Architecting your Views: Describing the Requirements

Design Requirements
When I sat down to architect my CMS (well, actually it is my LightBase framework, but I’ve decided that a framework can learn a lot from a CMS!), I had the following design requirements:

• Page Templates - The ability to set page templates to be used sitewide along with support for business rules allowing different pages, sections, users or even times of day to drive the page template used to render a given request.
• Multiple Dynamic Content Areas - I can’t remember the last time I designed a site that might not have the need for a dynamic right bar showing articles relating to the practice area, products relating to the current category or something similar. The system had to support multiple dynamic content areas. For the sites that don’t need that, the 1..n content areas would just be 1.
• Reusable Screens - It is quite possible that different parts of a site might reuse the same screen. For instance, order view in my account may be the same as the order view on the thank you page (and email) in a commerce system.
• Extensible UI Components - If I never had to write another table or form it would be too soon. While a simple data grid is often not flexible enough, I wanted to have reusable session aware data grids supporting ordering, filtering, paging and a range of display customizations and capable of rendering in HTML (eventually I’d add the option of rendering using AJAX or Flash). I also wanted to be able to generate most of my form displays by calling the appropriate “form” component.
• Snippets - When end clients want to be able to manage a page, I can give them a page or article admin (article admin where there might be > 1 article per page). When my resellers want to manage the layout of a checkout screen, I can provide them with easily editable HTML+ templates. The problem comes when the client needs to be able to add a custom message to the bottom of the shopping cart or under the drop down list of shipping methods that they want to change daily in the run up to Christmas. Snippets are a simple object comprised of a name and WYSIWYG description that my resellers can place anywhere in any template and the end users can manage using the admin system.
• Separation of Concerns - There should be as close to zero code on template pages to make it easier for designers to maintain and as few graphic design decisions in the code allowing the scripts to be completely re-skinned for different sites.
• Declarative Specification - As much as possible I want to replace custom scripts with standard libraries and a set of declarative properties which I can store in a metabase and efficiently reuse across thousands of applications.