Contents tagged with Orchard

  • The Evil Empire Strikes Back

    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.

  • Many ways to relate Orchard things, part 5: media

    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…

  • Many ways to relate Orchard things, part 4: taxonomies

    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.

  • Many ways to relate Orchard things, part 3: lists

    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.

  • Keeping a project’s public Git or Mercurial remote safe from your private stuff

    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.

  • Many ways to relate Orchard things, part 1: database relations

    A long time ago, I wrote a documentation topic on how to implement 1-n and n-n relationships in Orchard using database relations. It was much needed at the time, as this was still a difficult topic. Between spotty mapping mechanisms for relationships, and specific Orchard conventions, it wasn’t something you could expect just anybody to figure out on their own. It is still the way to go under some conditions, but those conditions are arguably very uncommon, and there are now much better solutions for more common cases.

    In this series of posts, I’ll show one technique per post, with pros and cons, and use cases for each. Today, we begin with database-bound relationships.

  • The Orchard Way

    An order for an electric conversion of a vintage Porsche  just arrived at Greg’s workshop. He follows a script that will implement the transformation of the car.  He looks at the order, and sees that the customer bought the 70kWh battery. He picks up the right number of cells, and re-orders more to refill the stock. The batteries are secured in the trunk. Then, he removes the car’s engine, and disposes of it. He fits the electric motor in its place, and proceeds to route wires from the trunk to the engine’s compartment. The control system is then assembled. All these operations are done sequentially by Greg. In a few weeks, the car is ready.

    Meanwhile, a few kilometers away, another order for a brand new electric car arrives at Elon’s factory. It should be an obsidian black metallic all-wheel drive with a 85kWh battery, panoramic roof, silver cyclone wheels, black leather seats, carbon fiber décor, black alcantara headliner, autopilot, and subzero weather package. That’s a lot of little independent details.

  • Content item identity in Orchard and DecentCMS

    Identity is a funny thing. It’s one of those concepts that we use all the time, but that are tremendously difficult to pin down precisely. To keep things “simple”, in philosophy and in physics, it’s about equivalence relations. In computer science, I’d say it’s more like a bijection between two categories of objects. The difficulty is that you can only approximate real identity this way: by definition, an object is only identical to itself. What we call identity in code really is a proxy for identity, a substitute for it that usually takes less bits to represent than the object itself. The difficulty when building an identity algorithm is twofold: you need to be able to deterministically extract an id from an object, and the id needs to be different when the objects are different. In other words, same yield same ids, and distinct yield distinct ids. Of course, this can be made more complicated with mutable objects. The constraints are in fact very close to those of a good hashing algorithm.

  • The DecentCMS and Orchard content type systems compared

    The content type system in Orchard is one of the reasons for its great flexibility. The ability to build your own content types from building blocks that are just the right size is essential to building a great CMS. Orchard has content types that are made of content parts, that can have properties and fields. Parts are aspects of a type, such as title, comments, or body, that there can be only one of per type. Fields are named, and there can be any number of each type of field per content type. Confused yet? There’s a reason for all this, of course, but in DecentCMS, I’ve opted for a simplified version.