Reading some time ago the Item Buckets documentation I discovered something really cool called code data sources. We delivered something similar in our internal libraries and it proved super useful ever since. I’ve also recently read a nice article by Ronald Nieuwenhuis on NewGuid about their approach to the subject.
So what a PowerShell and Sitecore nut does when he sees stuff like that? Obviously delivers a scripted data source!
Why do that?
Just to prove that both Sitecore and PowerShell are infinitely malleable and mixable, is good enough for me, but that’s not really the reason someone other than me would be interested in it.
- Delivering complex functionality based on multiple criteria. e.g. your field may need to provide different set of items to choose from based on:
- user name or role (in simplest case this can be done using right management, but maybe not always possible in a more elaborate scenario)
- current day or month?
- In a multisite/multimarket scenario you may want to show different items for each site
- based on engagement analytics parameters of the page
- based on where in the tree an item exist (some of it can be done with use of a “query:”)
- anything you might want to build the code data source for…
Something that would be beyond the reach of a regular Sitecore query and potentially something that you would really need to deliver code source for. But maybe you’re not in a position to deploy that on your environment?