Tales from the Evil Empire

One of the neat features in the new C# 6 is string interpolation, which is a concise way to inject values into a format string, using curly-brace-enclosed expressions. Here’s a simple example of what it looks like:

Newtonsoft’s JSON library provides lots of different ways to read JSON documents, including a SAX-like way to work with the document by reading it forward-only: JsonTextReader. This is very advantageous if you’re working with very large documents, especially if they are being streamed from a remote source. Using this kind of API, there is no need to have the whole document loaded in memory at once. The downside is that those API are usually quite unfriendly and low-level: you usually have to move a cursor and read values manually. This is not just tedious, it’s also brittle and typically creates excessive coupling with the structure of the JSON document. Last week, I had to read a large JSON document, and I wanted to explore better ways to perform such tasks, which led me to write a small set of helper methods that make it a lot easier to walk JSON documents using Newtonsoft’s JsonTextReader.

Enumeration fields are not exactly relationships, but they implement a very similar scenario. Therefore, it's useful to know about them, so that you can use them when they are relevant.

Enumeration fields are fields that present a set of predefined values, of which one or several can be selected, depending on the field configuration. The values are defined per field, which means that those values can’t be re-used across different content parts. If you have a scenario for re-use of values, then you probably need to use a taxonomy instead.

A little more than three years ago, I left Microsoft, and co-founded Nwazet, a hardware company that built cool products for makers. At the end of 2014, we sold our intellectual property to ModMyPi. Since then, I’ve been doing freelance consulting and development under the name Decent Consulting, and I’ve also been building a new CMS based on Node.js: DecentCMS… And today was my first day back at Microsoft as a Senior Program Manager.

Today’s way of relating Orchard contents is less universal than any of the ones I’ve talked about so far in this series: it will only enable you to attach media, such as images, videos, and audio, to your content items. Still, media have been real content items for a few versions of Orchard, and the media library picker is a very efficient way to add single or multiple media, so this most definitely deserves a post…

Taxonomies in Orchard can be seen as glorified tags, and in a way, that’s what they are: you can define multiple classifications for your content items, and assign any number of these classifications to your types. For example, a song could be tagged with a “genre” taxonomy, that defines terms such as “rock”, “blues”, “metal”, “progressive”, or “electro”. The same songs could be tagged with a “mood” taxonomy, with terms such as “epic”, “soft”, “spooky”, or “trashy”. Each song may be tagged with any number of terms from each taxonomy. In other words, there are n-n relationships between songs and taxonomy terms.

What makes Orchard taxonomies so much better than simple tags is that taxonomy terms are content items, and as such can be extended with additional parts and fields. Our genres and moods, for example, can be enriched with a body part, in order to give them a rich-text description.

The list feature, once deprecated, is back, entirely re-done, and now a great way to build parent-child relationships between content items. It’s so good we’ve even considered rebuilding the blogging feature entirely with it. The feature is actually admin UI around a single little thing that’s been in Orchard from the start: the Container property of the Common part. That’s right: all Orchard content items have the ability to point to another item to contain it. List is just exposing it, with some help from the Containable part, which adds the notion of order under the container.

So you’re a committer on an open-source project, and you also use the same project to build non-public projects for your customers. You set-up your customer’s repository so that it has remotes that point to the public project’s repo on one side, and the customer’s private repo on the other. You pull from the public remote, and only ever push to the private one. Everything works fine, until one day, you make one small mistake and push all of your customer’s proprietary code to the public repo for all to see. Oops.

Before you ask, no, I did not just do that. I did it once a long time ago with some proprietary code of my own, not customer code, thankfully. It was embarrassing enough however, and I had to ask for some help zapping the code before it was on too many people’s clones. This post is not about fixing the mess, it’s about preventing it from happening.