Have you ever been in a predicament, in code, where you need to point to an item in the Sitecore content tree?
For instance, you are building a Search Component, and when the user clicks search, you are going to send over the keyword/s in a query string to the Search Results Page for use in processing and displaying the results. In code, I will need that URL in my Search Component in order for me to send over the results. Let’s analyze what our options are on this scenario:
For sake of simplicity, I will leave the null checking and exception handling to you. These are simply options to get ultimately to my point:
Option 1 (Rookie Option):
var searchResultsPage = Sitecore.Context.Database.GetItem("/sitecore/content/Home/Search Results");
var searchPageUrl = LinkManager.GetItemUrl(searchResultsPage);
We can get the item using the path, then get the item URL at that point. However, we NEVER want to do this with content items! If that path changes then now you have a broken Search Component. Just because we can use paths to get items in Sitecore, doesn’t mean it’s a good practice. As a matter of fact, I would consider it bad practice all around, so steer clear of this method.
Option 2 (Better Option):
var searchResultsPage = Sitecore.Context.Database.GetItem(ID.Parse("F6778EA3-1B76-4BBF-AD21-63E9EA847FDE"));
var searchPageUrl = LinkManager.GetItemUrl(searchResultsPage);
A better method to pointing to items is with the ID using the item GUID. Why? Performance reasons. Sitecore will pick that item up faster using the ID. More importantly the ID is tied to that item ONLY and anywhere the Content Editor moves the item, Sitecore will still be able to fetch it, and nothing will break on the Search Component.
Option 3 (Even Better Option):
Typically, in most solutions that I have come across for Sitecore, there is Constants file that has ID’s in the Constants file something like this:
public class ItemIDs
{
public const string NewsCategoriesFolder = ID.Parse("{B866EC76-54ED-447D-9AB2-5E05A0699586}");
public const string SearchResultsPage= ID.Parse("{F6778EA3-1B76-4BBF-AD21-63E9EA847FDE}");
}
As you can see from above there is an item for the News Categories Folder and the Search Results Page. Both of which need to be referenced in code, and the reason why they are in the Constants file. Using the method of putting those ID’s in the Constants file makes it easier to manage those ID’s in one place. When doing so, you can then get your item more clean and like so, in this case the Search Results page:
var searchResultsPage = Sitecore.Context.Database.GetItem(Constants.ItemIDs.SearchResultsPage);
var searchPageUrl = LinkManager.GetItemUrl(searchResultsPage);
If you make a change to the Item ID, then it will make that change across your solution versus having that ID out there in 5 other components you will need to change manually.
Option 4 (Best Option using TDS & Glass.Mapper with Code Generation):
Option 3 is definitely considered a best practice, but what if we can make this even easier to manage dynamically using TDS & Glass.Mapper, and keep ID’s out of the Constants file altogether except for rare circumstances?
Now that you have seen a few ways to point to the item in the Content Tree, let’s discuss Parameter Templates. Parameter templates are a way for you to add fields to your rendering that can help out the Content Editor in their daily Content Editing experience. Below are links to helpful information regarding Parameter Templates:
Now, that you have a good idea of what Parameter Templates are and how to set them up, let’s talk about why we would want to use them as a best practice in components for item pointing.
Parameter templates help to manage the solution while providing a better experience for your Content Editors. We simply create a Parameter Template to be used with the Search Component that has this criteria:
- Name: Search Results Page
- Field Type: DropTree
- Data Source: /sitecore/content/Home/
We create a Standard_Values for the Parameter Template and set it to the Search Results Page by default.
When added to the Search Component, it is by default set to the Search Results page, but if the Content Editor ever wanted to point to an alternative Search Results page (for whatever reason), they now have that option. But more importantly, you bypass having to now add this to the Constants file, if your Parameter Template is strongly typed as one of your Models. Using TDS with Glass.Mapper “Code Generation”, this will allow you to create your Parameter Template for the Search Component, then have it auto-generate the Model in your solution for use where you can then call on the Parameter Template like so using Glass.Mapper (notice Search_Results_Parameter):
var renderingParameters = GetRenderingParameters<Search_Results_Parameter>();
var item = Context.Database.GetItem(ID.Parse(renderingParameters.Search_Results_Page));
var pathInfo = LinkManager.GetItemUrl(item, UrlOptions.DefaultOptions);
The Search Results Parameter is now dynamically generated anytime there is a change in the item in Sitecore. Hence, you never had a need to create the model OR add the item ID/path to the Constants file.
Keep in mind you can still do this without TDS/Glass.Mapper “Code Generation” feature, but then you will need to create a model manually for your Parameter Template. The benefit is that you have given the Content Editor the ability the point to the Search Results page versus having this functionality in code that needs to be changed by a developer, and that is the benefit to the client. To my knowledge, you can also do this same type of “code generation” functionality with Unicorn/Synthesis as well.
I have found going this route equates to maximum productivity for the development team once the concept is understood, and helps in manageability of your solution overall. Happy coding!
Sitecore Sandbox 