When SharePoint unveiled their web content management functionality in 2007, they included the practice on inline editing directly into the content management experience. While they were by no means the first to do so, I feel strongly that they did a very good job considering it was their first iteration of the technology. User interface developers creating page layouts can very easily integrate the editing of metadata directly into a page layout very easily by dragging columns from the “Page Content” section in the toolbox panel of SharePoint Designer. But what if we have some more advanced layouts, and when we try to add metadata into the editing experience? It actually makes the editing experience much less attractive.

Case in point, here is an event page layout for the new Portal Solutions site built in 2010 (the methods described in this post will work in 2007, but all sample code is tested in 2010). As you can see, I have a section that highlights details about the event, and this section is a smaller, floated column on the right. Dragging the columns from the toolbox into the page layout produces a rather ugly content management experience.

The forms that are added inline throw off the layout. You can also notice that I also have a styled button, and putting this page into edit mode actually makes that metadata column incomprehensible. Clearly, we need a better solution.

Using the Read-Only Metadata Value Control

Thankfully the platform provides us some tags that allow us to change how this works. Instead of using a single control that does both the edit mode and display mode we can split the two. Here is what the code looks like when I simply drag and drop the column from the toolbox (this is the address column which actually OTB).

<SharePointWebControls:NoteField FieldName="fc2e189e-ba91-48c9-9dd3-16531afddd50"
   runat="server"></SharePointWebControls:NoteField>

What this control does is in display mode it only pulls the value of the column, but in edit mode it adds the form to support editing the value. We need the ability to separate the two display modes to make for a better experience, and I will show you how.

But first let me direct your attention to that nasty GUID in the snippet above. That comes from SharePoint Designer 2010 by default, and what we really want to use there in the FieldName attribute is not the GUID but the internal name for the column (in SP Designer 2007 it correctly pulls the internal name). While this code might work for a one-off, it certainly won’t work in a scenario where we need to publish these page layouts particularly in a feature deployment. If you didn’t create the column with a feature you can find the internal name by simply opening up the column in edit mode inside the UI (Site Settings » Site Columns » Your Column Name), and in the title bar it will tell you the internal name after the ?field= in the URL (be sure if you create the name in the UI to keep the column name all one word when first creating, and then you can go back and add spaces).

Now let’s look at a special control that only pulls the value from a column, and even when it’s in edit mode it doesn’t show a form. This truly is a column in read-only mode. This snippet uses the same address column.

<SharePointWebControls:FieldValue id="WorkAddress" FieldName="WorkAddress"
   runat="server"></SharePointWebControls:FieldValue>

This is much better! Technically, the ID can be whatever you want, but be sure to coördinate to with a developer if they are working with this in any way and need to know the ID. I usually keep the ID and the FieldName the same, but that is at your discretion. Now let’s replace all the columns with this read-only control and see what this looks like in edit mode.

Adding Back in the Editing Experience

This is looking good, but we still want the ability to edit the values for these columns inline. To do this I add a section at the bottom of the page dedicated to editing metadata. I still keep the rich HTML fields (Publishing Page Content) in the page where they display (if I’m using it), but I move all other columns down below (and sometimes depending on the situation I even put publishing HTML fields in this metadata zone as well). To accomplish this we are going to use the EditModePanel control from the same toolbox panel (in the SharePoint Controls » Server Controls section) to add content into the page that only displays when the page is in edit mode.

<PublishingWebControls:EditModePanel runat="server" id="PageMetadata">

<div class="pagemetadata">

<h4>Edit Page Metadata</h4>

<SharePointWebControls:TextField FieldName="Title" runat="server"></SharePointWebControls:TextField>
<SharePointWebControls:DateTimeField FieldName="EventStartDate" runat="server"></SharePointWebControls:DateTimeField>
<SharePointWebControls:DateTimeField FieldName="EventEndDate" runat="server"></SharePointWebControls:DateTimeField>
<Taxonomy:TaxonomyFieldControl FieldName="EventType" runat="server"></Taxonomy:TaxonomyFieldControl>
<SharePointWebControls:UrlField FieldName="RegisterLink" runat="server"></SharePointWebControls:UrlField>
<SharePointWebControls:NoteField FieldName="WorkAddress" runat="server"></SharePointWebControls:NoteField>
<link href="/_layouts/1033/styles/Themable/forms.css" rel="stylesheet" type="text/css" />

</div>

</PublishingWebControls:EditModePanel>

This will allow the content contributor to have a much more streamlined experience particularly in pages where you have a significant amount of metadata you want to offer to edit inline. The column controls I’m using above are similar to the ones provided by the toolbox (with the GUIDs replaced with internal names), but with the EditModePanel it only shows the form layout to edit when the user asks for it in a much better layout.

The one thing to notice is the inclusion of a SharePoint stylesheet that styles the HTML from the controls added when the page is in edit mode. I noticed sometimes the stylesheet didn’t come through, so to alleviate I just included it. It only renders when in edit mode so it’s not an unnecessary HTTP request for viewing content only, and even if it is already included it shouldn’t cause you a styling issue unless you want to overwrite these form styles (in that case remove that reference above).

Here is what the edit metadata zone looks like in edit mode which I put under the page content. I didn’t do much with it style-wise in this screenshot, but you could add some nice touches depending on your desires or needs.