How Many Tiers for a Clean View Layer?

An interesting possibility cropped up for my MVC a few weeks ago. I've been working with microformats on and off the last few months (you can read about one of my first adventures with them when I created a microformatted resume). I started to wonder where else my site could use this new feature. An easy place to add microformat tags are links - you can add a 'rel' attribute that describes the relationship of the link to your site. Also, if I added a layer of abstraction to my links site wide, then I could easy add behavior rules (target="_blank" and whatnot) that would affect an individual link across all of my pages and sites.

This idea would involve creating a table of all my links, internal and external, that could be mapped to meta information about the links. There would be a helper class on my site that would pull a link based on an alias, give it attributes based off of the meta data (including microformatting), and spit out a final link. No where on my site would I have a manually written link tag. Everything would be wrapped and packaged by the helper class.

The idea of a helper class wrapping up a typical DOM element within a presentation layer started to make me think more. Up until now, I had treated the controller-view presentation layer very loosely, focusing more on my data layer. The controller pulls object information from the data layer, tweaks it accordingly, picks out a view, and spits out the information into it. The view only loops through arrays and echoes out data. If I wanted to do a view-inside-a-view, the controller had to do twice as much work. Also, if I wanted to add helper classes for links, I'd either have to add more logic to my view or clutter up the controller with view logic. I needed a better setup.

I work with an interesting framework at my job that is somewhat similar to Joomla. Modules are packaged pieces of logic that can be inserted anywhere on a page. They include a controller and view piece (and optional model logic). While they sometimes require a specific chunk of data to be passed in (in relation to the page content), each module is pretty much a stand alone piece of the page.

One possible solution for my MVC would be to break up the 'view' logic into separate entities. There would still be a controller that sets up global pieces for all views contained on a page. The controller would kick off a template file, which can be thought of a page view, that has placeholders for different view pieces. When a new view piece is loaded, an initial file is triggered that reads the controller's data and parses it for the piece. This chunk of data is then fed to the piece, which spits it out. This step may be three tiered - initial file parses controller data, middle file sets all vars, final file echoes out data - though this may add unnecessary load time.

While this solution would clean up the view logic and allow me to build more complicated pages, I'm worried about the additional files. Object orientated PHP is not very efficient to begin with, and this would easily triple the number of view files needed for a typical page load. I'm planning on testing this on a small scale on a future site to see if the clean code and simple views outweigh the slower load times. Eventually, when I start working on a future caching system for my MVC, I expect that this idea of modules and mini-views will be a huge boon to my application - though I'm not sure how quickly the rollout for this would be.