HTML::Template, CGI:Application and design methodologies

[rchiav]

I don't have a lot of expierence with web development, but sometimes it's the best means to and end. I'm currently retrofitting an existing web based tool to use HTML::Template and by the end of the week I'm going to start working on converting it to use CGI::Application. I'm also working on a project that's in the planning phase where I'll be using HTML::Template and CGI::Application.

My question has to do with the strcutre of the application. I'm pretty anal about things being "clean", and I always feel like my web apps get out of hand. I have to do some redesign around how the content is printed to work with CGI::Application because I create and print different sections at different points in the app. For instance, the top title/header area is generated in one location and the left side panel is generated in another. Now this won't work with CGI::Application because I need to return the entire content from the method call. Now this lead me to this question..

How do people normally generate the different sections of content? It seems to me that I now have two options. I can either "templatize" the entire page (top, left and the main content) for each different "mode", or I can have each "mode" call fuctions that return strings that contain the top and left and then tie up the footer and closing div/table/html tags.

Neither way seems all that "clean" to me and leaves me feeling that I'm missing a better, "cleaner" way to make the logic flow and be more readable.

I'd appreciate any feedback. Also, if this would more approptriatly fit in Meditations, feel free to move it. I wasn't sure where it would be better.

[jerrygarciuh]

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.


HTH
jg

[Trimbach]

I would strongly consider templatize-ing the entire page, top, left, and main. One of the reasons you template in the first place is to separate your program logic from your design, and to consolidate your designs for easy updating and re-use. Assigning separate "modes" to your top and left menu bars sounds awfully complicated to me. If the top and left sections are static, why not just TMPL_INCLUDE it, and if there are small changes (along the lines of "you are here" site navigation and such) that stuff's a piece of cake by throwing in some TMPL_VAR's or by judicious use of TMPL_IF in your template. If the top and side REALLY change in bizarre and complex ways for each mode, that's a clue that you should be using different templates. No one says you have to use only one template for every page in your site. :-) Trying to manage different parts of the same template through "modes" sounds like a recipe for spaghetti-code to me.

[rchiav]

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.

[Trimbach]

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

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.

[elwarren]

Take a step back from your application and your CGI::Application work. As you said, with CGI::Application you must return the entire content from the method call. When you generate a webpage with your existing app, your browser cannot render or display the page until it has the entire page, so it's essentially the same thing. You could just wrap your entire bit of cgi code in a sub and then return the entire page, you'd get what you want but lose any benefits.

As for how I prefer to generate content, I say follow what you call templatizing the entire page. Try to break up your different sections into their own functions, then call them to populate your template. Hmmm, looks like I answered by saying, "both."

I wasn't really exposed to this methodology until I was involved with a largish Java j2ee web project (at which point I asked, "why don't we do this in perl," after which I discovered cgi::application and another framework and realized we did) and even more so later with a portal project. Every bit of content in the portal came from it's own object/function and the portal is just there to put a nice skin on them (using a template.)

Once you start writing this way, it becomes much easier. Code reuse and all that blah blah blah. Take the chatterbox client to the right. It doesn't care about tags, it just dumps what it's got and the site takes care of it. You could wrap the chatterbox in a table cell like it is now or wrap it with html body tags and make it a page by itself.

HTH

[Anonymous Monk]

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. :)