March 27, 2013
Link Provider and Resolver go hand in hand. If you create one, you need to create the other. Sitecore comes with a default provider that gives you a nice, SEO-friendly URL. The Resolver reads those same URLs and translates them to find the content item in the CMS. When Item Buckets came along (which is now standard in Sitecore 7), they used a provider that may have been used for news items. Because bucket items, by default, are stored based on the date/time they were created (it creates a hierarchy of folders from year all the way down to seconds), the default provider within Sitecore will show you those date-based folders. So, to make the URL a bit friendlier, item buckets used the news link provider that essentially removes the date-based folders. The Resolver, on the other hand, finds the appropriate item by traversing the date-based folders.
With this said, you can create your own Link Provider/Resolver combo for specific needs such as multi-sites, complex SEO-optimization rules for URLs, storage (such as with item buckets), and so on. Although Resolvers are in the pipeline where you can have one Resolver after another, you can only have one (1) default link provider. Make sure to accommodate other link rules that may be on your site, such as the default one. I recommend that you build providers on top of each other, either through inheritance or as private member. Of course, you can always call a specific provider in your code if you need to.
Placeholders and Placeholder Settings
Have you ever wondered why there is a Key field in the placeholder settings? Why can't we just name the item with the key that we want? Is it because that's how it has always been and Sitecore just never took it out? At some level, it makes sense to just have the item name be the key, right? Well, sort of. If your Sitecore instance hosts multiple websites, then it's probably a good idea to have the same placeholders, particularly when your authors are the same people as well as for training and "getting used to" purposes. So, how does the placeholder key, name, and settings work?
When you put a < sc:placeholder > in your layout or sublayout, it only requires a key outside of the typical ASP.NET stuff. That key is what needs to be unique so that the rendering engine can find the placeholder in the hierarchy. For Page Editor purposes, you create a Placeholder Settings with the same key. You can name this item anything you want, but I assume that you will name this item the same as you would normally name the key. In the Page Editor, the placeholder "title" that you see when you hover the "add to here" or if you look at the container hierarchy is actually the name of the placeholder setting and not the key. What does this mean?
This means that I can create same named placeholder settings to show the author the "same" placeholder on different sites on the same Sitecore instance, such as "right-rail". But, on each of those "right-rail" placeholder settings, I can have a different key such as site1-right-rail and site2-right-rail. In the layout, I put < sc:placeholder > with the appropriate key for the corresponding site. Now, on each site they will both have a body placeholder but with different sets of components.
comments powered by