In Praise of Pages

For most applications, a major goal for developers is to program in a language that is relatively comprehensible to the client who has to specify the requirements. If you're coding for loops and they're talking insurance coverage rules, that mismatch will typically make both specifying and maintaining the code more difficult than it needs to be. This is one of the big drivers of Domain Specific Languages - allowing programmers to write solutions that (at least at a high level) are described in terms of the problem domain.

One of the big trends in ColdFusion frameworks has been the move from a page controller model to a front controller. In this posting I am going to argue that for many use cases this is not a great choice.

For true web applications, an event metaphor works quite well. I like the Fusebox style naming convention of circuit.fuse that a number of MG and M2 developers also use. So URLs like index.cfm?event=cart.add are quite appropriate for web "applications".

However for web "sites", I find that most users think of a site with sections (often relating to topbar links) that are comprised of a number of pages and I often get requirements such as "in the about-us section, have a list of testimonials in the right hand sidebar" o all of the pages to describe secondary content area functionality.

Of course, there are a number of ways of implementing this in a front controller, but because events don't have a natural hierarchy (I guess you could have an n-dot notation with event=about-us.history.founders.peter.moreinfo but I haven't seen that in the wild).

However, given that the user already thinks in terms of pages which have a parent, section, display order and the like, why not just have a page object and use that to drive the functionality to present?

The main downside of traditional page controllers (such as those common in .NET applications) is that if they aren't designed well you actually have real controller code in each page, so if you want to have three pages all of which implement an article list, you'd have to replicate the controller code or make all three requests go to the same file. To me this is an unacceptable coupling between file system and functionality, but it is very easy to implement a "page controller" (in the past I called it a pseudo page controller) where you just use pages as a metaphor and then route to a front controller that takes the properties of the requested page and uses that to drive the functionality to display.

Such a solution allows for the conceptual comfort (for users) of a site with pages while still allowing for the code reuse benefits of a front controller as a page doesn't include any code - it just sets some properties that will affect what code to run.

So, how does this work in practice? Well, firstly you need to have a way to represent pages. You could just create files manually in a directory structure, make them set a few properties (Page.Title, Page,SectionName, etc.) and then include the front controller, but we keep pages in a database to make them easy to use and then either generate stub pages or (preferably) use URL rewriting to pass a file path to the front controller (say filepath=about-us/history) which then asks the PageService to return a loaded Page object with the necessary properties.

For the primary content area we allow a page to define a feature to use (a controller - catalog, cart, article-list, etc.) and a default method to run (cart.list, catalog.categoryview, etc.) as well as any properties to configure the feature if you'd like the article list on this page to be a little different from the article list elsewhere in your site. In this way a non technical user can easily add pages to a site and select pre-built features, so if you've coded a calendar for the about-us/events page and they want to add it to a new contact-us/holidays page then they can do so without help from a programmer.

More importantly, with a page model, you can easily write controllers for secondary content areas (maybe a right hand sidebar) saying things like "If Page.SectionName EQ 'about-us' then call the testimonial-list feature" which makes for a really expressive set of controllers for any secondary content areas.

The page controller model provides for extremely search engine friendly *and* meaningful URLs, allows end users to manage the URLs (so you don't have to be involved in changing all the event names to make them better match your new key word optimization strategy when the new marketing guy comes in), provides for the reuse of functionality within a site by non-technical users and makes it easy to describe secondary content areas using concepts like pages and sections that are fairly intuitive to business users. And because the pages don't actually have any code, there are none of the downsides experienced with old style page-controllers.

Of course, if you are building true web applications where a page metaphor is inappropriate or meaningless to the business users, an event based metaphor makes more sense, but for the applications I build I have found a page controller to be much more flexible and maintainable.

I know that you can conceptually implement any of this using an event based model, but I really don't see why you'd bother! Any thoughts?