[eluser]WanWizard[/eluser]
As the brits say, "all ten and six pence".
In a modular application, you should use templates to generate your pages. A template contains the basic div structure of the page, and uses some method to dynamically include the content of the page into the defined content area's. How you achieve this is entirely up to you, and depends a bit on how you want to deal with the dynamic content.
Some people simply create an array in the controller, render the different dynamic content blocks (views?) there, pass the array to the template and echo it. Or they pass an array with view names (partials), which get fetched in the template. For me, that doesn't fulfill the requirement of modularity, as you still 'hardcode' it, but then in a controller.
My applications use only a single controller, with a single method. I have a route that routes all URI's to that method. The method parses the URI, fetches the page definition from the database (including theme, template, regions and all widgets per region). It then passes that information to the template engine (I use a modified version of Colin Williams' template library). When the template is rendered (or parsed, depending on the template parser used), it does callbacks to module controller/methods that produce the widget output.
Result is an application framework that is completely resuable. All I have to do is make the templates (design the layout), determine which widgets the application needs, and get those from the stack of widgets I've build over the years. And if need be write new ones.
Note that even the body of every page is a widget. For example I have a module called 'blog'. In contains the controllers, models and views to generate the blog view pages, the index, the admin section, the edit pages and sidebar widgets for things like 'last 5 blog entries'. If I have a client that needs a blog on his site, I copy the module in, define the page, sent out the invoice, job done .
