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:
- ExSite Webware manages collections of websites.
- Each website is a collection of pages.
- Each page is a collection of content objects.
- 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:
- 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.
- 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.
- 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.
- 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.
Context
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.