Thursday, January 14, 2010

Positioning Content For Display

With this post I want to continue discussing how Sitecore handles presentation logic. My last post described layouts, which are just aspx files that Sitecore uses when someone wants to view content.

Think of HTML. Without content, HTML isn't very useful. Sure, you can have a box with a blue border, but if you don't have any content to put into that box, what's the point? I think of a Sitecore layout in much the same way. Layouts don't have content, they just position content.

So a key question to answer is how do you make content available to a layout? With HTML you just type text or a URL into a tag. With Sitecore you have some more sophisticated options available.

Positioning content using code
Sitecore has an API that provides access to content, so content can be positioned for display using code. For example, the following code could be added to the Page Load event handler in order to display the value of a field named "Text":



Item item = Sitecore.Context.Item;
Response.Write(item.Fields["Text"].Value);


I am far from a Sitecore expert at this point, so I can't say for certain that there's anything wrong with this approach. After all, it works. If you're comfortable with writing code, Sitecore allows you to write code.

However, even as someone new to Sitecore, I can see at least one possible problem with using this approach. When content editors work in Sitecore, they use a WYSIWYG interface called "Page Editor". The page editor allows a user to click on a value and start changing it.


The problem is how does Sitecore know how to generate the interface that allows the editor to actually edit? Unless you tell it, Sitecore doesn't know. Again, you can write code to tell Sitecore to render the user interface so it enables the value to be edited.

Maybe that's not a big deal in this example. In some cases you might not want an editor to ever change a value (site name, for instance). But some of the time - if not most of the time - you are going to want editors to be able to control the content. This is a content management system :-)

And this is a trivial example I'm using. There are only 2 values to edit. In the real-world it's not unusual to have a dozen or more. This quickly becomes more work than expected just to set up, let alone maintain.

Positioning content using server controls
Using the server controls that come with Sitecore is a much easier way to get content into a layout. The following code is an example of how a Sitecore server control can be used to display the value of a field named "Text":


<sc:FieldRenderer ID="FieldRenderer1" runat="server" FieldName="Text" />


Aside from the generic advantages server controls offer over coding, you also get at least one significant Sitecore-specific advantage: these controls are self-aware. By this I mean that they understand the environment in which they are being executed.

For example, if the control is being executed on the published website, a text value may be rendered. If the control is being executed inside the Page Editor interface, the control is able to determine if the current user has permission to edit the value. If the user has permission, then extra code will be generated that will allow the user to edit the value.

The value of this functionality becomes clear when you start thinking about content authoring and usability. But that's a topic for another post.

What's next?
In my next post I plan to get into some of the specific Sitecore server controls that are used to access content.

Want to learn more?

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.