Many have asked me, “Does ECL support BluePrinting”? My reply is always a solid yes, but (yes there is a but), I should really reply with a question: “Does your external system support BluePrinting”?
Since it is nice that ECL supports BluePrinting, but ECL just exposes items from your external system in SDL Tridion. So for them to be BluePrinted, you should have your ECL Provider make the connection between an SDL Tridion Publication and the specific items you want to show in that context. An ECL item URI contains a Publication URI, so to implement BluePrinting correctly in your provider, you will need to give the child item, the same ECL Item ID as its parent item. The only thing that is tricky there is localization, an ECL item doesn’t really have a localized state, the ECL stub Component can have that state though.
BluePrinting in external systems
Most external systems won’t have a BluePrinting concept like SDL Tridion has, but in reality all you need is a link between the parent item and its (BluePrinted) children. So as long as you can define an item and be able to locate its children (or the parent from a certain selected child), then you can implement this logic in your ECL provider and you will have BluePrinting.
How is that done? Well in your Mountpoint class (the one implementing the IContentLibraryContext interface), in the GetFolderContent, GetItem and GetItems methods, you make sure that you fetch the correct item from the external system related to the BluePrint context you are in. For this you will use the Publication ID which you have in your ECL URI. If your external system deals with languages or language cultures, you will need to define a mapping of each language (or language culture) and a SDL Tridion Publication.
BluePrinting Media Manager items
As an example of ECL and BluePrinting I can use the work I have done to add BluePrinting support to Media Manager though ECL. Now coming back on my initial question: “Does your external system support BluePrinting”? Media Manager currently (version 2.5.1) doesn’t have a BluePrinting concept like SDL Tridion has, and since the Media Manager ECL connector is not open source, you can’t add it like I mentioned before.
What I did to solve this was to create a folder for each parent distribution, and place the child distributions of that in there. Since my BluePrinting example was purely based on language cultures, I added this mapping in the SDL Tridion Publication metadata (defining which language culture that Publication belongs to).
Now to be able to know which folder belongs to which (parent) distribution, I prefixed the folder name with the distribution ID, and to know which child belongs to what language, I prefixed each distribution title with the language culture code. The pictures below show an example of how my distributions are stored in Media Manager and how they then will appear in SDL Tridion.
Now when an ECL item is localized, in SDL Tridion, we can localize its metadata, and the trick to make BluePrinting work is then all in the ECL Resolver Template Building Block. This will react on a localized item and find the corresponding child item in the folder belonging to the (parent) distribution. It finds the correct distribution using the language culture code that is prefixed in the distribution title of course.
The code for the ECL Resolver Template Building Block can be found on Google code, lines 301 – 393 show the code that checks if this Media Manager distribution (ECL item) contains a YouTube ID and if it is localized it will try to find the correct (BluePrinted) child distribution.
The rest of this TBB is exacly the same as the default ECL TBB which is what is delivered with SDL Tridion 2013 SP1, and as such, it can be used as a replacement.
If you have any questions about the code, please feel free to add that on http://tridion.stackexchange.com/, for other remarks, you can leave a comment on this blog.
Nice explanation, Bart. I like the power of GetFolderContent, GetItem and GetItems to show CMS users only the (culture-specific) version of an item for a given Publication in this example.
So basically any hierarchical relationship we could define could be displayed in a Mount Point based on things known about the external items (location, naming convention, external metadata, etc.).
Two question then — 1. how much does performance influence your design approach for the mount point display logic (is there caching involved, or do you start with the ideal hierarchy and figure out the performance after)?
2. Could you show an ECL item more than once, in say, different mount point folders?
Thanks!
@Alvin ECL is part of the UI (as an extension) so following the same cache principles. Things like icons are cached, lists and items not really I believe. If that is an issue all depends on your external system, the fact that we get a list of lets say 400 tems from which we only show 100 should not matter that much I would expect. Ideally your external system should have a way of delivering us the items we want and it should also deal with performance (and caching).
For #2, yes you can show an ECL item as many times as you want, but when you show it in different mountpoints, be aware that it gets a different ID, so from an SDL Tridion perspective it will be a different item.