Treelist In Sitecore Has More Options Than You Think
Showing, hiding and stopping users from selecting items
Beyond The Data Source
The Treelist and TreelistEx fields types in Sitecore present the content author with many options. They can choose anything they like from a given point in the Sitecore tree. While this freedom is great, too much freedom creates headaches for developer and compromises the health of the CMS.
While a fields Source property in Sitecore can be set by GUID, Path, XPath Query. Treelist and TreelistEx controls have a fourth very powerful option, the query string.
The Query String
Using all available options, this is what a Source using a Query String would look like:
All The Parameters
A little overwhelming. Let's break it down by parameter: (Case-insensitive, Sitecore forces values to lowercase internally)
The root item the the field points to. Must be a path. This is short coming I believe to be addressed in Sitecore 7.
Allows the same item to be added twice by the content author. Defaults to "no".
A comma separated list of template names (no ids). Items are visible in the tree, but can’t be added/selected. My favorite.
excludetemplatesforselection=Item Name,Item Name 2
A comma separated list of item names or ids to be hidden from the author. Useful to hide unwanted folders, for example.
A comma separated list of templates names (no ids). Items based on these templates will hidden from the author.
A comma separated list of item names or ids to be shown to author.
A comma separated list of templates names (no ids). Items based on these templates will shown to the author.
A comma separated list of template names (no ids). Items are visible in the tree and can be selected.
Changes the database name being referenced. Useful if using an external data provider.
This is the look of a Source field I'd typically set.
datasource=/sitecore/content/fishtank/repo&excludetemplatesforselection=Some FolderI haven’t come across a real-world scenario to use the Include*** options but I know they're out there.
Although not perfect (i.e. names and paths instead of ids), the Query String field source adds functionality to the Treelist and TreelistEx that can lead to less code and a simpler authoring experience. And in the bigger picture, leveraging the Query String field source approach opens up many possibilities when creating your own custom fields.
Thanks for reading.