But sometimes when I'm building a content management system, I'll provide pseudo page controllers to allow site admins to manage the functionality available on a given page . . .
My goal is not only to encapsulate what can vary, but to stick the encapsulated variability in a database, put a web based admin front end on it and let my resellers or end clients deal with it so I don't have to!
While the front controller pattern works really well for web applications, in more content heavy sites I find that clients want more control over their URL's than simple SES URL's like /article/7/My-Article-Title-Here.html. They want to be able to show (and navigate) richer semantic trees. Also, peripheral content is often driven by context. Going to the same article at /about_us/history/My-article.html and at /partners/archives/My-article.html often has to show different side bar content or site templates.
Finally, once I've written or customized a piece of functionality for a client (newsletter, discussion board, shopping cart, etc.), I like the idea that a non-technical site admin can configure and implement it in their site without me having to get involved in discussions about what page the function should go on or what properties should be set (those are important decisions, but my resellers handle that as part of the project management – I just provide them with guidance where necessary).
With a pseudo page controller, a site admin can use a web based interface to add, edit and delete pages on their site. I define a page as something that appears to be a distinct physical file. For example; about_us.html and contact_us.html are two separate pages, but articles.html?aid=7 (or articles.html/7/My-article-title.html – same difference) and articles.html?mode=list are the same page but two different screens (one might display an article view for article 7, the other might display a list of articles). To complete the taxonomy of views, articles.html?aid=7 and articles.html?aid=12 are both the same page (distinct virtual file name) and the same screen (distinct template), just different content, and a screen can have different skins and/or versions to allow for different look and feel or content display based on personalization or business rules.
The nice thing about the pseudo page controller is that if a client wants to have two different stores on the same site or a couple of newsletters, they can drop in and configure that by adding a page, selecting a “feature" from a list of customized standard features and completely custom features and then fill out a page (or few) of properties to configure the instance just the way they want it.
How do I implement this? Well, I used to use stub pages. Basically, every time an admin user added, edited or deleted a page, my page publisher would make all of the necessary file and directory changes to actually save a physical file at that URL which just set page specific variables and included the front controller.cfm. That worked, but I'm currently moving to URL rewriting which will pass anything beyond the server name as a “filepath" which is passed into my front controller which then looks up the page by unique filepath (the name of a page like "contact.html" may not be unique, but the file path such as /partners/contact_us.html must be by definition) and returns a fully loaded page with all of the necessary properties and methods to handle controlling and displaying that page (using composition for the feature, display, etc.).
I'm still trying to decide the most elegant way to handle longer URLs where I want the same pseudo file/directory path to set both the page and the content ID such as /intranet/employee/store/toys/Barbie/my-barbie.html where the /intranet/employee/store drives the page, /toys/Barbie sets the category and my-barbie.html is the unique products title within the category (or /intranet/employee/store/toys/Barbie/43/my-barbie.html if my_barbie's ID is 43 and for business reasons I can't force unique titles within a category). I have some approaches, but none of them are really elegant, so any ideas appreciated!