Thursday, January 21, 2010

Sitecore Presentation Controls

In Sitecore, there are various web controls that can be used to display the value of a field. This is critical because content it stored in fields. If you want to display the date assigned to a press release or an image of the cover of a book that you sell on your website, this is what you are interested in.

However, presentation logic should be thought of as more than a bunch of individual values. There are relationships between the fields being displayed. You're not just displaying the title of a book along with its cover. You are displaying details about a book. Today it's the title and cover. Tomorrow it might also include a summary of the book.

Before presentation controls and after.

A block of presentation logic in Sitecore is defined using a component called a "presentation control". In this post I am going to give a quick overview of presentation controls.

What is a presentation control?
A presentation control allows presentation logic to be defined in a reusable component. Some examples are:
  • Book detail - displays the title, author, summary and price of a book along with an image of its cover, positioned in a certain way
  • Breadcrumb trail
  • Ad block - displays an image and a hyperlink
  • Header block - displays an image, search box, an ad block and a home link
Sitecore supports 3 kinds of presentation controls: sublayouts, webcontrols and renderings. Sublayouts and webcontrols are written using .NET. Renderings are written using XSLT.

What are the benefits to presentation controls?
One benefit of using presentation controls is that your presentation logic is encapsulated in a reusable component.

Another benefit is that content editors are able to use the Sitecore page editor to drop presentation controls into their web pages. This is a very powerful tool that can be offered to content editors, and one that I will cover in a future post.

This is not so much a benefit of presentation controls so much as a benefit of Sitecore. There is no new, proprietary technology that you need to learn in order to create presentation controls. You can use .NET or XSLT.

I spent many years teaching people how to use a product that depended on an unwieldy, proprietary language for presentation logic. It's definitely to Sitecore's credit - and the benefit of people learning Sitecore - that they decided against reinventing the wheel.

What's next?
My next post will take a look at some of the technical details of presentation controls. How are they written? What do they look like? How are they used?

Want to learn more?

Monday, January 18, 2010

Displaying Field Values Using Server Controls

This post is part 3 of a not-yet-determined number of posts discussing presentation logic and Sitecore. My previous post explained some of the options available for getting content to appear in a Sitecore website. I ended with a promise to cover some of the Sitecore server controls that are used to display content.

Sitecore has a number of server controls that are used for different purposes. For this discussion there are 2 kinds of server controls to consider: those that display a single value and those that display other controls. I will start with the former.

Controls that display content
One of the most fundamental tasks performed by presentation logic is to display values. If you are displaying content about a book, you might want to display the book's title and author and an image of its cover.

In Sitecore, the book would be an item which was created using a data template. The title, author and image are fields defined in the data template. A layout is used when the book item needs to be displayed. Server controls are used in the layout to position and render the field values.


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


The specific type of server control is Sitecore.Web.UI.WebControls.FieldRenderer. The class name reveals this server control's purpose: it renders the value of a field. The various web controls that extend Sitecore.Web.UI.WebControls.FieldControl provide similar functionality.

What's the difference FieldControl classes and FieldRenderer? FieldRenderer is generic. You give it the name of the field and it will render the value. FieldControl classes target specific field types. They recognize the unique capabilities of the different field types. The following examples demonstrate what I mean.


<sc:Image ID="Image1" runat="server" Field="Image" MaxWidth="250" />
<sc:Date ID="Date1" runat="server" Field="Date" Format="MM/dd/yyyy" />


As you can see in the following example, the specific options that are available using FieldControl classes are available using FieldRenderer. You just don't get Visual Studio showing what they are the way you do with FieldControls. One thing to note is that FieldControl classes do not exist for every possible field type, so you'll probably be using FieldRenderer at least some of the time.


<sc:Image ID="Image1" runat="server" Field="Image" MaxWidth="250" MaxHeight="100" />
<sc:FieldRenderer ID="fr1" runat="server" FieldName="Image" Parameters="MaxWidth=250&MaxHeight=100" />


What's next?
That gets us through the server controls that display field values. But most of the time individual field values aren't displayed on their own. Usually a number of fields are displayed together, forming a logical grouping of presentation logic. In my next post I will describe how blocks of presentation logic can be defined in Sitecore.

Want to learn more?

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?

Tuesday, January 12, 2010

Defining Presentation

Last week I wrote about content modeling and inheritance, two of the first topics you encounter when learning Sitecore. Content modeling isn't the most exciting topic. You're really just defining data structures used to store content. There are only so many ways to skin that cat, and so many things that a WCM vendor can do to make this a difficult or complicated task.

Handling presentation is another matter. A vendor can choose to use an existing technology for presentation logic. Or, if the vendor is especially self-confident, it can create its own technology. Sitecore uses the former option, with .NET and XSLT being the specific technologies.

What is presentation?
Just to be sure we're on the same page, I want to explain a little about what the term presentation means when dealing with WCM. Content modeling covers how content is defined. In Sitecore, data templates and items are the main tools used to model content. Content is what gets displayed, and it is separate from how it gets displayed.

Presentation is responsible for describing how content should be displayed. It says, for instance, that the image should go in the upper left-hand corner and the main text should be positioned below it. Presentation is what makes it possible to view content on a website. Content without presentation is like having records in a database without a query to retrieve them.

How is presentation defined?
Sitecore uses "layouts" to specify the overall positioning of content and the format of the content being displayed. The purpose of Sitecore items is to store content. The purpose of Sitecore layouts is to provide a visual representation of items. A layout's format is usually HTML, but it can be pretty much anything you want: XML, PDF, etc.

Uninteresting example of a Sitecore Layout.

Layouts are aspx files. And I don't mean a special kind of aspx file. There is no special class that has to be used to create a layout. There is no special interface that must be used to create the aspx file. No new proprietary language, format, tags or syntax is needed. Sitecore websites can be designed and coded in the same manner as any ASP.NET website.

So layouts are web pages, right?
It seems important to remember that a layout is NOT a web page. Sitecore uses layouts when it needs to display items. A web page - when delivered by Sitecore - is a combination of a layout with Sitecore content. Web pages don't exist inside Sitecore. Web pages are generated by Sitecore.

When you think of a web page, you think of something specific: a web page that describes an event or a place. A Sitecore layout, on the other hand, has nothing specific in it. It can display information about specific events or places, but it doesn't have any content of its own. I'm tempted to describe a layout as a presentation template, but since the word "template" already has a use in Sitecore, I'm not going to do that ;-)

What's next?
I've given an overview of what layouts are, but I haven't explained what goes into layouts. In a way, there isn't anything to explain. Layouts are aspx files, so anything that goes into an aspx file can go into a layout.

But, actually, there is more to explain. Sitecore provides some server controls that make it easy to access content in a layout. In my next post I'm going to explain about these server controls and the advantages you'll gain by using them.

Want to learn more?

Thursday, January 7, 2010

Inheritance, Content Modeling & Sitecore

In my previous post I discussed the most elementary aspects of content modeling with Sitecore. When you are learning a WCM system, it's easy to stick with very simple content models. The risk in this is that content models in the real world are not always simple.

Until you encounter requirements that include overlap and interdependency it's easy to have an unrealistic opinion of how well your WCM models content. So far I have been very impressed with Sitecore's approach to modeling content - specifically its support for inheritance.

In this post I will cover inheritance and why it's such a great thing to have in a WCM.

What is inheritance and how does it work?
A data template is a collection of fields. Those fields can be defined directly in the data template, or they can be "inherited" from other data templates. When content is modeled, there is often overlap between very different content. Inheritance allows the overlapping fields to be moved into separate data templates that can be used by any data template that needs the fields.

Let's consider some content that might appear on a website: books, press releases and reviews. The following table lists the fields that are needed for each content type:

Data Template Name
Fields
Book
title, description, image, category, author, price
Press Release
title, description, image, category, date
Review
title, description, image, book, reviewer name


Using inheritance removes duplication by allowing common fields to be moved into more generic base data templates. The following content model takes advantage of inheritance:

Data Template Name
Fields
Inherits
Content Base
title, description, image
[none]
Content Meta Data
category
[none]
Book
author, price
Content Base, Content Meta Data
Press Release
date
Content Base, Content Meta Data
Review
book, reviewer name
Content Base


This explanation of inheritance may appear to contradict something I wrote about items above. I wrote that an item is based on 1 and only 1 data template. That is true of items, but it is not true of data templates. A data template can be based on as many different data templates as you want.

The Book data template's path of inheritance as seen in Sitecore. This example shows the Book data template inherits from the "Content Base" template, which inherits from the "Standard template" template, etc. The "Content Meta Data" data template is also included, but is not shown in this screenshot due to space constraints.

Then what does it mean if an item is based on a data template that is based on multiple data templates? A book item is an example of this. The book item is based on the Book data template, but the Book data template is based on both Content Base and Content Meta Data. This means that the book item is able to store content defined in 3 data templates: Content Base, Content Meta Data, and Book.

You might be tempted to think that a book item is based on 3 data templates, but I don't think that's technically accurate. When you create the book item you can only select 1 data template. The fact that you inherit from 2 other data templates is important, but it shouldn't be confused with the fact that the book item is based on only 1 data template.

Why should you care about inheritance?
There are many reasons to appreciate inheritance. Being able to reuse content definitions makes it easier to make changes later. Consistency is improved because common fields are defined once and used when needed.

But I think the best benefit of inheritance is ease of use for non-technical users. Remember, all of this inheritance is handled by the developer. The content authors never see any of it directly, but they reap the benefits. From the author's perspective, all of the fields are just there. There is no linking or connecting to a separate object in order to enter the values. This means the author can work on the content in one piece, as it exists in the real world.

What is life like without inheritance?
This may seem like an obvious way to do things, but not all WCM systems are designed this way. Consider RedDot CMS (now called Open Text Web Solutions Management Server) as an example. In RedDot, it is possible to move common fields into a shared component. This component is and always will be separate from the component that uses it.

While setting these separate components up is not any more difficult than with Sitecore, the effects are far reaching and significant. Instead of having to create one piece of content, RedDot requires multiple pieces of content be created and connected to one another. Each piece of content is independent each other, meaning that they have their own security, workflow and publishing settings. Content authors have a hard time understanding which pieces go together and which don't. When blocks of content are missing from the website, they don't understand how that can be.

So what ends up happening is the fields that should be separated out are duplicated wherever they are needed. This makes life easier for content authors, but can result in a lot of duplication of work and added complication for developers. On a large project, it is easy to forget all of the places where changes need to be made.

What's next?
Data templates and inheritance seem to be 2 of the most important concepts to understand when first working with Sitecore. Modeling content is at the core of a WCM system, and data templates and inheritance are at the core of modeling content with Sitecore.

Being able to define content is crucial, but if you don't have any way to display content, you might as well not have any content at all. My next post will cover my first impressions of the approach Sitecore uses to handle presentation logic.

Want to learn more?

Wednesday, January 6, 2010

Content Modeling With Sitecore

One of the first technical topics you encounter when learning Sitecore is how the system separates content from presentation. In some ways this is a massive and complicated topic. There are so many options and approaches that can be used.

At the same time, its essence seems to be pretty simple. Not simple in that it should be easy for anyone to understand or that it can be learned quickly. I mean simple in the sense that there isn't much to it. Yes, Sitecore provides a large number of tools for a developer to use to model content and design presentation, but there's a distinct logic and consistency to it. Once you're able to get your head wrapped around that, the system isn't as overwhelming.

New York's original telephone system provides a good metaphor.

If one of the first things you learn is how Sitecore separates content from presentation, probably the very first thing you learn is how Sitecore models content. How does a developer configure Sitecore so content authors are able to create content on the site?

How is content described?
Data Templates are used to model content. A data template is a collection of "fields", with each field representing a specific piece of content. Data templates are used to create "items". An item provides the ability to save specific values for the fields. Each item is based on 1 and only 1 data template. To use an object-oriented programming analogy, data templates are classes and items are instances of those classes.

Fields from a data template at they appear in Sitecore.

For example, you might create a data template for a book. A book has fields to store a title, author, description, image and price. Each book item has its own title, author, description, image and price. Examples of book items are "Crime and Punishment", "Absurdistan" and "Sum" (which are 3 of the best books I read last year).

This is a simple example. In the real world, content is often much more complicated. What if you need to model all sorts of books, with each type of book having different content requirements. For example, the content for a novel might be very different from that of a journal or a reference volume or a technical manual.

The way a WCM system provides handles content like this (meaning there are similarities along with differences) impacts so many different aspects of the system that it's hard to overstate its significance. When a WCM doesn't do a good job, usability suffers, it becomes more difficult to introduce changes, duplication starts to appear, among other things. And all of these things increase the cost of building and maintaining your website.

What's next?
In my next post I will explore the concept of inheritance as it pertains to modeling content with Sitecore. I am impressed with how Sitecore allows developers to use inheritance to create a content model that is easy to develop, maintain and use.

Want to learn more?

Monday, January 4, 2010

Getting To Know "Getting to Know"

Hi there, and welcome to my blog. If I'm not mistaken, this blog has earned the distinction of being the first new Sitecore blog of 2010. Dubious, perhaps, but a distinction nonetheless.


Who am I?
In late 2009 I joined Sitecore as a Technical Architect. I'm a member of the Product Marketing team. As I've been telling my friends, the only bad part of the job is that it's not very easy to explain what I do. My responsibilities include making sure that people inside the company have the technical product knowledge they need in order to get their jobs done, and to help partners develop quality integration between Sitecore and external systems.

Prior to working at Sitecore, I worked at RedDot Hummingbird Open Text. My role there ranged from training to helping partners implement RedDot Open Text Web Solutions products. And before that I worked as a trainer, developer and consultant for content management and custom application development.

What is the purpose of this blog?
Eventually this blog will likely focus on integration topics, since working on integrations is one of my main responsibilities at Sitecore. I was inspired by the spirit of openness and sharing that I see at Sitecore, and I was eager to start sharing my experience and knowledge as soon as possible. But since the part of my job that deals with integrations won't be starting up for a little while, I had to think of something else.

Since I am not only new to the company but new to the product, I decided to blog about my experience learning Sitecore. I hope these posts will help people who are looking at or are new to the product see what it's like to enter the Sitecore world.

While I am new to Sitecore, I am not new to web content management. I may be learning features for the first time, but not the underlying concepts. I haven't been working with Sitecore long, but I already see that a number of the most intractable and pervasive problems people have with other WCM systems can be solved elegantly - or avoided altogether - using Sitecore. In addition to explaining features, I also hope to be able to explain why Sitecore's approach matters.

So thanks for reading. I hope you'll return!