View on
Terrence Brannon > Catalyst-View-Seamstress-2.0 > Catalyst::View::Seamstress



Annotate this POD


New  1
Open  0
View/Report Bugs
Module Version: 2.0   Source   Latest Release: Catalyst-View-Seamstress-2.2


Catalyst::View::Seamstress - HTML::Seamstress View Class for Catalyst


# use the helper to create MyApp::View::Seamstress # where comp_root and skeleton are optional view Seamstress Seamstress /path/to/html html::skeleton
                         ^-modulenm ^-helpernm ^-comp_root   ^-skeleton

# optionally edit the skeleton and meat_pack routines # in lib/MyApp/View/

# render view from lib/ or lib/

    sub message : Global {
        my ( $self, $c ) = @_;

        $c->stash->{LOOM} = 'html::hello_world';
        $c->stash->{name}     = 'Mister GreenJeans';
        $c->stash->{date}     = 'Today';

        # the DefaultEnd plugin would mean no need for this line


This is the Catalyst view class for HTML::Seamstress. Your application should define a view class which is a subclass of this module. The easiest way to achieve this is using the script (where myapp should be replaced with whatever your application is called). This script is created as part of the Catalyst setup.

    $ script/ view Seamstress Seamstress

This creates a module in the lib directory (again, replacing MyApp with the name of your application).

Now you can modify your action handlers in the main application and/or controllers to forward to your view class. You might choose to do this in the end() method, for example, to automatically forward all actions to the Seamstress view class.

    # In MyApp or MyApp::Controller::SomeController
    sub end : Private {
        my( $self, $c ) = @_;

Or you might like to use Catalyst::Plugin::DefaultEnd


The helper app automatically puts the per-application configuration info in MyApp::View::Seamstress. You configure the per-request information (e.g. $c->stash->{LOOM} and variables for this template) in your controller.

The meat-skeleton paradigm

When Catalyst::View::Seamstress is forwarded to, it will operate in one of 2 ways: a plain meat way or a meat-skeleton way. Plain meat is simple: the View takes $c->stash->{template} and calls new() and process() on it and stores the result in $c->response->body. Meat-skeleton is designed to facilitate the way that web sites are typically designed. It's discussion follows:

HTML pages typically have meat and a skeleton. The meat varies from page to page while the skeleton is fairly (though not completely) static. For example, the skeleton of a webpage is usually a header, a footer, and a navbar. The meat is what shows up when you click on a link on the page somewhere. While the meat will change with each click, the skeleton is rather static.

The perfect example of

Mason accomodates the meat-skeleton paradigm via an autohandler and $m->call_next(). Template accomodates it via its WRAPPER directive.

And Seamstress? Well, here's what you _can_ do:

1 generate the meat, $meat

This is typically what you see in the body part of an HTML page

2 generate the skeleton, $skeleton

This is typically the html, head, and maybe some body

3 put the meat in the skeleton

So, nothing about this is forced. This is just how I typically do things and that is why Catalyst::View::Seamstress has support for this.

Choosing plain-meat or meat-skeleton

There are two items which control how this plugin renders HTML.

The output generated by the template (and possibly its interaction with a skeleton) is stored in $c->response->body.

Tips to View Writers ^

The order of use base is VERY significant

When your helper module creates MyApp::V::Seamstress it is very important for the use base to look this way:

  use base qw(Catalyst::View::Seamstress HTML::Seamstress );

and not this way:

  use base qw(HTML::Seamstress Catalyst::View::Seamstress );

so that certain calls (probably new) get handled properly.

Getting config information from MyApp and MyApp::View::*

assuming Catalyst::View::Seamstress::new() starts off like this:

 sub new {
    my $self = shift;
    my $c    = shift;

$self->config contains things set in MyApp::View::*. $c->config contains things set in MyApp

assuming Catalyst::View::Seamstress::process() starts off similarly:

 sub process {
    my ( $self, $c ) = @_;

$self->config contains things set in MyApp::View::*. $c->config contains things set in MyApp.

There is no automatic merging of the two sources of configuration: you have to do that yourself if you want to do it.


Catalyst, Catalyst::View, Catalyst::Helper::View::Seamstress, HTML::Seamstress

A working sample app

The best way to see a fully working Seamstress-style Perl class is to pull down the working sample app from sourceforge.

A working sample app, which does both simple and meat-skeleton rendering is available from Sourceforge CVS:

 cvs login
 cvs co -P catalyst-simpleapp


Email the author or ping him on #catalyst on


Terrence Brannon <>


This program is free software, you can redistribute it and/or modify it under the same terms as Perl itself.

syntax highlighting: