http://qs1969.pair.com?node_id=266830

This is a technique I discovered a while ago. It will probably underwhelm a lot of people who may already have been using it for a while. However I've yet to see it explicitly discussed.

I refer to TT2 and CGI.pm's HTML generation methods as yin and yang here because their common uses represent polar opposites in the emphasis on application- vs. presentation centric design. By combinging the two, you can follow presentation centric design and get stickiness for form elements very painlessly.

So much fuss, so very little to show for it:

#!/usr/bin/perl -w use strict; use CGI; use Template # ... my $q = CGI->new; # ... $template->process("foo.tmpl.html", { query => $q, @other_variables, }) or die $Template::ERROR;
Now you can achieve sticky form elements simply by using TT2's object access capabilities to say things like
[% query.textfield("name", "J. Random Hacker", 30) %]

It is nothing earth shattering. But IMO, its usefulness is in fact because of rather than despite that.

Another use might be to implement purely presentation relevant aspects of a web application completely outside the core CGI script - after all, nothing stops you from querying parameter values as in lang = query.param('lang'); in the template. I have used this to retrofit internationalization on a CGI script without touching the Perl code at all.

Makeshifts last the longest.

Replies are listed 'Best First'.
•Re: Nirvana through the templating yin yang (TT2 / CGI.pm)
by merlyn (Sage) on Jun 18, 2003 at 16:00 UTC
      I know, but it's usually hard to write a CGI script without access to params via the CGI object. :) Admittedly I haven't even tried - but is it possible to instatiate a CGI object inside the main script and additionally use the TT2 CGI plugin?

      Makeshifts last the longest.

Re: Nirvana through the templating yin yang (TT2 / CGI.pm)
by VSarkiss (Monsignor) on Jun 18, 2003 at 15:07 UTC

    Probably also obvious to those who've tried it, but you can do the same thing with HTML::Template. I realized it only very recently.

    I originally had a drop-down list that I coded similar to:

    <select name="the_thing"> <tmpl_loop name="select_thing"> <option value="<tmpl_var name="select_value">"> <tmpl_var name="select_tag"> </option> </tmpl_loop> </select>
    (the values came out of a database lookup), but that lost the stickiness. I then realized I could cook up the select in CGI, and pass it to the template. So the only thing in the template file was just <tmpl_var name="the_whole_select">and I passed it the result of $q->popup_menu, and presto, stickiness returned. It's just a slight variation. (BTW, those samples are from memory, so there may be some inaccuracies in there.)

    The nice thing about it is that all the "real" presentation stuff is still in the template; it's a lot more convenient than before, with a very slight loss of maintainability.

      HTML::Template also makes it easy and clean to make other form elements sticky. it lets you just associate the CGI object with the template:

      my $query = new CGI; my $template = HTML::Template->new(filename => 'template.tmpl', associate => $query);

      and a template variable is set for every param that CGI knows about.

      for selects, i still don't like to use $query->popup_menu. instead i have a function in a standard library that i use for all my web programming like so:

      sub selectify { my $values = shift; my $labels = shift; my $selected = shift; my %selected = map {$_ => 1} @{$selected}; return [map { { value => $_, label => shift @{$labels}, selected => $selected{$_} || "", } } @{$values}]; }

      so in my code i can do:

      $template->param(some_loop => selectify(\@values,\@labels,[$query->par +am('some_param')]);

      and in the template:

      <select name="some_param"> <tmpl_loop name="some_loop"> <tmpl_include name="inner_loop.tmpl"> </tmpl_loop> </select>

      inner_loop.tmpl is factored out into its own template so i can reuse it all over the place. it just contains:

      <option value="<tmpl_var name="value" escape="html">"<tmpl_if name="se +lected"> selected="selected"</tmpl_if>><tmpl_var name="label" escape= +"html"></option>

      i don't know, i guess i just can't stand the thought of any of my output html being generated by CGI.pm and not totally controlled by my templates. that way if the designer wants to add a size, or class attribute to the select, they don't have to ask me to add it to the perl code.

      anders pearson

Re: Nirvana through the templating yin yang (TT2 / CGI.pm)
by kutsu (Priest) on Jun 18, 2003 at 15:52 UTC

    Before I start I like this post, and it's name, but:

    Aristotle said "polar opposites in the emphasis on application"

    Yin always contains a little Yang, Yang always contains a little Yin. They are not polar opposites. ++ for the post though

    "Pain is weakness leaving the body, I find myself in pain everyday" -me

Re: Nirvana through the templating yin yang (TT2 / CGI.pm)
by chunlou (Curate) on Jun 19, 2003 at 11:18 UTC
    What architecture to use is often dictated by your organizational and development environment, besides your teammates' skills and the merit of the technology itself.

    Whimsical development process encourages PHP type of technology, which more easily allows "on-the-fly" coding with little planning.

    N-tier architecture (starting with your using templating, for instance) requires intellectual and procedural supports from both programmers and non-programmers.

    The idea could be characterized in the following table, as an example (be the changes due to internal or external reasons):
      Architectural1.
    (Backend Logics) Changes
    Rare Often
    Business Rules2.
    (Middle Layer Logics)
    Changes
    Business Rules2.
    (Middle Layer Logics)
    Changes
    Rare Often Rare Often
    Presentation
    (Frontend Logics)
    Changes
    Rare Assembly?
    (just kidding)
    Template
    +
    scripting lang.
    (ever happened?) Template
    +
    scripting lang.
    Often Template
    +
    compiled
    codes
    PHP (not sure this
    can happen)
    PHP
    (simple 2-tier)
    + yoga, aspirin, etc

    1. This usually means DB, XML, etc.
    2. This translates into Perl scripts, Java beans, COM, stored procedures etc. for most people
      I feel the need to clarify - and disagree.

      If I correctly understand your table you are saying that in all the likely scenarios templating is the way to go, unless both the logic and presentation change often, and then putting the logic in with the presentation (ala PHP) is best.

      Surely with both the logic and presentation changing the best thing is to have them both seperate. As long as the interface is well defined then the two can be changed with minimal interaction.

      I am currently refactoring a PHP site I wrote in 2000 into a perl site. All of the pages are becoming shorter and cleaner, even with my ruthlessly splitting them into logic and templates. This may be influencing my view on this but quite frankly there is no reason to do it the php way once you have fully understood the templating way.

      Like the table though - thought provoking. Now back to that PHP...

      --tidiness is the memory loss of environmental mnemonics

        Surely with both the logic and presentation changing the best thing is to have them both seperate. As long as the interface is well defined then the two can be changed with minimal interaction

        Agreement to the Nth power! Especially if the presentation maintainers and the logic maintainers are different groups of people.

        With shifting requirements it's best to try and keep everything decoupled from everything else.

        (Update: Not that this is a pro-Perl, anti-PHP statement. You can mangle the code and presentation together just as easily in Perl.)

Re: Nirvana through the templating yin yang (TT2 / CGI.pm)
by submersible_toaster (Chaplain) on Jun 21, 2003 at 16:55 UTC

    ++Aristotle, Yeah! I've been fooling about with CGI and HTML::Template for a while, trying to get my head around separating glitz from guts. Associating the query object with a template was certainly a feature I liked.

    I hope this node collects many replies. Of particular interest to me is some comparison between Template toolkit and HTML::Template (I appreciate the toolkit is not as specific as HTML::Template).

    If anyone needs me, I'll be at searh.cpan.org most likely


    I can't believe it's not psellchecked