view release on metacpan or  search on metacpan

lib/Catalyst/View/TT.pm  view on Meta::CPAN

    The message is: [% message %]
    The base is [% base %]
    The name is [% name %]


The output generated by the template is stored in C<< $c->response->body >>.

=head2 CAPTURING TEMPLATE OUTPUT

If you wish to use the output of a template for some other purpose than
displaying in the response, e.g. for sending an email, this is possible using
other views, such as L<Catalyst::View::Email::Template>.

=head2 TEMPLATE PROFILING

See L</C<TIMER>> property of the L</config> method.

=head1 METHODS

=head2 new

The constructor for the TT view. Sets up the template provider,
and reads the application config.

=head2 process($c)

Renders the template specified in C<< $c->stash->{template} >> or
C<< $c->action >> (the private name of the matched action).  Calls
L<render|/render($c, $template, \%args)> to
perform actual rendering. Output is stored in C<< $c->response->body >>.

It is possible to forward to the process method of a TT view from inside
Catalyst like this:

    $c->forward('View::Web');

N.B. This is usually done automatically by L<Catalyst::Action::RenderView>.

=head2 render($c, $template, \%args)

Renders the given template and returns output. Throws a L<Template::Exception>
object upon error.

The template variables are set to C<%$args> if C<$args> is a hashref, or
C<< $c->stash >> otherwise. In either case the variables are augmented with
C<base> set to C<< $c->req->base >>, C<c> to C<$c>, and C<name> to
C<< $c->config->{name} >>. Alternately, the C<CATALYST_VAR> configuration item
can be defined to specify the name of a template variable through which the
context reference (C<$c>) can be accessed. In this case, the C<c>, C<base>, and
C<name> variables are omitted.

C<$template> can be anything that Template::process understands how to
process, including the name of a template file or a reference to a test string.
See L<Template::process|Template/process> for a full list of supported formats.

To use the render method outside of your Catalyst app, just pass a undef context.
This can be useful for tests, for instance.

It is possible to forward to the render method of a TT view from inside Catalyst
to render page fragments like this:

    my $fragment = $c->forward("View::Web", "render", $template_name, $c->stash->{fragment_data});

=head3 Backwards compatibility note

The render method used to just return the Template::Exception object, rather
than just throwing it. This is now deprecated and instead the render method
will throw an exception for new applications.

This behaviour can be activated (and is activated in the default skeleton
configuration) by using C<< render_die => 1 >>. If you rely on the legacy
behaviour then a warning will be issued.

To silence this warning, set C<< render_die => 0 >>, but it is recommended
you adjust your code so that it works with C<< render_die => 1 >>.

In a future release, C<< render_die => 1 >> will become the default if
unspecified.

=head2 template_vars

Returns a list of keys/values to be used as the catalyst variables in the
template.

=head2 config

This method allows your view subclass to pass additional settings to
the TT configuration hash, or to set the options as below:

=head2 paths

The list of paths TT will look for templates in.

=head2 expose_methods

The list of methods in your View class which should be made available to the templates.

For example:

  expose_methods => [qw/uri_for_css/],

  ...

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

    # additional complexity like checking file exists here

    return $c->uri_for('/static/css/' . $filename);
  }

Then in the template:

  [% uri_for_css('home.css') %]

=head2 content_type

This lets you override the default content type for the response.  If you do
not set this and if you do not set the content type in your controllers, the
default is C<text/html; charset=utf-8>.

Use this if you are creating alternative view responses, such as text or JSON