With the first iteration of performance enhanvements in place it is time to look further. Page caching is certainly good, but often does not give the kind of fine grained control required.

One way to break down page caching into smaller pieces would be to allow content views and(side)boxes to be cached individually. In practical terms this could mean to execute the layout on request, but return cached pieces of HTML for particular boxes and/or the content view.

This is the point where the current naming gets a bit confusing. View is a very ambiguous term here and I might have to look for something more precise. For now I’ll stick to page view for the current full page view instance and content view, which corresponds to the individual theme files under /content/views.

In order to get access to the HTML of a single box or content view, there could be a couple new classes, say ZMBoxView and ZMContentView (the current view could be renamed ZMPageView and ZMCachedPageView, respectively).

Instances of those new classes would be returned to the layout page rather than filenames and they would have a generate() method similar to the current ZMView implementations.

With this sorted, all that is left is to find a good way to figure out whether a box or content view can be cached or not. Eventually, this might be stored somewhere next to the caching strategy for full pages which is currently hardcoded. We’ll see how that goes…