[Catalyst-dev] RFC: Catalyst::View::Mason::Templated

Ash Berlin ash_cpan at firemirror.com
Tue Sep 18 08:19:32 GMT 2007


Sebastian Willert wrote:
> 
> Here's the POD, so please tell me what you think.
> 
> Cheers,
>   Sebastian
> 
> ---
> 
> NAME
>   Catalyst::View::Mason::Templated - Full featured Mason View Class
> 
> SYNOPSIS
>     # use the helper
>     script/create.pl view Mason Mason::Templated
> 
>     # lib/MyApp/View/Mason.pm
>     package MyApp::View::Mason;
> 
>     use base 'Catalyst::View::Mason::Templated';
> 
>     1;
> 
>     $c->forward('MyApp::View::Mason');
> 
> DESCRIPTION
>   Want to use a Mason component in your views? No problem!
>   Catalyst::View::Mason::Templated comes to the rescue.
> 
> EXAMPLE
>   From the Catalyst controller:
> 
>     $c->stash->{name} = 'Homer'; # Pass a scalar
>     $c->stash->{extra_info} = {
>            last_name => 'Simpson',
>            children => [qw(Bart Lisa Maggie)]
>     }; # A ref works too
> 
>   From the Mason template:
> 
>     <%args>
>     $name
>     $extra_info
>     </%args>
>     <p>Your name is <strong><% $name %>
>       <% $extra_info->{last_name} %></strong>
>     <p>Your children are:
>     <ul>
>     % foreach my $child (@{$extra_info->{children}}) {
>     <li>$child
>     % }
>     </ul>
> 
> OVERWRITTEN METHODS
>   new( $c, ?$args )
>   Parses the mason config and builds a valid "comp_root" out of the
>   "INCLUDE_PATH" config variable.
> 

I don't think the end user cares that this module have been
overridden/written. Probably should just me moved to a CONFIG section
and ignore the fact that new does INCLUDE_PATH -> comp_root

> ADDITIONAL METHODS
>   fetch_comp( $template )
>   Returns an HTML::Mason::Component instance for the given
>   template path.
>   Mason templates are compiled to full fledged perl modules with
>   introspection capabilities and other potential usefull stuff so this
>   method is provided here even if using it breaks API compatibility with
>   Catalyst::View::Templated.
> 
> MASON CONFIGURATION
>   This allows you to to pass additional settings to the
>   HTML::Mason::Interp constructor or to set the options as below:
> 
>   "DATA_DIR"
>     Defaults to "File::Spec->tmpdir"
> 
>   "ALLOW_GLOBALS"
>     Defaults to "qw/$c $name $base/"
> 
>     If you add additional allowed globals those will be prepended to the
>     list of default globals.
> 
>   Most of the parameters listet in HTML::Mason::Params are also present
>   (preverably in uppercase), so you can e.g. use your custom request
>   class.
> 

s/listet/listed/; s/preverably/preferably/;

> VIEW CONFIGURATION
>   "CHARSET"
>     HTML::Mason isn't bothered with character encodings so you can use
>     this to set the correct charset for the output string. Setting
>     "CHARSET" will force a
> 
>       Enocde::decode( $self->{CHARSET}, [...] )
> 
>     on the Mason output, thus allowing Catalyst::View::Templated to
>     guess the correct content-type.
> 
>   "INCLUDE_PATH"
>     An array ref containing the user's desired include paths. This is
>     set to a reasonable default ("root/") if the user omits it from his
>     config. HTML::Mason forces you to name your include paths if more
>     than one path is given. If you want to state the path keys
>     explicitly, it should be of the following form:
> 
>        MyApp->config->{View::Mason}
>        = { INCLUDE_PATH  =>
>          [ [ FOO => '/usr/local/foo' ],
>            [ BAR => '/usr/local/bar' ] ]
>          };
> 
>     If no path keys are given, they are calculated from the significant
>     (i.e. unique) suffix of the path, with the first path always mapped
>     to "MAIN". This example should give you correct idea:
> 
>        MyApp->config->{View::Mason}
>        = { INCLUDE_PATH  =>
>          [ '/usr/local/foo', '/usr/local/foo/widgets',
>            '/usr/local/bar', '/usr/local/bar/widgets' ],
>          };
> 
>     gets transformed to:
> 
>        MyApp->config->{View::Mason}
>        = { INCLUDE_PATH  =>
>          [ [ MAIN => '/usr/local/foo' ],
>            [ FOO_WIDGETS => '/usr/local/foo/widgets' ],
>            [ BAR => '/usr/local/bar' ],
>            [ BAR_WIDGETS => '/usr/local/bar/widgets' ] ],
>          };
> 
>     Please be aware that you loose compatibility with other
>     Catalyst::View::Templated classes if you specify the key names.
> 
> INCOMPTIBILITIES
>   CHARSET
>   The charset of a template no longer defaults to 'utf-8'
> 

Any reason why you don't put this back in anyway?

Apart from those it seems sane - but I don't know Mason at all if that
matters.



More information about the Catalyst-dev mailing list