• A categories.xml defines the structure (categories) of the website
• Ability to list images
• A settings.xml allows a webmaster to define any simple text settings like a site’s name, author etc.

Download prototype3.zip.

/categories.xml
I wanted a way to formalize the structure of the website. An XML Structure file is the obvious way to define a hierachical structure of category names with associated “main pages”. That’s basically what I did:

<?xml version="1.0" encoding="UTF-8"?>
<categories>
 <category name="Home" page="index">
  <category name="News" page="news">
   <category name="Local" page="news.local"></category>
   <category name="International" page="news.int"></category>
  </category>
  <category name="Views" page="views"></category>
  <category name="Gallery" page="gallery">
   <category name="Rossi" page="gallery.rossi"></category>
   <category name="All" page="gallery.all"></category>
  </category>
  <category name="Links" page="links"></category>
 </category>
</categories>

This allows us to create XSLT Functions or Templates which we can call to give us a navigation. The template for a horizontal navigation bar looks (in essence) like this:
/design/subtemplates/navi.xsl

 <xsl:template name="navibar">
 <xsl:param name="category">Home</xsl:param>
 <table class="navi">
  <tr>
   <xsl:for-each select="/site/categories//category[@name=$category]/*">
    <xsl:call-template name="naviitem"/>
   </xsl:for-each>
  </tr>
 </table>
</xsl:template>

It is then called from any page template using the following syntax:
/design/templates/page/simple.xsl

.
.
<xsl:include href="../subtemplates/navi.xsl"/>
<xsl:call-template name="navibar">
 <xsl:with-param name="category" select="’Home’"/>
</xsl:call-template>
.
.

One could argue that this is a propietary syntax but it’s not really. The syntax can be changed at any time by the webmaster by changing the template definition in navi.xsl. This is not something that is part of the CMS other than as a bundled example.

Settings
Any template can use site-wide settings or texts by simply including a reference to the /site/settings element. This is a simple XML file with all tags defined freely by the webmaster:
/settings.xml

<?xml version="1.0" encoding="UTF-8"?>
<settings>
 <site>
  <name>Demo CMS Site</name>
  <author>Jack Parker</author>
 </site>
 <option>My Option Here</option>
</settings>

So we can include the site’s author’s name in any template using XSLT:
/design/templates/page/simple.xsl

<meta name="author" content="{/site/settings/site/author}"/>

One could of course “misuse” this feature to define global styles or colors which can be changed centrally but that’s really the purpose of /design/styles/style.css.

Page Lists
Say we want to list some news articles on our news page with the newest first. We need a template which looks something like this:
/design/templates/subtemplates/lists.xsl

 <xsl:template name="pagelist">
 <xsl:param name="category"/>
 <xsl:param name="sort"/>
 <xsl:param name="order" select="’descending’"/>
 <xsl:variable name="child_categories" select="/site/categories//category[@name=$category]/descendant-or-self::category"/>
 <table class="pagelist">
  <xsl:for-each select="/site/pages/page">
   <xsl:sort select="*[name()=$sort]|@*[concat(’@',name())=$sort]" order="{$order}"/>
   <xsl:variable name="current_page" select="."/>
   <xsl:for-each select="$child_categories">
    <xsl:variable name="child_category" select="@name"/>
    <xsl:if test="$current_page/descendant::category/@name=$child_category">
     <xsl:call-template name="pagelistitem">
     <xsl:with-param name="page_node" select="$current_page"/>
     </xsl:call-template>
    </xsl:if>
  </xsl:for-each>
 </xsl:for-each>
 </table>

</xsl:template>

And we call the following in our page:

<pagelist category="News" sort="pubDate" order="descending"/>

Of course this will also include our main news.htm page because it is also in the “News” category. To exclude this we need an if statement:

<xsl:if test="$current_page/@id!=/site/categories//category[@name=$child_category]/@page">


As you can see, the XPath gets a little hairy at times.

Link Lists
I also tried out some simple link lists in infoboxes on the right.

This is called in the page using a similar tag to the <pagelist>:

<linklist category="Links"/>

The template is almost identical to the one above but calls a different template to display individual items.

 <xsl:template name="linklistitem">
 <tr>
  <td>
   <a href="{concat(@id, ‘.htm’)}"><xsl:value-of select="title"/></a>
  </td>
 </tr>
</xsl:template>


<xsl:call-template name="linklistitem"/>

Architecture

Demo Site

Basically the CMS could define a customization for the /projects/ folder and all subfolders and as soon as the user browses these folders in Windows explorer the GUI changes. They can have a different look and feel, different options when they select a file, CMS-specific tools like preview, publish, edit and customized file information on the left.

While I have not yet given up it seems that the following disadvantages are evident:

1. You can’t customize a folder and all it’s subfolders
2. The effort required to program extra functions is the same as an HTA
3. It doesn’t behave the same on Win9x, 2K, ME and XP
4. Security policies block many functions

That said, they are pretty cool. They save you all the effort of:

1. Displaying folders and files
2. Modfiying, renaming, deleting and copying files and folders
3. Folder, Navigation (back, forward, up) and the automatic tree view

For these reasons alone, it may be worth it to pursue the topic later. However, it may be worth a try to access the Active-X Object used to display the folder and use this in the HTA:

<object id="FileList" classid="clsid:1820FED0-473E-11D0-A96C-00C04FD705A2" tabIndex="1"></object>

Just need to find some documentation on this object…

Structure is the organisation of the pages in a website. This can be done in various ways:

• Flat structure - e.g. simple chronological blogs or basic wikis
• Hierachical
• Other?

Hierachical structures are probably the most traditional and common for websites.

Hierachies are structured logically to allow a user to browse intuitively to their goal (the page) and easily see other pages related to that page because they are in the same branch/folder.

There are however 2 types of hierachy which differ importantly:

• Strict Hierachy
• Loose Hierachy

Strict Hierachies
Here, each page resides in 1 folder. Most Operating Systems organise files in a strict hierachy. Hierachies such as this offer the additional advantage that a path is automatically available no matter where you are - the DOS path (/news/2004/october/) or breadcrumbs (news -> 2004 -> october). Hierachies are great!

Loose Hierachies
Modern Wiki’s and Blogs have no hierachy in the strictest sense because they either have no categories or they have a “loose hierachy” which means that pages can be in multiple categories and when you are on a single page, there are multiple possible paths which could get you there. Being on a certain news article could mean many paths and generating a single breadcrumbs navigation is not possible.

In summary, hard-hierachies (folders) are clear, strict and provide useful advantages in generating paths. loose-hierachies (categories) are flexible, easy to use and understand.

I envision using the windows folders and files in the CMS to implicitly define the site’s “Hard Structure” and offer an optional “categories.xml” to allow webmasters to defined a loose hierachy for pages.

See an example of this structure on Radio Userland’s Hierachy XML Format story.

<categories>
 <category name="Interests">
  <category name="Software"></category>
  <category name="Politics"></category>
  <category name="Art">
   <category name="Rennaisance"></category>
   <category name="Classical"></category>
   <category name="Modern"></category>
 
</category>
 
<category name="Philosophy"></category>
 </category>
  <category name="News">
  <category name="Events"></category>
  <category name="People"></category>
  <category name="Help Wanted"></category>
  <category name="Jobs"></category>
 </category>
</categories>

But what is “everything”? What types of websites are there out there? Can we list the main types of site which differ fundamentaly? I’ve tried to formulate a list leaving off sites which obviously require server side scripting (dynamic sites) such as forums, online stores etc.

• Blogs
• Wikis
• Directories
• News Platforms
• Portal
• Projects

I’m sure there are other types but I can’t think of any and there seems to be no other such lists on the web - at least I can’t find any.

A Wiki, in the classical sense, will not be possible with a static CMS because it require collaboration from multiple users. However a single user could create a Wiki for a private or publich Knowledge Base where he/she really is the only author.

Now I need to start thinking about what sort of CMS Framework would support all (or most) of the different types of sites.

• We’re adding propietary tags (contrary to guiding principles)
• XML Documents from 3rd party sources (docbook, word, rss, etc) would need this tag added

Particularly the second point is important if you consider importing 100’s of XML documents from an external system. Each one would need the <template> tag added. So, what’s the alternative? Folders!

Each folder has a corresponding template which is the default for documents in that folder. The pages in folder /content/pages/news/ would all have the template /design/templates/page/news.xsl applied by default. Of course the XML Author can specify another template using our trusty <template> tag.

Sounds great but: Folders introduce a new level of complexity in linking documents. With our old flat, single folder system linking was as simple as specifying the target pages name with the <a href="page.htm"> tag. As soon as you have folders you need to either:

• mirror the folders structure in your published site: <a href="/news/page.htm"> OR
• keep the flat site structure and rename published pages to (try and) ensure uniqueness of filename: <a href="news.page.htm">

Both options are equally complex (well, less simple) than the previous situation and the 1st option is more intuitive. We all like folders in our published site.

• Zero-Code - Try to minimize coding (read bugs)
• Stand on the shoulders of giants
• No proprietary languages/syntax

Run project1.bat to create the website. This calls cms.makesite.bat project1 In this way you can manage multiple sites by keeping them in seperate named folders components.xml contains re-usable Global Components (like a Header) which can be inserted into any page cms.makesite.bat uses sitemap.xml to get a list of all pages in the site and build a batch file to process them all with cms.makepage.bat cms.makepage.bat combines each pageN.xml with components.xml to ensure the template has access to both page and global components. cms.makepage.bat then uses the (currently hardcoded) template template/simple.xsl to produce pageN.htm in the folder site/ The resulting website  is in /project1/site/

Right click and choose “Save Link/Target as” to download the file prototype1.zip.gif. Then rename to prototype1.zip and unzip.

What about this?

All Components in the /component folder, seperated by context - Global or Page. All Templates in the /template folder, seperated by context - Global or Page. All binaries (files and images) in the /media folder. All Stylesheets in the /design folder. config.xml to bring it all together

TAL has 2 advantages over XSLT:

• It’s less complex
• It can be edited by any HTML editor

The second point is interesting becaus TAL introduces no new tags. You just design your HTML page as per normal but add attributes which define where your content goes.

TAL Snippet:

<html xmlns:tal="http://xml.zope.org/namespaces/tal" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title tal:content="document/header/title">Here comes the title</title>
</head>
<body>
…
</body></html></code>

In order to avoid having to write a TAL parser we can use a transformation to convert the TAL template to XSLT. Some bright spark has created the tal2xslt.xsl for us so all we need is xmlstarlet or other XSLT processor and we can create our pages with the following easy batch file:

xml tr tal2xslt.xsl template.tal.html > template.xsl
xml tr template.xsl page1.xml > page1.html
del template.xsl


Now I need to find a way to process a complete site…