[Catalyst-dev] Reasonable change to C::V::TT?

[Andy Wardley]

Ashley wrote:
> If someone has a better idea for how to handle this (I think multiple TT 
> views is certainly a decent way to approach it but adding a package for 
> every desired exception to the site-wide wrapper strikes me as Wrong™).

You can already do this kind of thing by putting it in your wrapper template.

I typically use a variable called "layout".  My site-wide wrapper template
simply wraps the content in the requested layout template (in my layout/
directory), or uses the default "layout/default" if undefined,

site/wrapper:

     [% DEFAULT layout = template.layout or 'default';
        content WRAPPER "layout/$layout";
     %]

If "layout" isn't defined then I first check the template.layout variable.
This allows a page author to select a layout by writing something like this
at the top of a page template:

     [% META layout='blog' %]

Going one step further, I would usually have a "page" data structure with a
bunch of metadata relating to the page.  This includes things like the layout,
page title, the additional JS and CSS files I want linked in for a page, and
so on.  It's usually better to keep all this metadata in one data structure
than sprinkle it around in lots of different variables.

     page = {
         layout = 'blog',
         title  = 'An Example Page',
         js     = ['jquery.js', 'another.js']
         css    = ['blog.css']
     }

An advantage of this approach is that it becomes easy to define all your
page metadata in a database, YAML file, or some other storage system of
your choice.  You can then pull out the relevant record for a page (indexed by
template URI) and stuff it into the stash as 'page' (or something else).  I've
done this  previously by subclassing View::TT and adding a page_metadata()
method which is called from the template_vars() method:

     my $cvar = $self->config->{CATALYST_VAR};
+   my $mvar = $self->config->{METADATA_VAR};

     return (
         $cvar => $c,
+       $mvar => $self->page_metadata($c->stash->{template})
     );

Storing your presentation metadata separately is usually a Good Thing[tm].
On a practical level it makes it easier to manage when it's in an external
store (implementing a simple webapp to edit your page metadata is left as an
exercise for the reader ;-).  On a conceptual level, it's promoting a clearer
separation of concerns between the application controllers and the
presentational aspects, and that's usually something to be encouraged.

HTH
A