| Figure 27-1 provides an illustration of a placeholder within the CMS Context. There are three forces at work within a CMS placeholder: A placeholder definition identifies the characteristics of information that can be captured. This content type is stored in the CMS Repository database as part of a specific template definition. A placeholder control governs, based upon the current Web Author mode, the appearance and interaction of the rendered user content. It is stored in the file system and is generic for all template placeholders. NOTE: The Web Author is covered in depth in Chapter 5 and further explored in Chapter 30. Details about placeholders themselves are examined for each placeholder type in Chapter 13.
A Placeholder object contains the specific instance of the placeholder being rendered, including the user content. It is hydrated with user content stored in the CMS Repository database for a specific posting's placeholder.
Figure 27-1. CMS Context 
In CMS, a TemplateDefinition must be related to one and only one template file. A PlaceholderDefinition within the TemplateDefinition identifies the characteristics of content that can be captured, and may be related typically one-to-one with an ASP.NET-based Web server control (see the ASP.NET Control Options sidebar) positioned on the associated template file. ASP.NET Control Options ASP.NET provides several different controls that can be used to piece together a Web page. Out of the box, the .NET Framework supports all of the following: Traditional HTML: HTML tags like <form><input type="text" /></form> are still available. HTML server controls: Tags that relate one-to-one with traditional HTML tags but that the Web server is aware of. They can manipulate, bind, populate, respond to, and render in browser-specific traditional HTML tags, including JavaScript if necessary. These typically look like <form runat="server"><asp:TextBox runat="server"></asp:TextBox></form>. Tags that have both the asp: and runat="server" tokens are characteristically built-in HTML server controls and are automatically handled by the .NET Framework. These tags must be within a <form> tag with runat="server". Each page class can only have one <form> tag with runat="server". Web server controls: Tags associated with a class that is used to generate its output. These are typically more abstract and complex than HTML server controls. In a Win32 fat client environment, these would be the equivalent of an OCX control. They are self-contained, compiled components that can be dropped onto any ASPX page. They contain the display logic for their user interface and can also sport properties, methods, and even events. ASP.NET has some built-in controls, like the DataGrid and Calendar, that qualify as Web server controls but can be accessed in the same way that HTML server controls are accessed. However, custom Web server controls require an @ Register directive with a unique TagPrefix that is used by the custom tag to relate the control with the class that will be used to render it. An @ Register directive looks something like <%@ Register TagPrefix="myCtrl" Namespace="MyNamespace" Assembly="MyNamespaceOrAssemblyName"%>. The tag for this custom Web server control would look something like <myCtrl:ClassNameWithinNamespace runat="server" CustomProperty="1"></myCtrl:ClassNameWithinNamespace>. These tags must also be within a <form> tag with runat="server". Validation controls: Tags associated with one of the previous two types of server control. These are used to test input that a user enters into the control. This is typically done client-side, but on downlevel browsers this validation might be done on the server. The control detects this and generates the necessary code for the given situation. Web user controls: A Web user control can have everything that a Web Form can have. In fact, removing the <html>, <head>, <body>, and <form> elements from a Web Form (these must be in the hosting page) and saving the result as an ASCX in the same project as the hosting ASPX page is normally the way a Web user control is created. These are typically used for creating reusable page elements like menus and toolbars.
Additional documentation is available for each type of ASP.NET control on MSDN or in VS.NET help. |
The Web server controls in a template file are called CMS placeholders, and they provide the user interface in both the authoring and presentation modes of the Web Author. For instance, in authoring mode, an HTML placeholder is rendered as an object that looks like a fancy text box allowing a user with sufficient rights to edit the contained content, but in presentation mode, the contained content is simply rendered surrounded with <span/span> tags only allowing the user to view the content. This is all managed at runtime by a Placeholder object that is instantiated and hydrated with the contained content typically from the CMS Repository. The @ Register directive used by a CMS placeholder server control looks something like the following: [View full width] <%@ Register TagPrefix="cms" Namespace="Microsoft.ContentManagement.WebControls""  Assembly="Microsoft.ContentManagement.WebControls, Version=5.0.1200.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
The placeholder tag looks something like this: [View full width] <cms:HtmlPlaceholderControl runat= "server" PlaceholderToBind="NewHtmlPlaceholderDefinition1"> </cms:HtmlPlaceholderControl>
where cms: relates back to the @ Register directive with a TagPrefix equal to "cms", HtmlPlaceholderControl is the built-in CMS class that will be used within the Microsoft.ContentManagement.WebControls namespace (found in the Microsoft.ContentManagement.WebControls. dll referenced by the VS.NET project), HtmlPlaceholderControl1 is the name that code would use to reference this control, and NewHtmlPlaceholderDefinition1 is the name of the PlaceholderDefinition that this control will be related to in the template that is related to this template file. Web user controls are typically used to create the header, footer, and navigation sections of a template file. The CMS placeholder construction is somewhat analogous to the way that XSL is used to transform XML into HTML. Consider that an element within an XSD identifies the characteristics of information that can be captured, and may be related one-for-one with an HTML element positioned on the document to be rendered. Those HTML elements provide the user interface at runtime for the XML hydrated with the contained content. XSL is like CMS, XSD is like a PlaceholderDefinition, HTML is like the placeholder control, and the XML is like the Placeholder object. Placeholders keep the part of the page that can be edited by users separate from the page design. Formatting and presentation for whatever content is ultimately provided is determined in advance by the template and hence the template file on which the page is based. Placeholders can contain HTML, XML, images, or attachments, but, if needed, custom definitions can also be created. When the posting runs, the placeholder is rendered on the page using the associated content from the CMS Repository. A Placeholder object is inherited from CmsObject, but the PlaceholderDefinition is inherited from CustomReflectableObject. The result is a very different parentage from that of a channel or a posting. For instance, both objects have constructors. The following sections explore the structure of the Placeholder object class followed by the structure of the PlaceholderDefinition class, and then the unique properties of each type of placeholder. |
