Working at Sitecore Australia brings me into contact with a lot of interesting problems and gives me the opportunity to solve them in (hopefully) interesting ways. A customer recently made the fairly common request to find a way have Items appear in more than one place. What I mean by that is they were looking to have an item appear as a child item to multiple parent items, an example being a book item appearing under multiple genre items.

For this I wrote a Data Provider module called ItemMirror, below is a package with the book/genre example I mentioned and I’ve also included the code, both will be up on Shared Source very shortly.

Package

Code

Typically the solution to this problem is to have a multi-select field such as a treelistex on each of the genre items and select the books you want to appear under it, you then can leave it up to the renderings to sort out where each book appears. In the vast bulk of cases this is a sufficient solution but the customer felt that in this case it left 3 unresolved issues:

  1. Increased difficulty editing the book items.
  2. Sub-par URLs, instead of landing on site.com/genre/book.aspx you would either land on site.com/genre.aspx?bookid=xxx or link to site.com/bookrespository/book.aspx
  3. Increased difficulty creating renderings.

What they said was needed was the ability to have book items that are otherwise stored in the book repository (called bookpile in the image above) shown under the genre items as children. This would neatly solve all 3 problems they were having, only problem being that it wasn’t possible out of the box with Sitecore (yet) hence the need for the ItemMirror module.

Configuration of the ItemMirror is done via the ItemMirror.config include file which you should find in App_Config/Include once the package is installed. The only line you’ll want to change is the one which configures the active template and the field which picks the items to replicate:

<template id=”{2BA6F255-67F5-4EDD-B626-11224F707658}” field=”bookSelection” />

The module should support multiple templates so you can have both genre/book and category/product running on the same website.

Quick Disclaimer

  • Documentation is forthcoming, in fact the lack of that is what’s holding it back from going on Shared Source really, think of this as the beta release.
  • Yes the virtual items publish and yes they become “real” once that happens, this is mostly because I didn’t feel that having the ItemMirror system running on the web database was particular wise or necessary.
  • The use of the master database is currently hardcoded in, if anyone can “solve” the XPATH statement needed at Line 75 in MirrorProvider.cs please post in the comments, otherwise I’ll have it solved for the Shared Source version.

Otherwise enjoy and feel free to suggest improvements.

Update:

A few quick replies based on comments via email/msn.

You could have used the Inline Item List Field.

Yes but sadly it wasn’t actually released when we started, it could in fact still be used alongside the ItemMirror.

What about Wildcard items?

Yep, that would have solved the URL issue but the customer wasn’t keen on the * items.

Is writing renderings to pull items from a multilist really that hard?

Well no, not for you and I but the customer was looking to do a lot of development in house, been able to simply render all child items would make their life a lot easier.

Isn’t this just Item Proxying?

No, come on guys, read the post, install the module!

What about stability/performance/daisy-chaining/other?

All good concerns and really this is why I made sure it only runs on the master database and gets turned into real items on publish. Daisy-chaining should only be possible if you explicitly set it up that way in the include file, in that case best of luck to you. Stability and performance were fine during development (isn’t it always?), it’s got two layers of caching, item and entity which should in theory cover you but it’s still needing some stress testing before it goes on Shared Source. Any volunteers?