Catalyst-View-Template-Pure

 view release on metacpan or  search on metacpan

README.mkdn  view on Meta::CPAN

arguments are not passed directly to the template as data, but rather passed as
initialization arguments to the ->new method when calling the view the first time
in a request.  So you may still use the stash, but because the view is mediating
the stash data I believe we mitigate some of the stash's downsides (such as a lack
of strong typing, missing defined interface and issues with typos, for example).

# CHAINING TEMPLATE TRANFORMATIONS

There are several ways to decompose your repeated or options template transforms
into reusable chunks, at the View level.  Please see [Template::Pure](https://metacpan.org/pod/Template::Pure) for more
abour includes, wrappers and overlays.  However there are often cases when the
decision to use or apply changes to your template best occur at the controller
level.  For example you may wish to add some messaging to your template if a form
has incorrect data.  In those cases you may apply additional Views.  Applied views
will use as its starting template the results of the previous view.  For example:

    sub process_form :POST Path('') Args(0) {
      my ($self, $c) = @_;
      my $v = $c->view('Login');

      if($c->model('Form')->is_valid) {

README.mkdn  view on Meta::CPAN

      ],
    );

    __PACKAGE__->meta->make_immutable;

In this example we set the `src` attribute for the include processing
instruction to a path off 'Views' which is a special method on the view that
returns access to all the other views that are loaded.  So essentially any
view could serve as a source.

The same approach would be used to set overlays and wrappers via processing
instructions.

If using the `Views` helper seems too flimsy an interface, you may instead
specify a view via an accessor, just like any other data.

    package  MyApp::View::Hello;

    use Moose;
    use HTTP::Status qw(:constants);

README.mkdn  view on Meta::CPAN

      directives => [
        '#hello' => 'name',
      ],
    );

    __PACKAGE__->meta->make_immutable;

Just remember if your include expects arguments (and most will) you should pass
them in the view call.

In fact you could allow one to pass the view `src` include (or wrapper, or overlay)
from the controller, if you need more dynamic control:

    package  MyApp::View::Hello;

    use Moose;
    use HTTP::Status qw(:constants);

    extends 'Catalyst::View::Template::Pure';

    has 'name' => (is=>'ro', required=>1);

README.mkdn  view on Meta::CPAN

      ->apply('Footer', copyright => 2016)
      ->http_ok;

When a view is used via 'apply', the result of the previous template becomes
the 'template' argument, even if that view defined its own template via
configuration.  This is so that you can use the same view as standalone or as
part of a chain of transformations.

Useful when you are building up a view over a number of actions in a chain or
when you need to programmatically control how a view is created from the
controller.  You may also consider the use of includes and overlays inside your
view, or custom directive actions for more complex view building.

## wrap

Used to pass the response on a template to another template, via a 'content'
argument. Similar to the 'wrapper' processing instruction.  Example:

    package MyApp::View::Users;

    use Moose;

lib/Catalyst/View/Template/Pure.pm  view on Meta::CPAN

arguments are not passed directly to the template as data, but rather passed as
initialization arguments to the ->new method when calling the view the first time
in a request.  So you may still use the stash, but because the view is mediating
the stash data I believe we mitigate some of the stash's downsides (such as a lack
of strong typing, missing defined interface and issues with typos, for example).

=head1 CHAINING TEMPLATE TRANFORMATIONS

There are several ways to decompose your repeated or options template transforms
into reusable chunks, at the View level.  Please see L<Template::Pure> for more
abour includes, wrappers and overlays.  However there are often cases when the
decision to use or apply changes to your template best occur at the controller
level.  For example you may wish to add some messaging to your template if a form
has incorrect data.  In those cases you may apply additional Views.  Applied views
will use as its starting template the results of the previous view.  For example:

    sub process_form :POST Path('') Args(0) {
      my ($self, $c) = @_;
      my $v = $c->view('Login');

      if($c->model('Form')->is_valid) {

lib/Catalyst/View/Template/Pure.pm  view on Meta::CPAN

      ],
    );

    __PACKAGE__->meta->make_immutable;

In this example we set the C<src> attribute for the include processing
instruction to a path off 'Views' which is a special method on the view that
returns access to all the other views that are loaded.  So essentially any
view could serve as a source.

The same approach would be used to set overlays and wrappers via processing
instructions.

If using the C<Views> helper seems too flimsy an interface, you may instead
specify a view via an accessor, just like any other data.

    package  MyApp::View::Hello;

    use Moose;
    use HTTP::Status qw(:constants);

lib/Catalyst/View/Template/Pure.pm  view on Meta::CPAN

      directives => [
        '#hello' => 'name',
      ],
    );

    __PACKAGE__->meta->make_immutable;

Just remember if your include expects arguments (and most will) you should pass
them in the view call.

In fact you could allow one to pass the view C<src> include (or wrapper, or overlay)
from the controller, if you need more dynamic control:

    package  MyApp::View::Hello;

    use Moose;
    use HTTP::Status qw(:constants);

    extends 'Catalyst::View::Template::Pure';

    has 'name' => (is=>'ro', required=>1);

lib/Catalyst/View/Template/Pure.pm  view on Meta::CPAN

      ->apply('Footer', copyright => 2016)
      ->http_ok;

When a view is used via 'apply', the result of the previous template becomes
the 'template' argument, even if that view defined its own template via
configuration.  This is so that you can use the same view as standalone or as
part of a chain of transformations.

Useful when you are building up a view over a number of actions in a chain or
when you need to programmatically control how a view is created from the
controller.  You may also consider the use of includes and overlays inside your
view, or custom directive actions for more complex view building.

=head2 wrap

Used to pass the response on a template to another template, via a 'content'
argument. Similar to the 'wrapper' processing instruction.  Example:

    package MyApp::View::Users;

    use Moose;