Simple information site in Sitecore – part 8: Spots – Presentation oriented

This is the eighth part of the article series in 11 parts, describing how to build a simple information site in Sitecore.


In this article we’ll go through how you can build a content spot framework for your website. This article has been split into two parts. The first describing a content oriented implementation and the second describing a presentation oriented implementation. In this part we will describe the presentation oriented, where the spots are managed through the new unified page editor.

Written by: Jens Mikkelsen
Tue, Mar 29 2011

Articles in this series


Part 1: The requirements
Part 2: Installing Sitecore and setting up a Visual Studio solution
Part 3: Architecture
Part 4: The basic layouts
Part 5: Identity and documents
Part 6: Navigation
Part 7: The homepage - content oriented spots

Part 8: The homepage - presentation oriented spots
Part 9: News
Part 10: Search
Part 11: Deploying the solution


The Unified Page Editor


In this article we will use the Unified Page Editor to give the end user an optimal user experience through a visual GUI. Most of the features for the Unified Page Editor have recently been released and this article is based on Sitecore If you are developing on a previous version of Sitecore, you should upgrade before implementing the functionality described in this article.

As we already have developed the content oriented solution, the presentation oriented implementation will be created next to it (side-by-side). When you develop your solution, you should probably decide which implementation you want, and only use that.

Sitecore has also provided some documentation on the editor, which you can read about in the Client Configuration Cookbook

Also note that the Unified Page Editor is a merger between the old Page Editor and the Page Designer. No longer will the editors have to switch between the two. Further Sitecore has implemented a huge amount of features which improve the usability and fixed most of the technical issues, developers were complaining about. Therefore I suggest you use the presentation oriented implementation in your future solutions.


Layout deltas


A lot of improvements have been applied to the original Page Designer, which was released in a previous version of Sitecore. Besides improving the usability for the end user, Sitecore has addressed one of the biggest advocates against the Page Designer – the issue where layouts were copied from the templates standard values to the specific item, when adding a single presentation. This issue resulted in a solution which was hard to maintain, as it was impossible to control presentations in a centralized manner. But as I said, this has been addressed by Sitecore with the concept of layout deltas.

Layout deltas are a rather good solution, as only the specific presentation – added through the Unified Page Editor – is saved on the specific item. This means you can have areas on your website, where you allow editors to control presentations. You can still add presentations centralized, but the deltas from the standard values are saved on the items and will therefore be applied afterwards. This makes it perfect for spot frameworks. Here you want to give the control over the presentations to the editor in certain placeholders.

For more information on layout deltas I recommend you read Adam Conns blog post about it.


The implementation


Implementing the presentation oriented solution is no more complex, than the content oriented. In fact it might be simpler, as we don’t need any logic to add spots dynamically – Sitecore takes care of this for us. However there are a lot more configurations, if you want the editors to have the best user experience.

In this implementation we don’t need a spot render, as the placeholders handles this for us. Actually we don’t even need to modify the spots; we developed in the last part. However we need to ensure the editor will setup a binding between the presentation and a datasource. This is done through configuration.



The placeholders

In the same way we created the TwoColumnSpot sublayout in the content oriented implementation, we need a sublayout containing the placeholders, where the presentations can be inserted. We need to add this to a new component – we will call it SpotNew, as it is the “new way” to implement spots. So go ahead and create the component folders and project, as you by now have done a few times. (Note that we create a new component as this implementation is built next to the content oriented implementation). Further create a sublayout called TwoColumnPlaceholder: 


New component


In this sublayout we need nothing else but two placeholders:


< div class="TwoColumn">

  < div class="LeftColumn">

    < sc : placeholder id="LeftPlaceholder" runat="server" key="SpotLeftPlaceholder" />

  </ div >

  < div class="RightColumn">

    < sc : placeholder id="RightPlaceholder" runat="server" key="SpotRightPlaceholder" /> 

  </ div >

</ div >



This is actually it. There isn’t any need for the spotpresenter I described in the last article. Now all we need to do is, to change the home page to use our new presentation. So go to the homepage templates standard values and view the layout details. Here we need to change the TwoColumnSpot sublayout to the TwoColumnPlaceholder sublayout:


Change layout




The spots

In the last article we implemented the HTML and image spot. As I mentioned the implementation for the presentation oriented solution is actually the same. This is due to the fact that the data is pulled from the datasource, which is specified through the XSLT variable $sc_item.

In the same way as in the content oriented implementation, we need templates to keep the content in. We might as well structure this in exactly the same way, as we did before. As it is a side-by-side implementation, I am going to create the data templates for the spots again. The templates have the same fields, but I prefix them with SpotNew, as this is the component name:


New spot templates


I am also going to create a new spotfolder called SpotNewFolder and set the insert options of the standard values to point at our two new spots:


Spotfolder insert options


Now create a spot folder in the content tree:


Create spots folder


As the code is more or less the same, go ahead and copy the renderings from the implementation we implemented in the last part of the article series:


Spot renderings


Now all we need to do is to change the XSLT to use our new field names. The HTMLspot should look something like this:


< xsl:template match = "*" mode="main">

  < div class = "Spot">

    < div class = "HTMLSpot">

      < div class = "SpotTitle">

        < sc:text field = "SpotNew_Title"/>

      </ div >

      < div class = "SpotText">

        < sc:html field = "SpotNew_Text"/>

      </ div >

      < div class = "SpotLink">

        < sc:link field = "SpotNew_Link">

          < sc:text field = "SpotNew_LinkText"/>

        </ sc:link >

      </ div >

    </ div >

  </ div >

</ xsl:template >



And the ImageSpot should look something like this:


< xsl:template match = "*" mode="main">

  < div class = "Spot">

    < div class = "ImageSpot">

      < sc:link field = "SpotNew_Link">

        < sc:image field = "SpotNew_Image"/>

      </ sc:link >

    </ div >

  </ div >

</ xsl:template >



As you can see, it is really simple and only very little code is needed, but now comes the configuration.



Configuring the Unified Page Editor


The Unified Page Editor is a great tool for the editors. However by default it is rather open and the editors can change and insert presentations to all placeholders. You should always decrease the possibilities for the editors as much as possible, if you want to keep your site streamlined. What can be changed, will be changed. So we need to set this up.

First of all we need to ensure that the editors cannot insert presentations in every placeholder on the site. When you login to the editor and click insert component, you will see that you can insert it everywhere:

Unified page editor


Here the editor can even insert presentations to the header, footer etc. and we don’t want that. This means we have to configure Sitecore to disallow it.

The insert possibilities are created through a concept called Placeholder Settings.



Placeholder settings and bindings


Note that the configuration I do in this section of the article, is only for documentation. You should look through it to understand placeholder settings and the binding mechanisms. If you are actually implementing a site following this article series, you should wait to the next section to do anything. 


As the name indicates, placeholder setting is where you control the settings for placeholders. It is controlled through an item in Sitecores content tree under layouts:


Placeholder settings


These items control different things for the placeholders. I will come back to the different settings later. First of all it is important to understand how a placeholder settings item is associated with a placeholder. There are multiple ways:


  • By name. If a placeholder has the same name as an item in the placeholder settings folder.
  • By explicit reference through the layout field on an item (or standard values if layouts are added on this).


Both are referenced by the placeholder key.

The first option isn’t very nice, as this means we lose our settings, if we rename a placeholder and that we need a setting item per placeholder name. Instead we can use the second option to create generic settings, which can be reused.

Sitecore by default creates a reference by the name, if you use the standard functionality. This is done by accessing a page through the Page Editor. When you select a placeholder, you can click properties and a setting item with the name of the placeholder is created:


create placeholder settings


But as I mentioned, this is not all that good, so you should - more often than not - use the other binding mechanism. You can do this by creating the settings item in the content editor:


Manually create placeholder settings


Now that you have created the item, you need to associate with a placeholder. So go to the item where you have assigned the layouts (should be on standard values) and click layout details in the ribbon. Here you can click edit and you can select placeholder settings. Then click add, and you can now define your binding:


Bind settings to placeholder


In this example I bind the HeaderRegion (note that the placeholder key must be typed in lower case letters) to use the GenericSettingItem I earlier created.

I will explain the different setting options in the next chapter.


Controlling presentation insert options

Note: Now we are back on track and you should now implement the configuration I describe. 


As I mentioned we do not want editors to insert presentations to placeholders like the header region – only in the spot placeholders. You can control this by using the “Editable” field of the placeholder settings. If this field is unchecked, it is impossible to insert presentations to that placeholder. So go ahead and create a generic placeholder setting item, which we can assign to all the placeholders except the spot placeholders. In my case I have decided to call it NoInsertOptions and I have disabled editing:


No insert options


Note that the editors still have the possibility to alter and create content - but just not insert any presentations.

Now we need to assign this to all the placeholders, where the editor shouldn’t be allowed to insert anything. On the frontpage template this should be the placeholders with the following keys:


  • HeaderRegion
  • ContentRegion
  • FooterRegion


So go ahead and add these settings to the standard values of the frontpage:


Placeholder settings


When you now go to the Page Editor, you will see that it is only possible to insert something to the spot placeholders:


Spot placeholders


Now this makes it better, but we still have work to do. If you click one of those “Add to here” buttons, you will see that the editor can select any presentation. First of all this isn’t very userfriendly, second of all we don’t want the editor to insert anything but actual spots. We can also control this through the placeholder settings in the “allowed controls” field.

To set this up create a new settings item, which we will use for all spot placeholders. To make it a little more transparent which component the settings item belong to, create it in a new folder called Spots. When created add our two spot renderings to the allowed controls field:

Spot placeholder settings


Now assign it to the following placeholders:


  • SpotLeftPlaceholder
  • SpotRightPlaceholder


Again remember to use lower case letters:


Assign spot settings


If you now click the “add to here” button, you will see that the editor can only select the controls we specified:


Assign spot


That makes it a lot easier to use. However we are still not done.



Setting up presentation items for the Unified Page Editor


Even though we have come a long way, there are still a few improvements, we need to work on. First of all it doesn’t make much sense to let the editor insert a presentation without specifying a datasource – remember that we use the datasource property to pull out data. If the editor inserts a control without specifying the datasource, the control will use the context item. This item doesn’t have any of the spot fields, hence there will be rendered no content. However the new unified page editor holds a dialog in cohesion with the insert control dialog, which allows the editor to both select an existing content item and create a new. To ensure that the editor does this every time, we have to configure this on the individual rendering.

The first thing we want to ensure is that the datasource dialog is triggered after insertion, but we don’t want to bother the editor with the properties dialog. The properties dialog can be used in some cases, to specify presentation properties, but most often it will more likely confuse the editor with settings such as caching, which is far too technical for a non-technical editor. You can control this with the setting “Open Properties after Add”. Set this to “No”:


Open properties settings


The next thing we want to ensure is that the editor selects or creates the right type of datasource. This means that for a HTML spot, the editor should only be able to select the HTML spot data template we created earlier. Further we need to specify that if the editor wishes to create a new HTML spot item, it should also be based on the HTML spot template. This is done through the two settings “Datasource Location” and “Datasource template”. Set the first of the two to point at our spot folder and the second to the template of the HTML spot:


Renderings settings


Now we have ensured that the editor needs to specify a datasource and that it should be of the right type.

When the editor inserts a presentation and clicks next, he is prompted with the following dialog:

datasource dialog


In this dialog the editor can only select spots in the folder SpotsNew or create a new spot data item based on the HTML spot template. Try and create an example item. After you close the properties dialog, you can alter the content of the spot item through the Unified Page Editor. You can also see in the Content Editor that the item has been created.

Now do the same for the Image spot, but here you want to point at the Image Spot data template instead of the HTML Spot template:

Image spot settings


Now you are almost done. The last thing we need to do is to take advantage of Sitecores new screenshot functionality. This allows you to give a better visual representation of the presentation the editor is inserting. We have already inserted an HTML spot to the frontpage, so we can use that for our screenshot. Go to the Appearances section of the HTML spot. There you will find a field called Thumbnail. This is used in the dialog, when an editor inserts a presentation. Click the “Take screenshot” button and capture the HTML spot we already inserted:


Screenshot selector


Here you need to enter the path and device where the page is present and you can now use the percentage slider to zoom in and out. Then you can select the image you want and that is then shown to the editor:


Screenshot in action


If I just had some graphical skills, that would look very sweet :) Do the same for the Image Spot.

Congratulations! You have now implemented the spot framework in a presentation oriented manner.


You can download the source code and the Sitecore content here





Please rate this article

5 rates / 4,2 avg.

  • About the author:

    Jens Mikkelsen

    Jens Mikkelsen is a partner at Inmento Solutions a Sitecore consulting firm. He works as a Sitecore specialist and consulting helping clients architect and build quality Sitecore solutions using the newest modules and tools. 

    Further he has been deeply envolved in various complex solutions and has built up a strong knowledge of Sitecore architecture and best practices. He has especially focused on and is specialized in debugging and analyzing Sitecore solutions.


    Jens is very interested in the technical mechanisms in the new marketing products such as Sitecore DMS and Sitecore ECM.

    My Sitecore Freelance CV

11 responses to "Simple information site in Sitecore – part 8: Spots – Presentation oriented"

This is interesting. I have tried to implement something similar but I have just inherited all of the different spot template types up into my page templates.

It means every page template can have one instance of each spot with it's own content.

I find this is very easy for the editor. Would you advise against my method?
Posted: Wednesday, June 01, 2011 10:15 AM
Hi Jens,

Great work on this article, it has really helped me out on my last project.!

I have used this approach and it worked pretty good. We created a set of components which can be used on most pages through de website.

However, we ran into 2 drawbacks with this approach:

- number 1:
all data that is created by the components is stored on a central location. For example: /sitecore/content/components/teaserboxes.

Some of these containers contain important content that we want to save in a lucene index. Unfortunately when lucene indexes the content of these components, it stores the location of the components itself, instead of the pages were a components is used. (When rendering searchresults, we want to link to pages where the components are used).

- number 2:
Alle items created through the "Unified Page Editor" are stored at a specified datasource. This allow us to use a specific component on other pages. This is not always desired by customers. Lots of customers ask me how they can create a component (with Unified Page Editor) which cannot be shared among other pages. (The locations are often not known when building the website)

Is there some way to prevent these drawbacks
kind regards,

Posted: Monday, June 20, 2011 1:58 PM
Hi Erik,

Some of your problems might be solved by using a relative location to store your data. You can use "./" as the Datasource Location of your rendering, or some other relative path. Be sure though that the resolved path exists (you can use a Branch to ensure a 'Spots' folder underneath each item exists, for example).

However, I would like to have a Datasource Location relative to the startItem of the current site. This would enable multiple sites (in the same sitecore instance) to have their own Spot content. I haven't found a way to do this yet. The Datasource syntax doesn't seem to support the full sitecore query syntax, otherwise something like "./ancestor-or-self::*[@@key = 'home']/Spots" might do the trick, but alas.
Posted: Wednesday, June 29, 2011 1:07 PM
Hi Matthijs

I'm going to write a blog post on how to use the Datasource Location on multisite solutions as soon as I get some time. But from memory what you need to do is to make your own class for GetDatasourceLocation and insert it into the getRenderingDatasource pipeline.

Posted: Wednesday, June 29, 2011 1:46 PM
Hi Jimmy. Thanks for the pointer! I already looked at some of the configuration options, but .. something with needles and haystacks.

Posted: Wednesday, June 29, 2011 2:24 PM
Hi Jimmy, your suggestion worked perfectly. I now have a GetDataSourceLocation implementation that can handle stuff like "query:ancestor-or-self::*[../../../sitecore]/Widgets". This resolves to the ancestor of the current item that is 3 levels deep, i.e. /sitecore/content/*, and the the Widgets child node of that. This way it's possible to have a bag of widget content (called Spots here) for each site independently.
Posted: Thursday, June 30, 2011 9:48 AM
Is there anything you can do about the spam, lately? It's kind of annoying, but I would still like to receive valid updates. The captcha might be too weak.

Thanks, Matthijs
Posted: Tuesday, August 16, 2011 9:31 AM
Great article as usual Jens.

If you go to navigant.com and see the spotlight banner on the home page you will see that there is a spotlight banner with 5 spots. I already have up a hybrid content/presentation implementation that allows for a Spotlight Banner to get added to the page and I customized the EditFrame to allow for Spots to get added to the Spotlight Banner. I cannot however add a new spot through the Page Editor. Has anyone successfully built something similar where the user can add component which has nested components which could also be added/managed or any tips on how to handle?
Posted: Monday, August 22, 2011 4:35 PM
Hi Matthijs

I'm so sorry for all the spam. We are very busy at the moment and I haven't had time for maintaing LearnSitecore. I have changed the captcha today, and hope it will work better now.
Posted: Saturday, October 01, 2011 1:16 AM
Hi Jens,

First of all I would like to thank you for posting such a great article. "Thank you".

Now, I would like to share the problem I am facing. I have included the widgets with xslt renderings that you have explained in your article and they are working fine. But when I try to use sublayout instead of xslt rendering, the widgets are not working as they are supposed to work. The Sitecore Context item points to the page that has the widgets but not the actual widget item. Can you please help me fix this issue. Also, I am working on a MVC project. Will we follow the same approach for widgets in MVC also or will it be done differently?

Eagerly awaiting your reply. Thanks again.
Posted: Friday, June 21, 2013 9:38 AM
I'm late to the party here and using SiteCore 8 and SiteCore Rocks as my first exposure, but I'm able to follow this far. Great tutorial!! So...did parts 9 through 11 happen? Can I find them (perhaps under another site?)
Posted: Sunday, December 27, 2015 6:17 AM

Leave a reply

Notify me of follow-up comments via email.