posted on 7:55 PM, July 25, 2007
This document describes, in moderate technical detail, how ExSite constructs web pages for display on client browsers. It is intended as a primer for technically-oriented graphic designers who will be tinkering with templating tools at an advanced level, and as an introduction to the ExSite content management framework for web developers.
Before reading this document, it would be wise to brush up on ExSite's Content Model.
OverviewExSite manages any number of websites (or website sections) that are collections of individual web pages.
Every web page produced by ExSite has both a static and dynamic representation. The static version is prepublished to disk, and is served as a traditional HTML document. The dynamic version is composed on the fly by the webserver, and served to the viewer immediately.
If the web page publishes to a simple HTML file and contains no recursive web applications, then the static representation of the page is the only one the public will normally see. A static web page typically has a URL that ends in filename.html. On the server side, this really is a simple, flat HTML file.
If the web page is configured to always render dynamically, then the dynamic representation is the one the public will normally see. A dynamic web page typically has a URL that ends in page.cgi?_id=NNN.
If the web page publishes to a simple HTML file, but contains web applications that may regenerate the page content, then the web page can appear both ways. The default view of the page will be published to a static file (and will appear as filename.html), but the page can be regenerated under different conditions (in which case subsequent page views appear as page.cgi?_id=NNN...).
In most cases, ExSite will automatically choose whether to display the static or dynamic representation of the page. Generally, it chooses the static representation (which is usually better for performance), unless one of the following is true:
Page identifiersPages can be referred to by their filename, or by their numeric page ID (the _id parameter to page.cgi). Either identifier can be used to locate the page.
Note however, that every page in the system has a unique page ID, but only pages in a particular site/section have a unique filename. If you specify a page by filename, ExSite will only look in the current site for a matching page.
How ExSite finds contentAll page content is located in content objects, which have various names (text labels) that identify the content. For example, a particular block of text might be called "body" because it comprises the main body of text on a page. An image might be called logo, or banner_ad, or MyPhoto, or PZ10114s.jpg. The names are arbitrary - it's nice if they are meaningful to you, but ExSite doesn't really care.
A page is a collection of references to different content objects (eg. text, images, stylesheets, etc.) that are assembled to create the final page. Each time a new content object is referenced, ExSite must find that content object somewhere in the system. Here is how it searches:
How ExSite builds a pageTo begin constructing a page, ExSite needs an initial starting point. It looks for a content object named page to begin. It searches for this content object using the above algorithm.
The page content object provides the initial HTML framework for the page. That is, when we load the page content object, and ask it for it's actual content data, we will receive a block of HTML that lays out the overall page structure, and will refer to other content objects that are needed to complete the page (such as images, stylesheets, menus, and text). These references to other content objects are specified using special tags in the HTML that are understood by ExSite (although they will look like HTML comments to any other HTML-handling program).
To illustrate, here is a very simple example of the type of HTML content that you might get in a "page" content object:
There are three special tags in this example that refer to other content objects that are needed to complete the page:
<!--$title-->This tells ExSite to insert the appropriate meta-data into this spot. Meta-data is not really content, but it can be inserted into the page just like content can.
[[logo]]This tells ExSite to insert a URL to the logo content object into this spot. ExSite will perform a search for logo (as described above), and when it is found, will determine the best URL to use.
<!--content(body)-->This tells ExSite to insert the HTML for the body content object into this spot. ExSite will perform a search for body (as described above), and when it is found, will determine the best HTML representation of the content to use.
Once these substitutions are complete, ExSite looks at the new, expanded, version of the page's HTML. New content references may have appeared as a result of the substitutions we performed, in which case, we have to repeat the process and search for the missing content, until no more references can be found. At that point, the page construction is complete, and it can be delivered to its destination - either the client browser (if the page is being rendered dynamically) or the publishing program (if the page is meant to be viewed statically).
More information on how to use substitution tags is given in the ExSite Templating Guide.
best practices (5)
content management (12)
data handling (7)
graphic design (21)
html formatting (7)
plug-in modules (28)
visual tutorial (29)
web protocols (9)