A quality content authoring experience requires many pieces to work well together. Renderings provide one important piece of configuration: the Datasource Location. This tells a rendering where to find its datasource items in the content tree, and when combined with Datasource Template, really helps guide content authors in creating/selecting content.
The Datasource Location is very flexible, accepting absolute paths, relative paths, and queries. If you have Sitecore PowerShell Extenstions installed, you can even use a PowerShell script to load a datasource location.
Datasource Location with a relative path:
./Assets
Datasource Location with a query:
query:./Assets//*[@@TemplateName = 'Console Folder']
Combine all multiple types to provide lots of flexibility:
/sitecore/content/nintendo/marketing/site content|./Assets|query:./Assets//*[@@TemplateName = 'Console Folder']
When using Datasource Location correctly, a Sitecore content author will see this when adding a new component:
Benefits of using Query
Using queries for datasource location allows for a unique approach to content organization. For example, querying content by template means some organizational duties can be handed to the content authors without losing the benefits provided by Datasource Location.
For example, the assets folder under this page has multiple types of folders for multiple types of content:
And with the proper query (selecting by folder name/ID), the content author only sees the relevant folders when selecting content for a rendering:
One Gotcha When Using Query
Unfortunately there is one issue that affects content authors when using queries for Datasource Location. If a datasource query returns no results, then the 'Select the Associated Content' dialog never appears when adding content. For example, here's an empty assets folder that would return no results with a query:
When adding a new rendering, a content author would skip the content selection dialog and just get an empty rendering (hopefully you're handling null datasources properly!):
This isn't a complete UX disaster, but it does break the usual flow of content authoring and might appear to be a configuration error during development and testing. Content authors just have a couple of extra steps to creating/selecting content.
If you will be using a query for a datasource location, make sure there will always be at least one result returned for the query to prevent any possible confusion for content authors.