The conception, birth, and first steps of an application named Charlie

Subscribe: Atom or RSS

The Raw Approach is Simple and Flexible

by Alister Jones (SomeNewKid)

I finished my previous weblog entry by saying that I believed the simplest and most flexible way to style an article webpage would be to use a “raw” template, similar to the following:

<html>
    <head>
    </head>
    <body>
        <h1><this:Title /></h1>
        <this:Content />
    </body>
</html>

If you looked carefully at the last screenshot in that previous weblog entry, you would have noticed the following wording: “Note: Changes here will apply only to this single article. To update the template for all articles, edit the ‘ArticlePage’ template within the Templates folder.” If it is not already obvious, the idea is that a particular type of webpage (such as an Article, Weblog Entry, or Photo Gallery) would have a default template that would apply to all webpages of that type. The website owner is able to update these default templates.

In addition to being able to update the default templates, the website owner may override the template that will be applied to a specific webpage. If one article is a review of the latest album by Bruce Springsteen (I am not hip to any music released this century), then the website owner can update the template so that it includes a large image of Bruce before the article, and a graphical affiliate link following the article.

<html>
    <head>
    </head>
    <body>
        <p>
            <img src="/images/BruceSpringsteen.jpg" />
        </p>
        <h1><this:Title /></h1>
        <this:Content />
        <p>
            <a href="http://www.amazon.com?123456">
                <img src="/ads/Nebraska.gif" />
            </a>
        </p>
    </body>
</html>

The first benefit here is that a system of default-and-specific templates is very flexible. If you have ever tried to “tweak” a site-wide master page—so that a specific page is just a little bit different—you will know how frustratingly inflexible a master page system can be.

A second benefit here is that those website owners who want to dabble in HTML can do so. HTML is a wonderfully simple technology that is easy to learn, and it would be disrespectful to hide the HTML away as if to say to the website owner, “You’d just screw it up, so we’ve put it out of your reach.”

But what about website owners who do not care to dabble in HTML? There are two approaches that we can take to support website owners who want to control the look and feel of their websites, but who do not want to learn HTML.

The first approach is stay at the same “raw” level, but to abstract some of the HTML. Here is an example:

<html>
    <head>
        <insert:Style name="Daylight" />
    </head>
    <body>
        <insert:Image name="Bruce" />
        <h1><this:Title /></h1>
        <this:Content />
        <insert:Link to="www.amazon.com?12345"
                     image="/ads/Nebraska.gif" />
    </body>
</html>

What I like about this declarative approach is that we can extend it to support localized text.

<html>
    <head>
    </head>
    <body>
        <h1><this:Title /></h1>
        <this:Content />
        <insert:Text name="Disclaimer" />
    </body>
</html>

We can also extend this approach to insert common elements such as the headers and footers.

<html>
    <head>
    </head>
    <body>
        <insert:Snippet name="Header" />
        <h1><this:Title /></h1>
        <this:Content />
        <insert:Snippet name="Footer" />
    </body>
</html>

We can also extend this approach to insert elements from other plugins. Here is how a homepage might look.

<html>
    <head>
    </head>
    <body>
        <insert:Snippet name="Header" />

        <h1><insert:Text name="WebsiteTitle" /></h1>
        <h2><insert:Text name="WebsiteSummary" /></h2>

        <insert:Text name="RecentWeblogEntries" />
        <weblog:Listing recent="5" />

        <insert:Text name="RecentPhotos" />
        <photos:Gallery recent="5" />

        <insert:Snippet name="Footer" />
    </body>
</html>

Remember now, most of this template stuff was automatically created by the Wizard of a turnkey website, or by the developer of a custom website. The website owner does not need to touch this simple declarative templating unless he or she wants to make changes.

But what about the website owner who wants to control the look and feel of the website, but does not want to muck about in this declarative templating? The alternative approach is to introduce a pretty graphical user interface.

What is notable here is that this graphical user interface builds upon the declarative templating. Why is this notable? Well, if we had started with a GUI, we would have used logic to generate the resulting page:

Homepage homepage = GetHomepage();

TitleLabel.Text = homepage.Title;
SummaryLabel.Text = homepage.Summary;

if (homepage.ShowWeblog)
{
    WeblogEntryCollection entries =
        Weblog.GetRecentEntries(homepage.WeblogNumber);
    WeblogGridView.DataSource = entries;
    WeblogGridView.DataBind();
}

if (homepage.ShowPhotos)
{
    PhotoCollection photos =
        Photo.GetRecentPhotos(homepage.PhotoNumber);
    PhotoGridView.DataSource = photos;
    PhotoGridView.DataBind();
}

If we had started with the GUI and ended up with code like that above, we’d have one hell of a hard time retro-fitting a templating system that allows a website owner to make little changes here and there.

However, we did not start with the GUI. Rather, we finished with the GUI, where it simply provides a way of cloaking the declarative template. The template is still there, but it is hidden behind the GUI. But because the template is still there, and because the default-and-specific templating system is still there, we have not sacrificed the flexibility of the original “raw” approach to styling a webpage. If the website owner uses the GUI to define the default template for articles, he or she can still override the template that will be applied to a specific article. Now we have the friendliness of a GUI for the default template, and the flexibility to hand-craft the template for specific pages.

With this approach, we have now accounted for each of the three website owners in our little story. Tom was satisfied with the Wizard. Michelle was satisfied with the Control Panel. Joshua is satisfied with this flexible templating system.

What I have not yet discussed is how the settings in the Control Panel will apply to the declarative templating system. I’ll discuss that in the next weblog entry, as it highlights the flexibility provided by this declarative templating system.

by Alister Jones | Next up: The Raw Approach is Extensible

0 comments

----