RATIONAL

Catalyst::View::TT::Alloy is generally compatible with Catalyst::View::TT. The "TIMER" configuration option isn't supported, and the "paths()" alias to "include_path()" has been removed.

Although Template::Alloy emulates several other templating modules, the interface differs for each one. For this reason, this module only provides the TT interface.

DYNAMIC INCLUDE_PATH

Additional paths can be added to the start of INCLUDE_PATH via the stash as follows:

    $c->stash->{additional_template_paths} =
        [$c->config->{root} . '/test_include_path'];

If you need to add paths to the end of INCLUDE_PATH, there is also an include_path() accessor available:

    push( @{ $c->view('TT')->include_path }, qw/path/ );

Note that if you use include_path() to add extra paths to INCLUDE_PATH, you MUST check for duplicate paths. Without such checking, the above code will add "path" to INCLUDE_PATH at every request, causing a memory leak.

A safer approach is to use include_path() to overwrite the array of paths rather than adding to it. This eliminates both the need to perform duplicate checking and the chance of a memory leak:

    $c->view('TT')->include_path([ qw/ path another_path / ]);

If you are calling "render" directly then you can specify dynamic paths by having a "additional_template_paths" key with a value of additonal directories to search. See "CAPTURING TEMPLATE OUTPUT" for an example showing this.

RENDERING VIEWS

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

        $c->stash->{template} = 'message.tt2';

        $c->forward('MyApp::View::TT::Alloy');
    }

If "template" isn't defined, then it builds the filename from "Catalyst/action" and the "TEMPLATE_EXTENSION" config setting. In the above example, this would be "message".

The items defined in the stash are passed to Template::Alloy for use as template variables.

    sub default : Private {
        my ( $self, $c ) = @_;
        $c->stash->{template} = 'message.tt2';
        $c->stash->{message}  = 'Hello World!';
        $c->forward('MyApp::View::TT::Alloy');
    }

A number of other template variables are also added:

    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

  sub send_email : Local {
    my ($self, $c) = @_;

    $c->email(
      header => [
        To      => 'me@localhost',
        Subject => 'A TT Email',
      ],
      body => $c->view('TT::Alloy')->render($c, 'email.tt', {
        additional_template_paths => [ $c->config->{root} . '/email_templates'],
        email_tmpl_param1 => 'foo'
        }
      ),
    );
  # Redirect or display a message
  }

METHODS

new

The constructor for the TT::Alloy view.

process

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".

render

Arguments: ($c, $template, \%args)

Renders the given template and returns output, or croaks on 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.

config

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

HELPERS

    $ script/myapp_create.pl view TT::Alloy TT::Alloy