Deploying complex Property Editors (Archetype) with Umbraco Courier on UaaS
TL;DR; I wrote a Courier DataResolver for the Archetype property-editor. The code is currently only available on GitHub and has only been tested against Umbraco-as-a-Service.
We’re very fortunate that with our latest project at Umbrella we are getting to develop with cutting-edge Umbraco technologies: Umbraco v7, Umbraco as a Service (UaaS) and the Archetype property-editor.
If you haven’t yet heard about UaaS yet, then be sure to catch-up with the recent uHangout episode where Niels Hartvig explains all.
Initially starting development with v7 was quite daunting, as with my past experience of v4/v6 I had a wealth of data-types and packages at my disposal; the most vital one being uComponents! What would I do without the Multi-UrlPicker?! Enter Archetype!
In a nutshell, Archetype is a new v7 property-editor that wraps around other data-types. This can either be as a single fieldset or grouped into multiple fieldsets. If you’re familiar with DataType Grid, or Embedded Content – it’s like those, but made with tiger blood! Check out Kevin Giszewski’s video demo showcasing Archetype’s features.
Here’s an example of how we’re using Archetype as a pseudo Multi-UrlPicker on our Umbraco website:
We found this works well and our content editors are happy with the interface.
All was well and good in our local development environment, then when we pushed our content changes up to our UaaS environment — we hit major issues with the node Id values inside our Archetype’s nested Content Pickers!
For those of you who have done team-development and multi-environment deployments with Umbraco may have experienced a similar situation; this usually leads to a lot of swearing and tearing out hair!
“Now! Have no fear. Have no fear!” said the cat.” There is a solution and it’s name Courier!
At this point, I have to admit that my past experience with Courier had been pretty hit & miss — sometimes it worked, sometimes it failed. Looking back I think maybe I’d expected too much from it.
Since Courier is one of the underpinning features of UaaS, I thought it wise to wipe the slate clean, let’s put the past behind us!
I read up about Courier’s DataResolvers and how to develop one for your own property-editor — from packing up a data-type’s prevalue options to extracting a content node’s property value.
The key point to remember, is that whenever you have a custom property-editor that can store a node Id (of any type – Content, Media, etc), you should consider developing a Courier DataResolver for it. I wish that someone had told me this during our main uComponents development!
Due to the complex nature of Archetype, the DataResolver needed to handle both the prevalue options and the node’s property values. The prevalue options were easy to resolve, as I knew these only referenced other data-type Ids. The node’s property values were much more trickier, as these could potentially reference any** node type (e.g. Content, Media, etc) and use **any type of data structure (e.g. JSON, XML, etc).
I had to think of a smart solution.
OK, so here’s the part where I moan about Courier being closed-source and not being able to dig into the API … yadda, yadda, yadda … ultimately I said hello to my old friend .NET Reflector and cracked open the assemblies. (I probably broke a license agreement in doing this – apologies! My motive was knowledge, not profit.)
From the assemblies I investigated how the ResolutionManager worked – this was key as I wanted to use it to pass the inner/nested values from an Archetype to it – meaning that Courier itself would attempt to resolve any node Ids! Happy days! (This even applied to any Archetypes that were nested within an Archetype … think about that for a minute.)
If you are interested in seeing the full source-code for the Archetype DataResolver, it is available on my GitHub repository.
For other examples of DataResolvers, there are examples on Umbraco’s Courier repository – yup, it’s not all closed-source! ;-)