LoginRegisterCommercial SupportContact Us

Development & IT > The ExSite Content Model

The ExSite Content Model

posted on 4:51 PM, July 27, 2007
The 4-level content "stack".
This document describes how content is organized in the ExSite content management framework. This information is helpful for understanding how sites and pages are assembled and organized by ExSite Webware. Graphic designers and web developers may find this information useful if they are working with web content at more advanced levels.

The Content Stack

All web content is organized in a 4-layer hierarchy, which is illustrated in the diagram. The layers in this diagram can be summarized as follows:
  1. ExSite Webware manages collections of websites.
  2. Each website is a collection of pages.
  3. Each page is a collection of content objects.
  4. Each content object is a collection of data, or revisions.
Each of these layers is described in further detail, below.

Websites and Sections

A web site is a collection of related pages. They are also called "sections" in Exsite, because some web sites are so large that they are subdivided into multiple sections that have their own graphic designs, different editors and administrators, and so on. Functionally there is no difference between sections of a large site that serve a common purpose, and a collection of unrelated sites, so ExSite uses the terms "web site" and "section" interchangeably. Whether two sections are part of the same perceived "web site" or two different web sites entirely, depends on how you configure the administrators and URLs of the sections.

On the server side, a section is simply a folder (or directory) where the section's pages are published.

Sections can be nested to any level. That is, each section can be defined as a child of another section in the system. Server-side, the child section is simply a subfolder of the parent. Client-side, the child is typically displayed as a subfolder in the URL of the site, for example "http://foo.com/child", or "http://foo.com/child/grandchild". (Alternatively, you could configure it to show up as "http://child.foo.com", etc.)

How sections nest, and how they treat their URLs, depends on the section "type", which you define when you create/configure a section. The options are:
  1. Native Web Site

    A native web site is treated as a subfolder of its parent website. If it has no parent, then it is treated as a subfolder of the default site served by the web server. In other words, it will publish to a subfolder of the default DocumentRoot of the web server.

    You can define a native web site with no parent to publish to a blank folder. That means it publishes directly to the DocumentRoot of the web server. In other words, it will be the default web site served by the server.

    The publication location of a native web site is simply a folder name. ExSite figures out where to put this folder based on the site's relationship to other web sites in the system.

  2. Stand-alone Web Site

    A stand-alone web site always publishes to its own location, which is independent of other sites on the system. Your webserver must be configured to serve this location independently of the other sites on the server (eg. using a VirtualHost declaration, in Apache).

    The publication location of a stand-alone web site is a full directory path to the folder where the stand-alone website is served from. In addition, you need to specify the URL that the web site will be accessed with, since it cannot be inferred from the parent site, if it is stand-alone.

  3. Web Site Template

    A web site template does not publish anywhere, and is not publicly viewable. It is a collection of "model" pages, organized into a preconfigured site map, which can be used to quickly initialize a new web site of one of the above types.

  4. Remote Web Site

    A remote web site publishes to a remote server, using FTP. This feature has been discontinued in ExSite version 3.

Pages, Templates, and Libraries

Pages are collections of web content. They come in three flavours: regular pages, templates, and libraries.

Regular pages are conventional web pages, consisting of text, images, and possibly other types of content, all formatted for presentation to a viewer. Regular pages contain content objects that are specific to that page, such as body text, or images that appear only on that page.

Templates are models of pages, specifying design and layout, and marking where page-specific content should be inserted to create regular pages. Templates contain content objects that are used on every page that shares the same design, such as stylesheets, design images, and the framework HTML that defines the page layout.

Libraries are unstructured collections of web content, such as images or documents. Libraries contain content objects that are made available for sharing by the whole site, or stored for archival purposes, such as image albums, document repositories, and so on.

Content Objects

A normal content object is an entity that defines a particular piece of content, such as a block of text or HTML, an image, a stylesheet, etc. The content object gives the content a simple name (eg. "body", "photo", etc.) by which we can reference it, and defines whether the content is editorial or design in nature (which determines who can update it).

Editorial content is what the viewer is actually there to see; it is the real, substantial content of the site.  It is typically page-specific;  that is a piece of editorial content belongs on a particular page, and has a particular web address that viewers visit to view the content.

Design content is used to dress the site up in a "theme" or graphic design.  It consists of structural HTML, images, backgrounds, and stylesheets.  It is typically not page-specific, and the same or similar design elements will be reused across many pages.  For this reason, most design content is found in templates.

Content Data (Revisions)

For normal content objects, the actual viewable web content is stored in the content data layer. Each content data item is treated as a particular "revision" of the content object. Any number of revisions can be kept on file, but two are of particular importance:
  • current (or active) revision - this is the most recently published revision, and is the one the public will see when they visit the site
  • newest revision - this is the most recently added revsision, and is the one the administrator sees when previewing pages in a CMS tool
These will often refer to the same revision.  All remaining revisions are essentially archived copies of older content.

Restoring old versions of any piece of content can be done one of two ways:
  • delete the most recent version(s). This is called a "rollback".  ExSite will then make use of the most appropriate of the remaining versions.
  • copy the old version you wish to recover to a new version. This is called "promoting" the version. This has the advantage of preserving/archiving all other versions.


Each of the above layers in the ExSite content model knows where it fits relative to the layer above. That is, every piece of content data knows which content object it belongs to, and every content object knows which page (or template, or library) it belongs to), and every page knows which section it belongs to. Therefore, from any given starting point, it is easy to work backwards/upwards to find the website context we are working in.

We can also work downwards from any given point, although the logic is a little trickier. From any given website, we can find a particular page that best represents that site - we use index.html, by convention. From any given page, we can find a content object that best represents that page - we use the content object named "page", which ExSite assumes to contain the HTML framework for laying out the page. From any given content object, we can find the best content data to use - we simply take the most current version.

Since from any starting element, we can always work up to the website/section, and work down to the content data, we can construct the complete "content stack" consisting of one element from each layer, no matter where we begin from. This content stack is sometimes called the "context". ExSite often needs to know the context before it can operate on the page or content. For example, consider a content object called "logo" - if we want to know where on disk this content is published (if it is published at all), we have to go down in the content stack to the content data layer to determine if the current revision is a publishable file such as an image, and if so what the file name is. Then we have to go up in the stack to the page and section to figure out in which folder we should place this file.

Dynamic Content

ExSite also understands another, much more interesting type of content object, which is a Dynamic Content Object. Dynamic content objects are inserted into pages/content just like any other content object. They occupy an inline position, just like an image would. However, they serve as link that ties the page into a dynamic web application, and as an insertion point for that application to inject content into the page. When ExSite encounters the tag for a dynamic content object, it invokes the appropriate web application, passes it whatever parameters are noted in the tag, and waits for the application to pass back a stream of HTML content. That content is inlined in place of the original dynamic content object tag. There are programming mechanisms that allow this content to generate self-referential links and forms that re-invoke the web application, allowing for a wide variety of rich interactions.

Dynamic content objects and web applications are in charge of managing their own content data. They may use the same content data model that we've described above for conventional content, or they may use their own completely different data model [for example, pulling sales reports out of a database]. The details will vary with each web application.

Free-form vs. Structured Content

Most editorial web content is either free-form or structured. 

Free-form content is typed or pasted directly into a page by the site editor or administrator.  The approach to managing this content is not unlike revising a normal document, such as in a word processor.  You can cut and paste to move things around, place images where ever they suit you, and apply your own styles as you see fit.  The content is all stored in the content stack described above.

Structured content is not typed into the page by the editor, but is inserted pre-formatted by a Dynamic Content Object.  The dynamic web application knows about the details of the content's structure, what requires emphasis, how to link to extra information or other functions, how to format and align things, such as in tables and reports, and so on.  Each web application that has its own specialized data model will manage its own data, which may have no relation to the content stack.  The application will provide specialized forms for entering data, and other tools for manipulating or previewing the data.  In general the site editor cannot alter the presentation of the stuctured content, as this is strictly controlled by the web application.  However, the web application will usually provide CSS hooks (stylesheet classes and IDs) that will allow a graphic designer to apply their own presentation rules to the structured content.  For instance, you might want particular fonts, colors, or borders to be used in certain types of reports.  You can usually add these CSS rules to your templates, and they will kick in when the dynamic web application inserts its preformatted content into your pages.

Database Schema

Details on the database tables that hold CMS data can be found in the ExSite Database Guide.

Filed under: programming