Check out To MVC... and Beyond. The author makes some good points. Possibly the most important point is that while web architectures are typically referred to as being MVC, they are very different from the MVC design as applied to GUI programs.
The MVC pattern ... was developed for use in a point-and-click GUI environment. Although the Web is arguably a graphical user interface, it is not a GUI: it is quite different from the event-driven, instant-feedback world of MVC's origin. Although they share the same rough object model -- there are objects in each that can be called Model, View, and Controller -- they should be known by different names. For this article, I will distinguish them as GUI-MVC and Web-MVC.
Where before the controller was responsible for many nuances of user activity, in Web-MVC its role is essentially reduced to a single three-step algorithm: read the servlet parameters, decide which data methods to call, and decide which view to display next.
On the other hand, the Web-MVC pattern deals with several questions left unasked by GUI-MVC. While GUI apps are mostly modeless, Web applications suffer from complex rules determining the transitions from view to view. These nuances of page flow and navigation usually find their way into the Controller role of Web-MVC. In more sophisticated frameworks (e.g. Blueprints, Struts) there are separate actors to handle these navigational tasks: gatekeepers, Screen Flow Managers, page flow configuration files, and so on.
And he points out exactly what I did in my last post:
[The architecture I describe] can apply equally well to an application with many pages, or with nested views. Nested views are a common technique. A given HTML page usually consists of several high-level components (viz. Title, Banner, Navigation Bar, Body, Footer). Each high-level component can consist of many low-level components (viz. Form, Anchor, Paragraph).
Each of these components can be factored into a miniature Model-View dyad. (The controller is usually superfluous at this level.) This is the approach favored by the JFC Swing components.
He also nails another technique I use:
Some architectures use a single servlet as a gatekeeper or dispatcher, responsible for receiving all input; this gatekeeper performs certain common tasks (e.g. authentication) and then sends the request on to either another object ... for processing. This does not qualify as a Big Ball of Mud; rather, all the succeeding discussion about controller servlets and view servlets applies, only pushed down one layer.
So yeah, I liked that article. I want more. 
You may also want to check out his article on Refactoring to Model-View-Controller.
One of the magic words of flexible programming is... say it with me now... declaratively. The more things you can specify declaratively -- in other words, what you want to happen rather than how -- the more flexible your program will be. That's why there's so much work with declarative languages, and why they can be so powerful. Furthermore, this is why regular expressions are so powerful, and why SQL is so powerful, etc.
But principles of declarative programming go far beyond the style of the programming language you're using. For instance, any time you can use a configuration file instead of something hard-coded in your code, it's far more flexible. Something in a configuration file that looks like foo=bar may look the same as something in code: foo="bar", but there's a big difference.
For my CMS, the templates are structured differently than anything I've seen. Rather than writing an HTML-looking template file with lots of "code" in it (things like "loop through all addresses, and print the name, address1", etc.), the templates have "sections" which simply serve as an anchor for content to go in. The sections can be filled in with any combination of "view components" or sub-templates, and maybe eventually actual output so you can specify what you want directly rather than having to have a view component for very simple things.
Then, in a configuration file, you just say (declaratively) "print my blogroll", "print my recent comments", etc... in other words, you can just specify the name of the view component you want. Right now, the "view components" are simply PHP functions that take data from the model and output whatever. But it's not ultimately limited to this. I could just as well specify the view component in a sub-template parsed by Smarty and compiled into a resulting PHP script.
I hope this will give me all the flexibility I want. In existing template designs the particulars of the data you're printing out are too tied to the template. In my system, you have instead a view component that is tied to the data given by the model, but the template doesn't have to know anything about what its sections are being filled with. Note that the sections can be as fine-grained as you want them to be, with a section for every view component that you're printing as the degenerative case, but usually with multiple view components for each section.
When I finally get all of this done, I'll probably have fun providing demos where I radically change the content of a page just by changing things in a configuration file.
The one downside is that currently the view components have to be specified as PHP functions. I don't currently have anything nice and neat like in MovableType. But, I haven't had to write my own template language 
, and maybe I can do something nifty with Smarty after everything is working neatly.
By the way, this is why I was so upset the other day that PHP doesn't have any kind of compile-time include. I have to use something like Smarty to get that kind of functionality.
Wednesday, January 8, 2003
Permalink
The Elegant Universe
Well I have finally found the crazyguy that preaches useless nonsencein A...
Joseph Baxter: Jan 7, 11:07pm