Mailing List Archive

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@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

On Nov 27, 2008, at 1:18 AM, Andy Wardley wrote:
>
> 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' %]

Great tip. I usually do the nowrap thing - but using a layout
variable like that is great. I will have to try that on my next site
build.

Thanks!!

Jay

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Ashley wrote:
> Catalyst::View::TT, line 236-ish
>
> if ( $vars->{wrapper} ) {
> $self->template->service->{WRAPPER} = [ $vars->{wrapper} ];
> }
> elsif ( exists $vars->{wrapper} ) # allow undef to clear wrapper
> {
> $self->template->service->{WRAPPER} = [];
> }

I would suggest that you allow $vars->{wrapper} to be an arrayref
itself, so one could actually set it to a stack of nested wrappers.

--
Jason Gottshall
jgottshall@capwiz.com


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev