abw at wardley
Nov 27, 2008, 12:18 AM
Post #2 of 4
(585 views)
Permalink
|
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
_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
|
