Web server output generation design patterns
There are several styles of content generation that I know of so far...I'm reviewing them because I'm looking to see if there could be something better.
Flat-file
Example: plain ol' PHP
PHP, at its simplest, doesn't have any separation at all -- you can, if you choose, have all the programming/form-processing logic in the same file that renders the output to the browser. While simple, if you're creating a full website, this can be cumbersome and confusing.
Component Paradigm
Example: Java EE/JSF
Each page is an Application (code). Each Application has an Application Layout (html). Each Application Layout has a number of slots. The Application has logic that designates what Pagelets go into what slots, and what layout a particular Pagelet should use. Each Pagelet (code) has a number of layouts (html), only one of which is rendered per request. When the request is in the Application stage, there is only one thread, and the application puts into the request object most of what the pagelets will likely need (pagelets can do computations and service requests themselves too, of course, but it's hard to share the results between pagelets)
Phew. So the cool part about this design is that the pagelet components are (in theory) reusable. Additionally, all of the pagelets can be executed in parallel, which (since Java uses native threads) can result in major performance improvements. The application doesn't need to designate the pagelet-slot mappings in code -- it can be configured in XML (lovely...). On the other hand, since the pagelets are executed in parallel, this makes flushing content to the browser before the page is done rendering somewhat challenging.
I haven't explored enough to tell, but it looks like Java's offerings are heavily component-biased, with solutions like Tapestry that look potentially interesting.
MVC
Examples: Ruby on Rails, Merb, Ramaze, Sinatra (sorta), CakePHP, CodeIgniter
The request is mapped to a particular method in a class, with this class being called the Controller. This method performs some computations required for display, then renders the View, which consists of a template typically wrapped in a layout (another template that provides the header and footer). The template can include other shared templates, called partials in Rails-speak, but are generally just template includes. Models are essentially wrappers for database objects (see ORMs). Models aren't really specific to MVC -- any time you're calling a method instead of writing out a SQL query by hand you're probably using a model (or a utility class -- but that would be sucky).
In conclusion...
What other stuff out there, good or bad, exists or could exist? I'm planning on exploring, at least with my mind and possibly with code, what some of the other alternatives are. Anyone have any experience with other web design patterns that would like to share?