Monday, February 22, 2010

Blog Update

Just wanted to let everyone know about a small - but important - change I recently made on this blog. I went back through my previous posts and added links to the relevant Sitecore resources so you can get more information on the topics discussed. Look for the "Want to learn more?" section at the end of each post. I will be including this information in all future posts as well.

Friday, February 12, 2010

How Sitecore Determines Which Layout To Use

Recently I've written about the core components of Sitecore's approach to presentation logic: layouts and controls (.NET and XSLT) and placeholders. I've explained how content is displayed in layouts, and how controls are positioned inside them. What I haven't covered is how Sitecore knows which layout to use and when. That is the topic of this post.

How content is viewed in Sitecore?
When someone wants to view content from Sitecore, a request is made through a URL. In Sitecore, every URL resolves to an item in the system. What Sitecore returns when a request is made is a visual representation of the item that corresponds to the URL. We know that layouts provide the basic structure of this visual representation, but how does Sitecore know which layout to apply to which item?

What is a device?
A device represents a specific way of viewing content in Sitecore. Sitecore analyzes a request in order to determine how the user wants to view content.

This determination is based on rules a developer configures. Sitecore allows the browser agent and query string values to be used to define rules. (Of course, it is also possible to extend Sitecore to support other criteria.) If you anticipate visitors will use desktop web browsers and mobile phones to access your site, you might configure 2 devices.

Device configuration options.

It's important to note that devices themselves don't do anything. A device does not specify which layout should be used. Sitecore inspects incoming requests in order to determine which device is appropriate for each request. After Sitecore figures this out, the device is just one of many pieces of information that are passed along to be used by other parts of the system. Other parts of the system may contain conditional logic that considers the device as a part of its operation.

I think the word device fails to convey the flexibility of devices. A visitor to the website can start out using one device and then can switch to another device without leaving his browser. Devices could be used to try out new HTML using live content without disrupting the live site. I'm not sure "device" is the best English word for the concept, but that is the word that Sitecore uses.

How are devices configured?
Devices are configured under the /sitecore/Layout/Devices node. After you create a device, you can specify the browser agent value and/or the query string value that Sitecore should use to uniquely identify the device. These values can be changed at any time in the future, so you don't need to be too worried about making a mistake.

BTW, when you provide a browser agent value, Sitecore checks to see if your value is found in the User-Agent request header. Sitecore performs a case-insensitive search using IndexOf().

How does a device relate to an item?
When you want to view an item, you always view the item through a device. Therefore it makes sense that device settings can be configured at the item level. However, since all items that are based on the same data template are probably displayed in the same way, a better place to configure device settings is on the data template itself (using standard fields, of course).

By configuring the device settings on the data template you are setting a default value. You're telling Sitecore that unless the device settings are overridden on a specific item, these are the settings Sitecore should use. One of the device settings indicates which layout Sitecore should use.

Presentation Details
The section of the Sitecore user interface that allows a layout to be specified for a device is called "presentation details". Like I mentioned above, presentation details can be set on data templates and on individual items (though the former is preferred).

Presentation details in the Sitecore user interface.

The presentation details section displays all of the devices that have been defined. For each device, they layout that has been assigned for the device is displayed. This is tell you that when a certain item is viewed using a certain device, a certain layout should be used. These settings can be changed at any time.

The layout details screen lists devices and the layout assigned to each.

What's next?
Now that I've gotten through the absolute basics of content modeling and presentation logic using Sitecore, I'm going to move onto different topics. Hopefully some that won't take almost 10 posts to cover.

Want to learn more?

Tuesday, February 9, 2010

How Presentation Controls Are Used In Sitecore

My last several posts have covered controls (.NET and XSLT). The purpose of controls are to allow presentation logic and functionality to be reused. One thing I haven't explained is how controls are actually used.

Controls can be used in two ways. One way is probably pretty obvious: you can put presentation controls directly in a layout using web controls. Sitecore provides web controls for positioning sublayouts and renderings. Since Sitecore web controls are already ASP.NET web controls, they can be used as-is.







Positioning presentation controls directly in a layout is sometimes called "static binding". The words refer to the idea that the controls are positioned in the layout in a way that does not change.

Which leads us to the second way to position controls: dynamically. Using dynamic binding, a control is positioned in a layout by a content editor rather than a developer. If you're comfortable with the concept of variables, the approach Sitecore uses will make perfect sense:
  1. Developer creates a "placeholder" in a layout. The placeholder is given a name.
  2. Developer specifies the controls that a content editor will be allowed to put into the placeholder.
  3. The content editor selects placeholder he wants to position a control in.
  4. The content editor selects the control he wants to drop into the placeholder.
Step 1 involves inserting a web control into the layout. Step 2 involves configuration inside Sitecore. Steps 3 and 4 can be performed in a number of ways. The following video demonstrates how to do it using Page Editor.



Now, there is a little more to working with placeholders than the 4 simple steps I listed above. The missing piece is understanding how Sitecore knows to you the layout in the first place. That is key because the placeholder is defined in the layout.

What's next?
I just tipped my hand, but defining content and presentation only get you so far. In order for either to be useful, they must work together. My next post will cover how you tell Sitecore which presentation should be used for which content.

Want to learn more?

Friday, February 5, 2010

Renderings

Presentation controls are an important part of Sitecore's strategy for displaying content. When these controls are created using .NET they are either sublayouts or web controls. When these controls are created using XSLT then are called "renderings"

Renderings serve the same purpose as any other presentation control (they provide blocks of reusable presentation logic). They are configured in the same way (they consist of a definition item as well as a physical file). They are developed and deployed similarly (changes to the files the definition items point to can be changed and deployed without having to notify Sitecore).

The idea with renderings is that Sitecore provides a view of itself in an XML structure, which can be transformed into HTML (or whatever presentation format you want) using XSLT.










...
Sample of the XML representation of a Sitecore item.


XSL extension methods are used to display field values in renderings. Placeholders cannot be defined in renderings.

One of the nice features available to you when using renderings is the Sitecore Developer Center. This is a part of the Sitecore user interface where developers are able to work on and debug their code. The Developer Center includes a preview screen that allows you to watch your XSLT execute as you write it.



Changes to XSLT files can be previewed inside Sitecore.

XSLT or not?
Using XSLT in Sitecore is something that people tend to feel passionate about. I've heard the arguments (some of them, anyway), but there are 2 things that make me feel that - as a general rule - it's probably better to stay away from XSLT.

First, .NET code runs much faster than XSLT code in Sitecore. Some people argue that the proper use of Sitecore's caching features renders this a moot point. I don't know enough about how Sitecore caching works to know how many situations this holds true for. I know from working with other system that there are times when content just can't be cached. For example, personalized navigation.

My second issue involves code maintenance. Trying to understand someone else's code is seldom a pleasant task, but trying to understand someone else's XSLT code takes unpleasant to another level. With .NET code you have Visual Studio to help you in a variety of ways. I'm not aware of any way to debug XSLT code running in Sitecore. Sure, it might take 1/2 the time for you to write XSLT code, but I wonder if that efficiency evaporates when it's time for someone else to work with the code.

Still, it is important to note that renderings are not a gratuitous or deprecated feature. There are places they are genuinely useful. In cases where you need to traverse multiple levels of the content tree (building navigation links, for example), using XSLT is a fast and powerful tool.

What's next?
Now that we've seen how controls are created, the next thing to cover is how are they used. My next post will cover this topic.

Want to learn more?

Monday, February 1, 2010

Sublayouts and Web Controls

Previously I explained what Sitecore's presentation controls are and why they are important. At this point you're probably ready for some technical details. These controls can be written using .NET for XSLT. In this post I will discuss presentation controls written using .NET.

When creating presentation controls using .NET you have two choices: user controls (which are called sublayouts in Sitecore) and web controls. For both user controls and web controls, the advantages and disadvantages inside Sitecore are the same in a regular ASP.NET application. Which you use depends on what you're trying to accomplish. (Microsoft has a good article that describes the differences between user controls and web controls)

And the user controls and web controls are plain old ASP.NET controls. There is no special Sitecore class to extend or interface to implement.

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="HelloWorldSublayout.ascx.cs" Inherits="mysite.HelloWorldSublayout" %>

[Hello, world.]


Example of an ASP.NET user control.

All of your development can be done in Visual Studio. Inside Sitecore, you simply need to register the control. After the control is registered it can be used inside placeholders.



Creating a sublayout using Sitecore.

The video above demonstrates how a sublayout is created inside Sitecore. The user creates a sublayout item, and then Sitecore generates the ascx file. But there's a little more to it than that.

When the user creates the sublayout, Sitecore creates a definition item for the sublayout. A definition item is the object inside Sitecore that maps a logical component to a physical one. Definition items are used in several places in Sitecore.

In this case, the logical component is the sublayout and the physical component is the ASP.NET user control (ascx file). The definition item merely points to a file on IIS. The location of the file was specified on one of the screens in the "create sublayout" wizard and can be changed at any time using the Content Editor.

The important thing to note is that the physical file can be edited outside of Sitecore. After this happens, Sitecore doesn't need to be notified. All Sitecore cares about is that it is able to locate a file at a certain location when a specific resource is requested.

Pretty much everything I just wrote about sublayouts is also true of web controls. In order to create a web control you use a different branch of the content editor (Layout\Renderings instead of Layout\Sublayouts). The configuration of the definition item for a web control is slightly more manual than that of a sublayout (you need to point Sitecore to a specific .NET class rather than a file). But I see these as minor differences.

What's next?
Presentation controls can be written using another technology as well: XSLT. My next post will describe how XSLT can be used to create presentation controls.

Want to learn more?