How Is a CMS Project Different from Regular Web Projects?

Although CMS is based on .NET and uses ASPX pages, CMS projects are different from typical Web projects. Most importantly, the ASPX pages that support a CMS site aren't run as themselves. What we mean by this is that the ASPX pages are run in the context of a posting (a Web page) within your site. When a user looks at a CMS-based site, they're really looking at postings, which are supported by templates. Templates, as we will see, are in part the ASPX files you'll be creating later and in part a template gallery item (covered later in this chapter). As a result of these differences, debugging your projects is a little different as well (we'll learn more about that in Chapter 12). Finally, when you create a new CMS Web application, a user control is automatically added to the project; this user control is the administrative functions provided by CMS and is referred to as the default console.

As we mentioned, CMS projects are not like normal ASP.NET Web applications, primarily because the ASPX pages aren't run directly. In CMS terms, the ASPX pages are essentially the support for postings added by a content contributor. Although, in truth, the ASPX pages are processed as they normally would be end users who view a CMS-based site never actually "see" the ASPX file directly. Instead, they see the posting.

For most Web applications, the developer chooses which ASPX page is shown to the end user. ASP.NET Web applications typically have one "container" (an ASPX page), hiding and unhiding controls based on events or operations. In a CMS-based site, content contributors choose which ASPX page (in the form of a template) they want to use when they create a posting. It's the choice of the content contributor which "container" is used to display content or functionality within a site. As a result, a developer has less control over what ASPX page is used and when. When that posting is displayed to some end user, its content is combined with the ASPX page and then rendered to the end user (we'll learn more about this processing in the next chapter). So, unlike a typical ASP.NET application, your CMS project will probably have multiple containers (ASPX pages), each possessing a unique content format or functionality mix. For some of you, this is a pretty big shift in the way that you need to think about developing Web applications. However, understanding this concept is key to creating effective CMS-based solutions.

As a result of this "there but not seen" environment that an ASPX page operates in, debugging is a little different. We'll go through a couple of debugging scenarios in Chapter 12, but it's important to understand that although debugging in VS.NET works just fine, you will start the debugging process differently with CMS projects.

Lastly, a CMS project includes a special user object. Similarly to how a typical ASP.NET Web application has a default webform1.aspx file automatically inserted into the project, CMS projects come with a user control called "defaultconsole." Unlike the generic webform1.aspx file, however, this user control is one of the core components you'll add to almost every template file you create. This user control will be created in a folder in your solution called "console."

In Figure 10-1, you can see what the Solution Explorer shows after we've created our CMS project.

Figure 10-1. A typical CMS project