Page as a Fundamental Metaphor in Web Applications

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).