view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        c      A reference to the context object, $c
        base   The URL base, from $c->req->base()
        name   The application name, from $c->config->{ name }

    These can be accessed from the template in the usual way:

    <message.tt2>:

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

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

  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 Catalyst::View::Email::Template.

  TEMPLATE PROFILING
    See ""TIMER"" property of the "config" method.

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

  process($c)
    Renders the template specified in "$c->stash->{template}" or
    "$c->action" (the private name of the matched action). Calls render to
    perform actual rendering. Output is stored in "$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 Catalyst::Action::RenderView.

  render($c, $template, \%args)
    Renders the given template and returns output. Throws a
    Template::Exception object upon error.

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

    $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 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});

   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 "render_die => 1". If you rely on the
    legacy behaviour then a warning will be issued.

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

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

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

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

  paths
    The list of paths TT will look for templates in.

  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') %]

  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 "text/html; charset=utf-8".

    Use this if you are creating alternative view responses, such as text or
    JSON and want a global setting.

    Any content type set in your controllers before calling this view are
    respected and have priority.