html-template-users — Discussion of HTML::Template and related modules

[htmltmpl] [Question] H::T => using <TMPL_UNLESS> to trigger <TMPL_LOOP>

[C H. <hag...@ep...>]

Hoping someone can shed some light ...

I have a template that calls a loop:


<!--TMPL_LOOP EDITRES -->

Bunch of template HTML stuff here

<!--/TMPL_LOOP EDITRES -->

And this works fine. What I'd like to do is
use a conditional in the template so that the
loop is only specified when a certain parameter
is present on the script side ...



<!--TMPL_UNLESS NAME="intro_error_notice" -->
<!--TMPL_LOOP EDITRES -->
<!--/TMPL_UNLESS -->

Bunch of template HTML stuff here

<!--TMPL_UNLESS NAME="intro_error_notice" -->
<!--/TMPL_LOOP EDITRES -->
<!--/TMPL_UNLESS -->

But when I try this, I get the error:


HTML::Template->new() : found <//TMPL_UNLESS>
with no matching <TMPL_IF> at
/path/to/template/file/here/template.tmpl : line 21.
at /usr/lib/perl5/site_perl/5.6.1/HTML/Template.pm line 2117.


I have confirmed that the conditional value is being passed ..
if I use:

<!--TMPL_UNLESS NAME="intro_error_notice" -->
<h4><!--TMPL_VAR NAME=intro_error_notice --></h4>
<!--/TMPL_UNLESS -->

The value displays. So, I guess my question is, am I asking
H::T to do something it isn't able to do?


Carl Hagstrom

RE: [htmltmpl] print_to error

[Robert M. <rw...@uc...>]

<blush>  Sorry, I completely missed that the first time for some reason
(obviously).   I appreciate you pointing it out again another way.  My brain
cell thanks you.

Robert

> -----Original Message-----
> From: Timm Murray [mailto:tm...@ag...]
> Sent: Thursday, May 06, 2004 12:28 PM
> To: Robert Murray; htm...@li...
> Subject: RE: [htmltmpl] print_to error
>
>
> At 12:20 PM 5/6/04 -0700, Robert Murray wrote:
> >Thanks for the quick reply, Timm.
> >
> >OK, I can understand why I would have to do that.   But I really
> don't want
> >to do that, because I'm going to send the user an email with the
> URL later.
> >I just want to create the file, which it does, so really my only
> >problem/confusion is the error message itself.   I don't
> understand why I'm
> >getting it.  I want it to go away.
>
> Since the return value when using print_to is undef, the print statement
> becomes:
>
>          print undef;
>
> Which causes the exact warning message you are getting.  Your choices are
> to either keep the print_to call out of the print statement, or shut off
> warnings.
>
>
> >Robert
> >
> >
> > > -----Original Message-----
> > > From: Timm Murray [mailto:tm...@ag...]
> > > Sent: Thursday, May 06, 2004 12:01 PM
> > > To: Robert Murray; htm...@li...
> > > Subject: Re: [htmltmpl] print_to error
> > >
> > >
> > > At 11:49 AM 5/6/04 -0700, Robert Murray wrote:
> > > <snip>
> > > >Now the thing is, my code WORKS FINE.  It creates the page, I
> > > can email it,
> > > >click on the link in the email and get to it, etc.   It's just
> > > bugs me that
> > > >when I run the program, I get:
> > > >
> > > >     Use of uninitialized value in print at make_renewals.pl
> line 263, <>
> > > >line 1.
> > > >
> > > >Line 263 in my script is:
> > > >
> > > >         print $spage->output(print_to => *WEBFILE);
> > > <snip>
> > >
> > >
> > >  From the HTML::Template documentation:
> > >
> > >          The return value is undefined when using the
> "print_to" option.
> > >
> > > If you want to print to both the the *WEBFILE file handle and to
> > > the user,
> > > then you need two output() operations:
> > >
> > >          $spage->output( print_to => * WEBFILE );
> > >          print $spage->output();
> > >
> > > Or, if you only want to print the template to the *WEBFILE
> file handle,
> > > then you do without the second line.
> > >
>

RE: [htmltmpl] print_to error

[Timm M. <tm...@ag...>]

At 12:20 PM 5/6/04 -0700, Robert Murray wrote:
>Thanks for the quick reply, Timm.
>
>OK, I can understand why I would have to do that.   But I really don't want
>to do that, because I'm going to send the user an email with the URL later.
>I just want to create the file, which it does, so really my only
>problem/confusion is the error message itself.   I don't understand why I'm
>getting it.  I want it to go away.

Since the return value when using print_to is undef, the print statement 
becomes:

         print undef;

Which causes the exact warning message you are getting.  Your choices are 
to either keep the print_to call out of the print statement, or shut off 
warnings.


>Robert
>
>
> > -----Original Message-----
> > From: Timm Murray [mailto:tm...@ag...]
> > Sent: Thursday, May 06, 2004 12:01 PM
> > To: Robert Murray; htm...@li...
> > Subject: Re: [htmltmpl] print_to error
> >
> >
> > At 11:49 AM 5/6/04 -0700, Robert Murray wrote:
> > <snip>
> > >Now the thing is, my code WORKS FINE.  It creates the page, I
> > can email it,
> > >click on the link in the email and get to it, etc.   It's just
> > bugs me that
> > >when I run the program, I get:
> > >
> > >     Use of uninitialized value in print at make_renewals.pl line 263, <>
> > >line 1.
> > >
> > >Line 263 in my script is:
> > >
> > >         print $spage->output(print_to => *WEBFILE);
> > <snip>
> >
> >
> >  From the HTML::Template documentation:
> >
> >          The return value is undefined when using the "print_to" option.
> >
> > If you want to print to both the the *WEBFILE file handle and to
> > the user,
> > then you need two output() operations:
> >
> >          $spage->output( print_to => * WEBFILE );
> >          print $spage->output();
> >
> > Or, if you only want to print the template to the *WEBFILE file handle,
> > then you do without the second line.
> >

RE: [htmltmpl] print_to error

[Robert M. <rw...@uc...>]

Thanks for the quick reply, Timm.

OK, I can understand why I would have to do that.   But I really don't want
to do that, because I'm going to send the user an email with the URL later.
I just want to create the file, which it does, so really my only
problem/confusion is the error message itself.   I don't understand why I'm
getting it.  I want it to go away.

Robert


> -----Original Message-----
> From: Timm Murray [mailto:tm...@ag...]
> Sent: Thursday, May 06, 2004 12:01 PM
> To: Robert Murray; htm...@li...
> Subject: Re: [htmltmpl] print_to error
>
>
> At 11:49 AM 5/6/04 -0700, Robert Murray wrote:
> <snip>
> >Now the thing is, my code WORKS FINE.  It creates the page, I
> can email it,
> >click on the link in the email and get to it, etc.   It's just
> bugs me that
> >when I run the program, I get:
> >
> >     Use of uninitialized value in print at make_renewals.pl line 263, <>
> >line 1.
> >
> >Line 263 in my script is:
> >
> >         print $spage->output(print_to => *WEBFILE);
> <snip>
>
>
>  From the HTML::Template documentation:
>
>          The return value is undefined when using the "print_to" option.
>
> If you want to print to both the the *WEBFILE file handle and to
> the user,
> then you need two output() operations:
>
>          $spage->output( print_to => * WEBFILE );
>          print $spage->output();
>
> Or, if you only want to print the template to the *WEBFILE file handle,
> then you do without the second line.
>

Re: [htmltmpl] print_to error

[Timm M. <tm...@ag...>]

At 11:49 AM 5/6/04 -0700, Robert Murray wrote:
<snip>
>Now the thing is, my code WORKS FINE.  It creates the page, I can email it,
>click on the link in the email and get to it, etc.   It's just bugs me that
>when I run the program, I get:
>
>     Use of uninitialized value in print at make_renewals.pl line 263, <>
>line 1.
>
>Line 263 in my script is:
>
>         print $spage->output(print_to => *WEBFILE);
<snip>


 From the HTML::Template documentation:

         The return value is undefined when using the "print_to" option.

If you want to print to both the the *WEBFILE file handle and to the user, 
then you need two output() operations:

         $spage->output( print_to => * WEBFILE );
         print $spage->output();

Or, if you only want to print the template to the *WEBFILE file handle, 
then you do without the second line.

[htmltmpl] print_to error

[Robert M. <rw...@uc...>]

Hello,

I'm converting some perl code that contained imbedded web page creation
code.  I'm using a template and writing the file to disk because I need to
reference it in an email sent afterwards.

I'm on a system with mod_perl, which I understand from previous posts has
'issues'.  (is there a mod_perl/H:T how-to anywhere?).

Now the thing is, my code WORKS FINE.  It creates the page, I can email it,
click on the link in the email and get to it, etc.   It's just bugs me that
when I run the program, I get:

    Use of uninitialized value in print at make_renewals.pl line 263, <>
line 1.

Line 263 in my script is:

	print $spage->output(print_to => *WEBFILE);

Obviously its talking about the WEBFILE var, right?   But if its
uninitialized then how come my page is created and all the tmpl_var's are
substituted just fine?   The whole part of the page creation from start to
finish goes like this (unimportant stuff snipped):

...
    open(WEBFILE, "> $diskpage") or ...;
    my $spage = GuestLib::initTemplate($Prog{'renewal_template'});
    my @loop_data = ();
    my @S_Guests  = split ',', $guestlist;
    foreach $g_alias ( sort @S_Guests )
        {
        my %Gst = GuestLib::doQuery("alias=$g_alias");

        my %rowdata = ();
        $rowdata{'g_alias'}    = $g_alias;
        $rowdata{'g_idnumber'} = $Gst{'guest_id'};
        $rowdata{'g_lfname'}   = $Gst{'last_first_name'};
        $rowdata{'g_title'}    = $Gst{'title'};
        push @loop_data, \%rowdata;
        }

    $spage->param('s_alias'      => $s_alias,
                  's_name'       => $s_name,
                  'g_count'      => scalar(@S_Guests),
                  'guestlist'    => \@loop_data );

    print $spage->output(print_to => *WEBFILE);
    close WEBFILE;
...

If you're wondering about my initTemplate() call, its just my own wrapper
function with some extra logging and stuff in it.  But if your curious about
init settings, it looks like this:

sub initTemplate
   {
   my $tname = shift;
   FatalError('TMPLINIT', $tname) unless $tname;
   my $t = HTML::Template->new('filename' => $tname, 'case_sensitive' => 1,
                               'die_on_bad_params' => 0, 'cache' => 1,
                               'loop_context_vars' => 1, 'globalvars' =>
1 );
   FatalError('TMPLINIT', $tname) unless defined $t;
   Log("...");
   if ( $Prog{'debug'} )  { ... }
   return $t;
   }


I've tried a few different things, but nothing worked.  I looked at the
archives regarding print_to and/or mod_perl but didn't find much that was
relevant or that worked.  The "tie WEBFILE, 'Apache'" thing gave me a
TIEHANDLE error, and other things I tried generated even more errors rather
than fix things.

If anyone has an idea of where I'm going wrong, please clue me in.  Thanks.

Robert

Re: [htmltmpl] Select/option How to set "selected"?

[Cees H. <ce...@si...>]

Mathew Robertson wrote:
>>Matthew, I don't understand what's wrong with Jason's example. If DBI yields
>>a result in the format HTML::Template understands, what's wrong with taking
>>advantage of that? How would you change his example to make it more indirect
>>and abstract?
> 
> 
> I would do something like:
> 
> {
>   my $sql_result = $db->fetch...
>   my @output;
>   foreach (@{$sql_result}) {
>      my $tmp;
>      $tmp->{name} = $_->[0];
>      if ($_->[0] == 'fred') { $tmp->{selected} = 1; }
>      push @output, $tmp;
>   }
>   template->param( 'some_loop' => \@output);
> }
> 
> this makes the 'some_loop' TMPL_LOOP become reasonably abstract, as used below...

The point was to move that conditional into the database query instead 
of doing it in perl.  Your results would have been identical, except 
that you set 'selected' => 1 and in the example given the user set 
'selected' => 'SELECTED'.  But both values are true, hence you could use 
the example given and still have the flexibility that you require in the 
template.

In Postgres you could do something like this to achieve the same result:

SELECT val, text, CASE WHEN val='fred' THEN 1 ELSE 0 END as selected
FROM table
WHERE whatever...

Then you can still use the $sth->fetchall_arrayref( {} ) method to pull 
an array of hashes out of the database and pass it straight to your 
template, thus removing the need for the loop and the conditionals in 
your perl code.

Cheers,

Cees

Re: [htmltmpl] Select/option How to set "selected"?

[Mathew R. <mat...@re...>]

> Matthew, I don't understand what's wrong with Jason's example. If DBI =
yields
> a result in the format HTML::Template understands, what's wrong with =
taking
> advantage of that? How would you change his example to make it more =
indirect
> and abstract?

I would do something like:

{
  my $sql_result =3D $db->fetch...
  my @output;
  foreach (@{$sql_result}) {
     my $tmp;
     $tmp->{name} =3D $_->[0];
     if ($_->[0] =3D=3D 'fred') { $tmp->{selected} =3D 1; }
     push @output, $tmp;
  }
  template->param( 'some_loop' =3D> \@output);
}

this makes the 'some_loop' TMPL_LOOP become reasonably abstract, as used =
below...

> I love HTML::Template. Especially in combination with =
CGI::Application. But,
> sometimes a database structure naturally lends itself to a form =
structure.
> Doesn't it? Why is it wrong to pump the SQL output directly to
> HTML::Template?

nothing is wrong with it per se... its all a matter of opinion...

I personally like the fact that I can do something like list with the =
TMPL_LOOP:

<TMPL_LOOP some_loop>
   <TMPL_IF EXPR=3D"(__counter__ % 3) =3D=3D 1">
       <tr valign=3Dtop>
   </TMPL_IF>
          <td width=3D33% align=3Dcenter valign=3Dtop class=3Dtext>
             ... some info...
             <TMPL_IF selected>
                 .... entry selected
             </TMPL_IF>
          </td>
    <TMPL_IF EXPR=3D"(__counter__ % 3) =3D=3D 0">
        </tr>
         <tr>
              <td colspan=3D3>
                   <spacer>
              </td>
         </tr>
   </TMPL_IF>
</TMPL_LOOP>

Basically this stuff takes the loop, then formats the output into three =
columns and multiple rows.
You can see here that the loop is no longer a combobox, but anthing that =
can be drawn using a table.

Thus, not tie'ing the output of the SQL to a specific format, allows me =
to use the same loop definition within:
1) as above
2) combobox
3) list of checkboxes / radiobuttons
4) arbitrary <UL> styled list where I color the selected item

Note, I also use a variation of the above code to display a picture =
gallery -> the Perl code doesn't need to care how I format the output =
(which would normally be done with nested TMPL_LOOP's).

This explain?
Mathew

>=20
> Mark
>=20
> ----- Original Message -----=20
> From: "Mathew Robertson" <mat...@re...>
> To: <htm...@li...>
> Sent: Monday, May 03, 2004 8:26 PM
> Subject: Re: [htmltmpl] Select/option How to set "selected"?
>=20
>=20
> > What's really neat if you do it like that is you can use DBI's
> > fetchall_arrayref method and be really snazzy:
> >
> > my $template =3D HTML::Template->new( 'filename' =3D> 'file.TMPL' );
> > my $sth =3D $dbh->prepare( <<_SQL_ );
> > SELECT val,
> >         text,
> >         (if then else to return 'selected' or '') AS selected
> > FROM table
> > WHERE whatever...
> > _SQL_
> > $sth->execute();
> > $template->param( 'OCCUPATION_LOOP' =3D> $sth->fetchall_arrayref( {} =
) );
> > ## Note that the fetchall_arrayref doesn't save you computing time =
--
> > ## it's only a shortcut and does the same thing as your loop to go
> > ## through the results
> > ---
> >
> > What's neat about this, too is that it simplifies the template code, =
as
> > Puneet laid out.
>=20
> Except that you have now tied your SQL statement directly to HTML =
syntax; in
> which case... what is the point of using H::T -> you could generate =
HTML
> output faster if you created an SQL statement which generated HTML =
directly.
>=20
> The purpose of H::T is to decopule the data from the presentation.
> Mathew
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>=20
> 

Re: [htmltmpl] Select/option How to set "selected"?

[Sam T. <sa...@tr...>]

> >You're telling me you don't keep a list of your class attributes in
> >your Perl code already?  I don't believe you!
>
> I don't understand. I don't have any elements or attributes in my
> Perl code. It's all contained in templates. I feel like I'm missing
> a point of sarcasm?

Nope, I just misread your comment as referring to Perl class
attributes rather than CSS class attributes.  You're correct that if
the form elements need CSS classes then you'd need to pass them to
CGI.pm in the Perl code.  Although, it occurs to me that you could
just tell your HTML designers to wrap the tag in a <span> and use that
to apply their CSS:

  <span class="jazzy"><tmpl_var some_select></span>

-sam

Re: [htmltmpl] Select/option How to set "selected"?

[Mark A. F. <mar...@ea...>]

From: Sam Tregar <sa...@tr...>

>So if I wanted to have <tmpl_var selected> set when $thing->{bar} was
on I'd add this to the loop body:

Thanks Sam. I understand now. It's essentially the same thing Puneet suggested last night. At that point it was just a matter of whether it was better to have "<tmpl_var selected>" resolved with each iteration of the loop or to test it as a boolean and, if true emit " selected". It sounded like there wasn't much difference except it might look less messy without the test (letting it resolve with each iteration).

>How would you setup @__selected__?  Would it really be easier than the
>single line of code shown above?

Setting up my hypothetical reserved array name "@__selected__" would be the same as the single line of code you used. Just an array of 0 (or undef) or 1 indicating if the row should process my hypothetical lable "<TMPL_LOOP_CHECKED>".

I was just trying to think of some way to simplify the Template syntax. Some way to move the testing for this commonly emitted string into H::T so the loop structure might look cleaner. But, it sounds like the result of this idea wouldn't look much different than just letting a TMPL_VAR resolve with each iteration. (Sorry).

>You're telling me you don't keep a list of your class attributes in
>your Perl code already?  I don't believe you!

I don't understand. I don't have any elements or attributes in my Perl code. It's all contained in templates. I feel like I'm missing a point of sarcasm?

Mark

Re: [htmltmpl] Select/option How to set "selected"?

[Cees H. <ce...@si...>]

Sam Tregar wrote:
> On Mon, 3 May 2004, Mark Fuller wrote:

>>It just seems to me like "selected" and "checked" are fairly basic and
>>there's no easy (more built-in) way to accomodate them. It seems like you
>>recognize that they require a bit of ugliness. Why not provide for them
>>somehow?
> 
> 
> Because CGI.pm already has it nailed.  Why reinvent the wheel?  And
> you can't beat the simplicity:
> 
>   $template->param(year_select =>
>                    scalar $query->popup_menu(-name => 'year',
>                                              -values => [ 1970 .. 2020 ])
>                   );
> 
> And in the template:
> 
>   <tmpl_var year_select>
> 
> I've been doing it for years now and it's never done me wrong.

I have to agree with Sam on this one.  I don't think there is a need to 
add features to handle select lists in HTML::Template.  The issue of 
filling in HTML forms was solved ages ago, and doing it in 
HTML::Template is not (IMHO) the elegant way to do it.

Use CGI.pm as Sam suggests, or use HTML::FillInForm (my preferred 
method).  These days the only thing that needs to be customized in a 
form element that a designer may need access to is the class attribute. 
  If you define a standard naming convention, then having the class 
attribute in your code is not a big deal (the code already defines the 
name of the form element as well...).  If you need to change the style 
dynamically, then load a different stylesheet for the page.  Don't 
change the name of the class attribute...

The only thing that I can see where using CGI.pm to generate select 
boxes could hamper a designer is if they want to put a null option at 
the top of the list ( eg -- Choose a Year --).  That would have to be 
encoded in the code which means the designer can't change it.  That is 
one reason why I use HTML::FillInForm.  I provide the template with a 
list of options (which the designer can put into a select box, or as a 
bunch of radio buttons formatted in a table, I don't care).   Then 
HTML::FillInForm comes along afterwards and fills out the form 
regardless of how the designer decided to lay it out.

Both methods simplify your templates a great deal, and make life much 
easier for the template designer.  That having been said, nothing is 
stopping you from continuing on using HTML::Template to fill in forms. 
It is a valid method that works well for many people.

Cheers,

Cees

Re: [htmltmpl] Select/option How to set "selected"?

[Sam T. <sa...@tr...>]

On Tue, 4 May 2004, Mark A. Fuller wrote:

> Does %row have special meaning in HTML::Template? I saw it used in
> another example. I don't know if I misunderstand something about
> this example. (How would I use $row{__selected__} after I set it?)

It's just a common way to setup a loop:

  my @loop;
  foreach my $thing (@things) {
     my %row;
     $row{foo} = $thing->{bar};
     push(@loop, \%row);
  }
  $template->param(things => \@loop);

So if I wanted to have <tmpl_var selected> set when $thing->{bar} was
on I'd add this to the loop body:

  $row{selected} = "selected" if $thing->{bar};

> For example, what if H::T could recognize a special keyword (such as
> TMPL_LOOP_SELECTED and TMPL_LOOP_CHECKED) inside the TMPL_LOOP and
> automatically test an array of booleans with a reserved name (say,
> @__selected__) who's index corresponds to H::T's internal row
> counter. H::T could fill in the "selected" or "checked" value if all
> the conditions are correct.

How would you setup @__selected__?  Would it really be easier than the
single line of code shown above?

> What I was getting at is that something seems to be missing in
> TMPL_LOOP. There are two types of loops which are common, have a
> known/standard requirement (testing for "selected" or "checked" on
> every row), and the syntax for accomplishing this is always referred
> to as "ugly." If it's so common, so standard, and so ugly, why can't
> there be a way that H::T handles it behind the scenes?

Actually, I find my standard way of accomplishing these things to be
quite elegent.  I actually like CGI.pm and I think it works very well
with HTML::Template.  Other people may choose to employ other
solutions, but that doesn't motivate me to help them.

> Doesn't this move the HTML out of the template?

Sure, it's a trade-off.  You gain some simplicity by setting up the
<select> in your code.  You lose some flexibility by not letting the
HTML designer diddle a small chunk of HTML.  I've found that it rarely
causes problems since designers don't usually need to work on these
tags.

> If I have class attributes that may change depending on visitor
> preferences, now I have to maintain them in two places (in the
> template for everything except SELECT and RADIOBOX elements, and in
> my Perl code for these two)?

You're telling me you don't keep a list of your class attributes in
your Perl code already?  I don't believe you!

-sam

Re: [htmltmpl] Select/option How to set "selected"?

[Sam T. <sa...@tr...>]

On Tue, 4 May 2004, Puneet Kishor wrote:

> Besides, that is what my designer gals and guys are going to
> know. They will have no idea what the heck $query->popup_menu(-name
> => 'year', -values => [ 1970 .. 2020 ]) means.

I've found that it's very unusual for designers to need to work on the
form tags themselves.  If they need to change anything it's usually
just a matter of adding the appropriate CSS '-class' parameter.  But
I've only had to do that a few times.  Much more common is the need to
move form tags around, which is actually easier if the form tag is a
simple '<tmpl_var foo_select>' and not a huge nest of if/else blocks.

-sam

Re: [htmltmpl] Select/option How to set "selected"?

[Mark A. F. <mar...@ea...>]

From: Sam Tregar <sa...@tr...>
>I don't think this is too much code to expect people to write:
>
> $row{__selected__} = "selected" if $value;
>
>That's really all you're talking about, right?

Does %row have special meaning in HTML::Template? I saw it used in another example. I don't know if I misunderstand something about this example. (How would I use $row{__selected__} after I set it?)

What I was getting at is that something seems to be missing in TMPL_LOOP. There are two types of loops which are common, have a known/standard requirement (testing for "selected" or "checked" on every row), and the syntax for accomplishing this is always referred to as "ugly." If it's so common, so standard, and so ugly, why can't there be a way that H::T handles it behind the scenes?

For example, what if H::T could recognize a special keyword (such as TMPL_LOOP_SELECTED and TMPL_LOOP_CHECKED) inside the TMPL_LOOP and automatically test an array of booleans with a reserved name (say, @__selected__) who's index corresponds to H::T's internal row counter. H::T could fill in the "selected" or "checked" value if all the conditions are correct.

I don't understand why there's a known requirement to produce HTML like this, but it always seems to be pushed outside the domain of H::T. If it's just a matter of ugly template syntax, couldn't the syntax be simplified by being standardized as a common processing method?

>Because CGI.pm already has it nailed.  Why reinvent the wheel?  And
>you can't beat the simplicity:
>
>  <tmpl_var year_select>

Doesn't this move the HTML out of the template? If I have class attributes that may change depending on visitor preferences, now I have to maintain them in two places (in the template for everything except SELECT and RADIOBOX elements, and in my Perl code for these two)?

Mark

[htmltmpl] ANNOUNCE: Bricolage 1.8.0 Arrives!

[David W. <da...@ki...>]

     It is with great pleasure that the Bricolage development team 
announces
     the release of Bricolage 1.8.0. The culmination of over 15 months in
     development, with contributions from over 20 independent developers,
     and new features sponsored by numerous organizations world-wide,
     version 1.8.0 represents a significant new pinnacle for the 
much-lauded
     open-source content management and publishing system. This release
     offers more new features, improvements, and performance gains than 
any
     previous release. There are so many, in fact (over 120), that they
     can't effectively be included in this email. Here are some of the
     highlights:

       * Support for managing multiple sites from a single Bricolage
       installation. Each site has its own categories, templates, 
document
       types, and workflows, and collaboration across sites is supported 
by
       document aliasing and shared workflow desks.

       * Significant performance boosts to search queries and URI 
uniqueness
       validation.

       * Email document distribution, which can be used to email the 
files
       generated by an output channel to one or more email addresses.

       * A greatly simplified and flexible templating and element API.

       * Template sandboxes to enable template development without
       interfering with production templates.

       * Support for Template Toolkit templates
       (http://www.template-toolkit.org).

       * New "Publish" and "Recall" permissions, for improved workflow
       management.

       * Per-user preferences.

       * Document formatting at publish time, rather than publish 
scheduling
       time.

       * New German and Mandarin localizations.

       * Image thumbnails and icons for all media documents.

       * Support for HTMLArea WYSIWYG editing with HTMLArea. See
       http://www.interactivetools.com/products/htmlarea/.

     For a complete list of the changes, see the release notes and 
changes
     list at 
http://sourceforge.net/project/shownotes.php?release_id=235793.
     For the complete history of ongoing changes in Bricolage, see
     Bric::Changes at http://www.bricolage.cc/docs/Bric/Changes.html.

     Download Bricolage 1.8.0 now from the SourceForge download page at
     http://sourceforge.net/project/showfiles.php?group_id=34789, and 
from
     the Kineticode download page at
     http://www.kineticode.com/bricolage/index2.html.

ABOUT BRICOLAGE

     Bricolage is a full-featured, enterprise-class content management 
and
     publishing system. It offers a browser-based interface for ease-of 
use,
     a full-fledged templating system with complete HTML::Mason,
     HTML::Template, and Template Toolkit support for flexibility, and 
many
     other features. It operates in an Apache/mod_perl environment and 
uses
     the PostgreSQL RDBMS for its repository. A comprehensive,
     actively-developed open source CMS, Bricolage was hailed as "Most
     Impressive" in 2002 by eWeek.

     Enjoy!

     --The Bricolage Team

AW: [htmltmpl] Select/option How to set "selected"?

[<Seb...@3S...>]

> Puneet Kishor wrote
> > [...] because I am using=20
> > CGI::Session, and I am not sure if that will work with=20
> CGI::Simple (can=20
> > anyone tell me if it will and how?).=20
>=20
> There has been some recent discussion on the CGI::Application=20
> list of just
> this issue. It seems that CGI::Session does a pretty strict=20
> test to make sure
> that it has a CGI.pm object and not just a compatible object.=20
> I think some
> work is underway to change this so that it does some tests=20
> for the param() and
> cookie() methods. So, not right now, but maybe not too much later.


I use CGI::Session in combination with mod_perl and it works like a
charm.
(No wonder since Apache::Request was written with backward
compatibility in mind.)
From what I can say so far mod_perl, HTML::Template and CGI:Session
are a winning team ;-)

Regards,
Sebastian

Re: [htmltmpl] Select/option How to set "selected"?

[petersm <pe...@ve...>]

Puneet Kishor wrote
> 
> since there are more than three ways to do it, I am actually going to 
> dissent here. Personally, I don't like CGI.pm. I think it weighs a lot, 
> and most of the time I use it (and I do), it mainly to extract the 
> params. I am stuck with it in a recent project because I am using 
> CGI::Session, and I am not sure if that will work with CGI::Simple (can 
> anyone tell me if it will and how?). 

There has been some recent discussion on the CGI::Application list of just
this issue. It seems that CGI::Session does a pretty strict test to make sure
that it has a CGI.pm object and not just a compatible object. I think some
work is underway to change this so that it does some tests for the param() and
cookie() methods. So, not right now, but maybe not too much later.



> > Except that you have now tied your SQL statement directly to HTML 
> > syntax; in which case... what is the point of using H::T -> you could 
> > generate HTML output faster if you created an SQL statement which 
> > generated HTML directly.
> >
> > The purpose of H::T is to decopule the data from the presentation.

how about something like this that decouples the SQL from the HTML but is
still relatively simple (and uses XHTML instead of HTML )

in perl
.
.
my $sth = $dbi->prepare(qq(SELECT val, text, (val = "$selected") AS selected
FROM whatever WHERE whatever));
my $tmpl = HTML::Template->new();
$tmpl->param(occupations => $sth->fetchall_arrayref( {} );


in the tmpl (for a dropdown select box)
.
.
<select name='whatever'>
<TMPL_LOOP NAME=OCCUPATION_LOOP>
  <option value="<TMPL_VAR NAME=VAL>" <TMPL_IF
NAME="SELECTED">selected='selected'</TMPL_IF>><TMPL_VAR NAME=TEXT></option>
</TMPL_LOOP>
</select>


or in the tmpl for a group of checkboxes, (or radio buttons)
.
.
<TMPL_LOOP NAME=OCCUPATION_LOOP>
  <input type='checkbox' value="<TMPL_VAR NAME=VAL>" name='whatever'  <TMPL_IF
NAME="SELECTED">checked='checked'</TMPL_IF> /><TMPL_VAR NAME=TEXT><br />
</TMPL_LOOP> 

this way the same SQL creates a structure that is independent of the HTML but
still not so much so that it's hard to work with.

Michael Peters
Venzia

[htmltmpl] Please remove me from your mailing lists

[Theron H. <hu...@at...>]

Please remove me from your mailing lists.

Theron Huffman
-------------------------------------------------------
"If you have the courage to begin, 
you have the courage to succeed." 
            --------David Viscott

Re: [htmltmpl] Select/option How to set "selected"?

[Puneet K. <pk...@ei...>]

On May 4, 2004, at 12:43 AM, Sam Tregar wrote:

> On Mon, 3 May 2004, Mark Fuller wrote:
>
>> ..
>
> Because CGI.pm already has it nailed.  Why reinvent the wheel?  And
> you can't beat the simplicity:
>
>   $template->param(year_select =>
>                    scalar $query->popup_menu(-name => 'year',
>                                              -values => [ 1970 .. 2020 
> ])
>                   );
>
> And in the template:
>
>   <tmpl_var year_select>
>
> I've been doing it for years now and it's never done me wrong.
>

since there are more than three ways to do it, I am actually going to 
dissent here. Personally, I don't like CGI.pm. I think it weighs a lot, 
and most of the time I use it (and I do), it mainly to extract the 
params. I am stuck with it in a recent project because I am using 
CGI::Session, and I am not sure if that will work with CGI::Simple (can 
anyone tell me if it will and how?). Talking about reinventing the 
wheel -- that is precisely what CGI.pm is trying to do... there is a 
perfectly well established HTML language there... why put it through 
another translotor.

Why don't I like CGI.pm... it is about a few thousand lines of code for 
about 2 or 3 things I want to do with it. I certainly don't want to use 
it to code HTML because that is just one more syntax to learn. I 
already know HTML however kludgy it might be. Besides, that is what my 
designer gals and guys are going to know. They will have no idea what 
the heck $query->popup_menu(-name => 'year', -values => [ 1970 .. 2020 
]) means. CGI.pm was invented to allow Perl programmers to do HTML 
without having to re-learn HTML. Since I already know HTML, but don't 
know CGI.pm, why learn CGI.pm.

I disagree with Matthew's suggestion as well (kinda rebellious here, 
no).

> Except that you have now tied your SQL statement directly to HTML 
> syntax; in which case... what is the point of using H::T -> you could 
> generate HTML output faster if you created an SQL statement which 
> generated HTML directly.
>
> The purpose of H::T is to decopule the data from the presentation.

There is always some disadvantage to any kind of abstraction. The 
purpose of H-T for _me_ is to decouple HTML and JavaScript from 
everything else. I know Perl and SQL (well, I just confessed above that 
I also know HTML, but let's overlook that). I want to separate that 
from a as-much-pure-HTML-as-possible website. Now, within my code how 
much I abstract is up to me. I could hide all the SQL by creating views 
and storedprocs for every conceivable SQL action and then just calling 
a simple SELECT statement all the time, or I could stick as much SQL in 
my Perl code and make my code db-independent (which also is not 
possible most of the time). The thing is, I can choose the level of 
abstraction that I am comfortable with. H-T has done its job 
magnificently by allowing the designers (or myself) to just concentrate 
on how it looks once there are no more syntax or logic errors.

As Jason summarized, use SQL and db to their fullest advantage, not 
just as dump respositories of data... there is much one can do with 
SQL.... use it and the db's inherent power. That coupled with 
fetchall_arrayref({}) -- yes, that is what I use almost 100% of the 
time... seems like it was tailor-made for H::T -- and you've got sweet 
code.

That said, keep in mind, in my very first response to Mark I started 
with "there are many ways of accomplishing this... here is how I would 
do it".

;-)

Re: [htmltmpl] Select/option How to set "selected"?

[Sam T. <sa...@tr...>]

On Mon, 3 May 2004, Mark Fuller wrote:

> By way of suggestion, the way HTML::Template has various "__first__,
> __last__, __counter__" helper fields, I wish there were a way to inform a
> loop of a special value used to indicate the row that should get the
> "selected" attribute. It seems like there's a lot of pragmatic helpers
> available, but nothing for what is a very basic HTML construct. Why not a
> reserved variable name like __selected__ and HTML::Template would fill it in
> automatically if a corresponding boolean is true for that row? Would this be
> any more efficient (or beautiful) than Puneet's suggestion?

I don't think this is too much code to expect people to write:

  $row{__selected__} = "selected" if $value;

That's really all you're talking about, right?

> It just seems to me like "selected" and "checked" are fairly basic and
> there's no easy (more built-in) way to accomodate them. It seems like you
> recognize that they require a bit of ugliness. Why not provide for them
> somehow?

Because CGI.pm already has it nailed.  Why reinvent the wheel?  And
you can't beat the simplicity:

  $template->param(year_select =>
                   scalar $query->popup_menu(-name => 'year',
                                             -values => [ 1970 .. 2020 ])
                  );

And in the template:

  <tmpl_var year_select>

I've been doing it for years now and it's never done me wrong.

-sam

Re: [htmltmpl] Select/option How to set "selected"?

[Mark F. <mar...@ea...>]

Matthew, I don't understand what's wrong with Jason's example. If DBI yields
a result in the format HTML::Template understands, what's wrong with taking
advantage of that? How would you change his example to make it more indirect
and abstract?

I love HTML::Template. Especially in combination with CGI::Application. But,
sometimes a database structure naturally lends itself to a form structure.
Doesn't it? Why is it wrong to pump the SQL output directly to
HTML::Template?

Mark

----- Original Message ----- 
From: "Mathew Robertson" <mat...@re...>
To: <htm...@li...>
Sent: Monday, May 03, 2004 8:26 PM
Subject: Re: [htmltmpl] Select/option How to set "selected"?


> What's really neat if you do it like that is you can use DBI's
> fetchall_arrayref method and be really snazzy:
>
> my $template = HTML::Template->new( 'filename' => 'file.TMPL' );
> my $sth = $dbh->prepare( <<_SQL_ );
> SELECT val,
>         text,
>         (if then else to return 'selected' or '') AS selected
> FROM table
> WHERE whatever...
> _SQL_
> $sth->execute();
> $template->param( 'OCCUPATION_LOOP' => $sth->fetchall_arrayref( {} ) );
> ## Note that the fetchall_arrayref doesn't save you computing time --
> ## it's only a shortcut and does the same thing as your loop to go
> ## through the results
> ---
>
> What's neat about this, too is that it simplifies the template code, as
> Puneet laid out.

Except that you have now tied your SQL statement directly to HTML syntax; in
which case... what is the point of using H::T -> you could generate HTML
output faster if you created an SQL statement which generated HTML directly.

The purpose of H::T is to decopule the data from the presentation.
Mathew


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
_______________________________________________
Html-template-users mailing list
Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users

Re: [htmltmpl] Select/option How to set "selected"?

[Mark F. <mar...@ea...>]

Thanks Sam. I try to stay away from CGI.pm. In my opinion, it should have
been named HTML.pm. <smile> I just don't need all the HTML'ish routines. I
use CGI:Simple.

The suggestion from Puneet looks great. I don't have any problem with it.
Yet.... :)

By way of suggestion, the way HTML::Template has various "__first__,
__last__, __counter__" helper fields, I wish there were a way to inform a
loop of a special value used to indicate the row that should get the
"selected" attribute. It seems like there's a lot of pragmatic helpers
available, but nothing for what is a very basic HTML construct. Why not a
reserved variable name like __selected__ and HTML::Template would fill it in
automatically if a corresponding boolean is true for that row? Would this be
any more efficient (or beautiful) than Puneet's suggestion?

It just seems to me like "selected" and "checked" are fairly basic and
there's no easy (more built-in) way to accomodate them. It seems like you
recognize that they require a bit of ugliness. Why not provide for them
somehow? It couldn't add more overhead than the loop variables mentioned
above. (I support your quest to keep it clean and fast!).

Mark


----- Original Message ----- 
From: "Sam Tregar" <sa...@tr...>
To: "Mark Fuller" <mar...@ea...>
Cc: <htm...@li...>
Sent: Monday, May 03, 2004 8:42 PM
Subject: Re: [htmltmpl] Select/option How to set "selected"?


> On Mon, 3 May 2004, Mark Fuller wrote:
>
> > How can I specify a row should be "selected"? The TMPL_VAR named "VAL"
is a
> > numeric index. If I could use TMPL_IF and concatenate the value of
"VAL", I
> > think it would work.
>
>  I just use CGI.pm's popup_menu().  I find that it's pretty rare for
> HTML designers to need to do something to the form tags themselves so
> I usually let CGI.pm to do the hard work for me.  You certainly can
> accomplish this with HTML::Template, but I don't think you're going to
> like the look of what it takes!
>
> -sam
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

Re: [htmltmpl] Select/option How to set "selected"?

[Sam T. <sa...@tr...>]

On Mon, 3 May 2004, Mark Fuller wrote:

> How can I specify a row should be "selected"? The TMPL_VAR named "VAL" is a
> numeric index. If I could use TMPL_IF and concatenate the value of "VAL", I
> think it would work.

 I just use CGI.pm's popup_menu().  I find that it's pretty rare for
HTML designers to need to do something to the form tags themselves so
I usually let CGI.pm to do the hard work for me.  You certainly can
accomplish this with HTML::Template, but I don't think you're going to
like the look of what it takes!

-sam

Re: [htmltmpl] Select/option How to set "selected"?

[Mathew R. <mat...@re...>]

> What's really neat if you do it like that is you can use DBI's=20
> fetchall_arrayref method and be really snazzy:
>=20
> my $template =3D HTML::Template->new( 'filename' =3D> 'file.TMPL' );
> my $sth =3D $dbh->prepare( <<_SQL_ );
> SELECT val,
>         text,
>         (if then else to return 'selected' or '') AS selected
> FROM table
> WHERE whatever...
> _SQL_
> $sth->execute();
> $template->param( 'OCCUPATION_LOOP' =3D> $sth->fetchall_arrayref( {} ) =
);
> ## Note that the fetchall_arrayref doesn't save you computing time --
> ## it's only a shortcut and does the same thing as your loop to go
> ## through the results
> ---
>=20
> What's neat about this, too is that it simplifies the template code, =
as=20
> Puneet laid out.

Except that you have now tied your SQL statement directly to HTML =
syntax; in which case... what is the point of using H::T -> you could =
generate HTML output faster if you created an SQL statement which =
generated HTML directly.

The purpose of H::T is to decopule the data from the presentation.
Mathew

Re: [htmltmpl] Select/option How to set "selected"?

[Jason P. <ja...@jo...>]

> That said, my philosophy is to dump as much work on the database as 
> possible. Why? -- because db programs have been developed over years and 
> years (not that Perl has not been, but your or my code may not have the 
> same advantage), db servers are typically fast machines, db software 
> have been honed to do set processing, evaluations, calculations, etc. 
> There is a lot of science behind db theory. Definitely use it to your 
> advantage.

I definitely agree here -- I didn't think about using SQL to do the 
selected part ... kinda neat. :)

What's really neat if you do it like that is you can use DBI's 
fetchall_arrayref method and be really snazzy:

my $template = HTML::Template->new( 'filename' => 'file.TMPL' );
my $sth = $dbh->prepare( <<_SQL_ );
SELECT val,
        text,
        (if then else to return 'selected' or '') AS selected
FROM table
WHERE whatever...
_SQL_
$sth->execute();
$template->param( 'OCCUPATION_LOOP' => $sth->fetchall_arrayref( {} ) );
## Note that the fetchall_arrayref doesn't save you computing time --
## it's only a shortcut and does the same thing as your loop to go
## through the results
---

What's neat about this, too is that it simplifies the template code, as 
Puneet laid out.

Cheers,

Jason