Dusty Eves


Sitecore Architect with Paragon Consulting

Experience Editor Tip With Advanced IA

With sophisticated information architecture content authoring also becomes more complicated.  With that an effective page-editor implementation becomes even more important.  Below are some tips and examples using Sitecore 7 and Glass Mapper.

Fields: Editable Vs Not

Starting with the basics, the first question is what fields are editable on what pages. It’s tempting when developing toward a Page Editor friendly experience to have all render fields be editable. The downside to this approach is that it can quickly become foggy what is being changed. Here’s an example below of a fairly common site content structure. A content listing page presents a snippet of a number of sub-pages.


Taking the example above, if we make the fields of the blog list editable a content author could be changing the blog description without realizing they’re changing the intro text block at the head of the blog page. Thinking in the context of a page they may well assume what they change on this page will effect only this page. While use of workflow will likely prevent any such mistakes from being published, we should avoid ambiguity where we can. A good rule of thumb is to avoid making a field editable it that field is a member of another page, or is displayed on another page. For example, in the content setup below, on a Blog page the content of the Blog Item and RelatedBlogs would be editable but on the blogs listing page, they would not.


Editor Only Page Elements

Taking the previous example you have likely notice that the problem we solved also applies in the other direction, if the user changes the intro description they’re also changing the description in the listing page, possibly without being unaware of it. While an architecture as simple as this isn’t likely to be confusing, the problem does present in more complicated architectures, and is easily solved. Enter the IsInEditingMode conditional. This conditional allows us to essentially put in PageEditor comments. Much like code comments make things easier on developers who have to maintain our code, these comments make things easier on content authors.

<% if(IsInEditingMode){ %>

<div class="PageEditorTip">
    The title and text below define the summary on the Blogs list page.

<% } %>

<h1><%= Editable(m => m.Title) %></h1>
<p class='BlogHeader'><%= Editable(m => m.Text ) %></p>


Fields Not Editable Inline

Some fields just are not conducive to editing inline, particular fields that serve as pointers to other content such as Multilists and Treelists. This is easily solved via the EditFrame. An EditFrame is simply an area called out in the Page Editor as an area with related content. You’ll not in our Metadata fields example we used an edit frame to mark the fields as grouped together. The important thing maintain awareness of with EditFrames is their item context. The default behavior for an EditFrame is to resolve to the current SitecoreContext.Item. With a sophisticated like we’re using here that won’t always necessarily be correct.

So continuing our example, in our content structure we have an item to define related blogs but nothing yet to render it. Our related blogs Sitecore item will be no more than a Title an a Multilist of related entries, from which we’ll render a list of anchor tags. Once we’ve our markup, next we wrap it all in an EditFrame.

<sc:EditFrame id="frmRelatedBlogs" runat="server" Title="RelatedBlogs">
    <h3><%= Editable(m => m.Title) %></h3>

    <asp:Repeater ID="rptMain" runat="server">
                <a href="<%# (Container.DataItem  as IBasicPage).Url %>"><%# (Container.DataItem  as IBasicPage).Title %></a>

Only problem now is that we don’t want to edit the current SitecoreContext.Item, but rather the RelatedBlogs items which is our DataSource. To address that we bind the EditFrame’s datasource to the path of our DataSource item:

public partial class RelatedBlogs : GlassUserControl
        protected void Page_Load(object sender, EventArgs e)
            rptMain.DataSource = Model.RelatedItems;
            frmRelatedBlogs.DataSource = Model.Path;

So at this point if you load the Page Editor and click on the Edit Item of our blogs EditFrame a small window will pop up, but only allowing you to edit the title. Not being what we want, we have to explicate what fields we want to be able to edit. Switching over to our core database, if you navigate in the Content Editor to /sitecore/content/Applications/WebEdit/Edit Frame Buttons, you’ll see where the buttons in your EditFrames come from. First thing for what we need, under the Edit Frame Buttons item, insert a new Edit Frame Button Folder called Custom. Next insert a new Field Editor Button. Populate the Header, Icon and Tooltip as apropriate. For fields enter RelatedItems. Now that we have the definition setup, we need to apply it to our EditFrame. Add a property to the EditFrame as follows: Buttons=”/sitecore/content/Applications/WebEdit/Edit Frame Buttons/Custom”

All of that, gets us this:

List Field Editor

Like what you see? Something I missed? Have an even cooler way to do the same thing?!?! Let me know in the comments below.

Leave a Reply

Your email address will not be published. Required fields are marked *