My concern with having everything in essentially one template (rather one template that includes other templates that include other templates) is that it might overcomplicate the data structure. In the small app I'm currently working on, I create 3 or 4 template objects and print each of their outputs. Each invocation of these templates is presenting data from unrelated queries.

I guess I'm just going to have to try it and see how well it works.

In the small app I'm currently working on, I create 3 or 4 template objects and print each of their outputs. Each invocation of these templates is presenting data from unrelated queries.

This is just a suggestion on how this might be managed (and simplified) with one template object:

sub some_mode {
    my $tmpl_object = $self->load_tmpl('my_tmpl.html');    
            
    $tmpl_object->param( param1 => 'foo'
                         param2 => 'bar',
                         param3 => 'baz');
    
    
    # Poke the data for the top part of the page into the $tmpl_object
    get_top($tmpl_object);
    
    # Ditto for the left side of the page
    get_left($tmpl_object);
    
    # Display the entire templated page 
    return $tmpl_object->output;
}
[download]

Of course you can add parameters to get_top() and get_left() to fine tune their output on a mode-by-mode basis, but by passing around one template object at a time things may become much simpler than having your program eat its tail calling one recursive mode within a mode within a mode after another.

Gary Blackburn
Trained Killer

I am currently in the midst of building a largish application using Template-Toolkit, CGI::Application, and Class::DBI.

I have been contempplating the best way to make a clean flow and I have found that building the page from component templates and keeping all of the "interface decisions" in the template logic has definitely made my application logic much more clear.

I think I have also really benefitted from the fact that Template-Toolkit understands Perl objects, such that I can pass large constructs from the application into the template under a consolidated name space and without a million individual args. So my advice would be to let the templates build themselves from components based on the data they receive and let your application assemble the data but leave the interface alone.

Personally I use HTML::Tree, which is an unfortunately named module that conflicts with the CPAN module of the same name. I use this for two reasons. The first is the templated HTML is fully valid HTML; it can be validated via the w3c, viewed without the code at all, and edited by WSYWYG HTML editors. The second is it changes the paradigm from the code driving the HTML to the HTML driving the code.

As for different sections of content, for serious web apps we use a framework that uses a set of perl objects to render a page, and allow SSI include processing to bring the pieces of a page together. The entire page is then templated, and viewable as a whole, and (almost) regular HTMLand the code for the application is broken down into bite sized, reusable components.

PHP and friends keep the code and its relevant HTML together, but I dislike tying the two together. I feel embedding the code in the HTML is just as bad as embedding the HTML in the code; and I feel that extra tags for templating is just putting the code in the HTML in a different language. :)