Context Counts - The Importance of the Page Metaphor
When is a resource not just a resource? When its context counts . . .
In Praise of Pages
Why I don't love Fusebox, Mach-II *or* Model-Glue!
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.
Page as a Fundamental Metaphor in Web Applications
I find that for the vast majority of applications I build, the idea of distinct HTML pages (the idea as opposed to actually having them) is incredibly useful. Even for “application” style projects it is often useful to be able to have help and FAQ and contact pages even if the vast majority of the functionality is more event driven.
I also find the ability to describe a site as a number of pages within a hierarchy with the top level pages being different sections as a very useful way to allow business users to describe common requirements for secondary content areas (“in the about us section I’d like to display a list of testimonials in the sidebar but it the catalog section I’d like to display cross sells instead"). There are definitely plenty of ways of implementing this using a simple event driven architecture (if you think about it a unique page file path can be seen as an event name so you can implement a pseudo page controller easily in MG or M2 with a little URL rewriting if you choose to), but I find the richness and usefulness of the metaphor to be great enough to justify building the concept of pages into LightBase.
It also allows for easy reuse of functionality as a non-technical user can use an admin screen to add a page to a site, select from a list of features, and parameterize the feature easily so a non technical user could add new discussion group or commerce pages to an existing site without programmer support.
I just wanted to mention this as future articles will treat the page “scope” as a fundamental element of a request. And to clarify, the page scope is the set of parameters that a user associated to a given page URL when creating the site – not variables within a given page request which is the request scope and (in LightBase) is contained within the RequestObject.
Page scope includes the default object, action and modifier (which between them fully describe an event for the primary content area) as well as the page name, section name and any default properties (such as the default category ID or number of records per page).
