IapetosCMS -- Overview
The Iapetos Content Management System, called CMS, is designed to make it easy to write good looking websites that are collections of html pages.
Development Model
We edit websites using the Eclipse platform that has had the standard Web Authoring tools installed. This gives color highlighting, spell checking and tag-completion as standard editing features. CMS is not tied specifically to Eclipse, and can be used in other tools, but this is our tool of choice.
We also use a Version Control System running on a server in our offices that keeps the "official" copies of all of our websites. By using a revision control system we also have a complete revision history. (At least going back to when we started using Revision Control.)
This type of server also makes project management a snap, since Eclipse tracks changes to and from the Version Control System server. This also makes it possible for more than one person to work on individual web sites. Currently we use SVN as our Version Control System, though we began several years ago with CVS and may move to Bazaar once it's integrated with Eclipse.
Each laptop set up for website editing is running a copy of Apache so that websites can be tested from within Eclipse. The ".lan" extension replaces the standard ".com" or ".org" extensions in the laptop browser window for testing the local, or ".lan" copy. Other than the extension in the browser, the rest of the website content looks identical in the local copy and in the production copy.
Eclipse also provides integrated support for Ant build scripts and we typically automate the deployment of websites. Once a website is debugged and running OK from inside Eclipse, it is a simple matter to deploy that website to the server using a couple clicks to kick off an Ant based deploy from within Eclipse.
Website Model
CMS uses the file system directory structure as the model for the website. Someone building a website using CMS is building up a hierarchy of articles in a directory structure. It is possible for individual pages to diverge from this model, drawing data from other places, or by capturing any additional path on the URL as parametric data, but at the highest level the website is a collection of files taken from and forming a directory tree.
In normal practice the top most directory determines the section of the site that the article is in. There are typically 3 levels of directories, though of course more or less are possible. When building sites we typically plan out the site using 3 levels even when there is not enough material to warrant this depth since websites have a tendency to grow over time.
The path part of the URL calls out a page from within the directory structure. Pages themselves typically exist in an "index.html" file but that file name is not supplied on the URL. Apache automatically adds the index.html file name to the path in order to find the page. This effectively makes each article into a directory, and provides a convenient place to put additional parts such as article related artwork.
The website page model maps to the underlying file system directories on both the web server and the development laptops. That directory structure has been carefully set up so that individual Eclipse projects can be managed and debugged locally and then converged into a well organized set of files on the web server.
Page Model
CMS uses a 7 part page model. The actual page seen by a website visitor are composed from individual files that make up these 7 parts. CMS does not enforce what those 7 parts are used for, it is up to the author of specific websites to plan how these 7 parts are used. Though there are some strong conventions used across most websites in the industry that suggests how those 7 parts should be used.
The center of all pages is the page content HTML, typically an article of some sort. Someone writing an article focuses primarily on the HTML that goes into the center of the page. There are standard CMS tags that go at the top and bottom of the HTML file that will cause the other 7 parts of the visible page to be brought together for final display in a browser.
The goal was to make writing HTML pages very easy by introducing a few simple header tags that are mostly boiler plate. Leaving the article content in a standard limited subset of HTML.
The other 6 parts of the page are filled in using content from files collected from a cascade that begins at the root of the directory structure that makes up the website. So, for each of the 6 additional parts, an html fragment is placed in a file in the directory structure above all the pages where it should be used. Its existence triggers its inclusion in all articles located in sub directories.
The following are the 6 possible additional parts that can surround any specific article page:
- Top The top of all pages across a website. The top is typically shared by all pages on the site. The top typically includes website banners, next/prev links, navigational menus and so on. (File: top.html)
- Bottom The bottom of all pages across a website. Like the top, the bottom is typically shared by all pages. Typically the bottom contains lesser used information, like contact information and access to feedback forms, search and so on. (File: bottom.html)
- Left The left side of all pages is typically the navigation for a section of a large website. (File: left.html)
- Right The right side of all pages. Lesser used, but available. (File: right.html)
- Header The header is inside the middle of a page and displayed at the top of the middle. (File: header.html)
- Footer The footer is inside the middle of a page and typically includes such things as foot notes. (File: footer.html)
Note that individual articles can add to any of these 7 parts by placing html fragment files in the same directory as their index.html files. These fragments can also be scattered throughout the directory structure above the individual article files causing various effects.
Tag Model
CMS uses an extensive set of customizing tags that accomplish various purposes when the page is displayed. Tags are processed in the Apache server when there is a request for the page received from a browser. CMS tags are reduced to Python calls and processed through Python Server Pages, a facility of the Apache mod_python module. This general structure makes it possible to add Python programming code to indivual web pages if it should be needed. The available set of tags are robust enough that this is rarely needed.
Tags are supplied in sets, and it is possible to write additional tag sets in Python. The base set of tags provides common functions for html pages.
All tags from a specific tag set begin with the tagset name, so for example, the <base:html> tag has the word base to indicate this is a tag from the base set. This is the tag that typically opens a CMS page.
All tags follow the standard HTML conventions dealing with opening and closing of tags. So, the preceding example needs a matched </base:html> tag at the close of the page. HTML editing tools, like those supplied with Eclipse, know this structure for HTML tags and can provide typing assist for these sorts of tags.
Script Model
Though javascript has been available in browsers for over 10 years, the differences between browsers has made javascript impractical for most website development. In an earlier, PHP based version of CMS, pages had to return to the server for help with nearly all interactive features since javascript could not be reliably used to add that functionality.
This has changed with the widespread availability of the jQuery cross-browser javascript library.
The library itself normalizes the various browsers, so for most operations all browsers can be considered alike. It also radically changes the coding model of javascript, supporting what is called unobtrusive javascript. This style of page design completely decouples the HTML from any supporting Javascript, changing, and dramatically simplfying the process of developing high-quality, high-function web pages.
CMS includes, and depends heavily on jquery and related plugins to provide in-browser customization on nearly all pages.
All page loads automatically include a compressed version of the jquery library as well as 2 key plugins: jquery.history and jquery.cookie. The CMS libraries also include a standard set of jquery plugins that supply runtime for several additional CMS related tag features that are best implemented in the browser.
There are a series of additional javascript based jquery plugins that deal with specific pages. This includes, for example, a standard jquery plugin for dealing with comment pages. There are tags for calling out these additional libraries on specific pages.
The general intention of the CMS design is that the HTML sent to the browser, search engine, or spammer is simple enough that search engines can understand the content, there is not enough information for nefarious purposes when automated spammers view the page and there is a functioning DOM, Javascript language, and jQuery library that can decorate the page when a real browser, and most likely a real person, is running the page.
The best example so far is the standard "Bible page." Follow the bible link in the footer of this page for an example.
Tool Model
CMS also provides various tools that are run when the website is deployed. These tools discover and collate data about the set of articles that make up a specific website. This data is used by various tags to supply specialized data in web pages.
For example, the next-previous tool studies the menu structure of the website to determine what the page order is for someone reading through all pages on a site. The set of next/prev links for all pages is stored as part of the website when it is deployed and provides the data behind next and previous link tags.
An Index-To-Scripture-References tool generates the Scripture Index for the site.
Another tool generates a list of all articles, typically called the Sitemap.
There are also various tools for dealing with Bibles in various formats and converting them between formats. Bibles are typically compiled into python ".pyc" files for use in the running web server.
Configuration Model
There are an extensive set of configuration options and default values that are supplied in PythonOption tags in the Apache VirtualHost tag or as part of an .htaccess file.
This includes setting the tagsets available on pages, style sheets and javascripts that should be included in all pages, and extensive options dealing with email back to article authors.