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

Re: [htmltmpl] RFC: Persistent or 2-stage evaluation

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

From: "Ragan, Steve" <sr...@bc...>
> Portions that
> pertain to user-specific variables are "renamed" (or purposely misnamed,
if
> you will) TMPL_VAR's so they are not recognized and handled by H::T during
> this pass.
>
> <my_special_VAR NAME=first>
>
> [then]
>
>     $output =~ s/my_special_VAR/TMPL_VAR/g;

Steve, thanks. That might work for me. I'm not sure I'd want to pre-generate
all the pages (and keep them in synch). Since I'm caching my own pages (by
language), I could probably do the ->new, ->output, regex
and ->new_scaler_ref when a page is not in the cache without too much
slowdown on the first display of a page.

The three things I've found that make multi-language processing difficult
with H::T are:

1. One-time evaluation of a template's page-specific vars (so that
subsequent displays can deal only in truly variable evaluations).
2. No way to say <tmpl_include name="constant_text_<tmpl_var name=LANG>"> to
use language-specific text determined at run time.
3. No way to recurse variables which may have been evaluated with text that
contains variables.

#2 and 3 are troubling because, if I can't pull in fragments of a page (for
a language), then I'm likely to use "Locale::Maketext" to provide me with
what may be lengthy fragments. If the fragments contain markup (like a
link), then I'm stuck because the fragment's link will contain an attribute:
"title=<TMPL_VAR NAME=LINK_TITLE_TEXT>" which will not be evaluated.

Feeding ->output back into new H::T objects can get around a lot of this. It
would be a lot easier if those 3 features were available. They don't seem
like they would require too much kludging.

Thanks,
Mark

[htmltmpl] Valid XHTML templates

[Tobias G. <lis...@e-...>]

Hi!

Is there any way to use a valid XHTML document as template? As far as I tried 
this seems to be not possible.

e.g.:

[1] valid XHTML, working:

<title><tmpl_var name="title"/></title>


[2] valid XHTML, but not working:

<option value="&lt;tmpl_var name&gt"><tmpl_var name="name"/></option>


[3] invalid XHTML, not working either

<option value="<tmpl_var name>"><tmpl_var name="name"/></option>


[4] invalid XHTML, but working (just removed the slash, this worked in [1]!)

<option value="<tmpl_var name>"><tmpl_var name="name"></option>


The template needs to be valid xml, to be processed for translations. My
current solution is to transform the valid XHTML to an invalid template
that HTML::Template can deal with. But I would prefer feeding HTML::Template
directly with the XHTML file.

Any ideas?

Someone mentioned a patch to use {%TMPL_xxx%} instead of <TMPL_xxx>. Is there
already a working version of this patch available?

bye,

Tobias

RE: [htmltmpl] RFC: Persistent or 2-stage evaluation

[Ragan, S. <sr...@bc...>]

Approach the problem from a slightly different tack. Don't try to do
everything in one pass through H::T.
Instead, think of it as a two-step approach.

Each user belongs to a group, and the group portions of the template are the
same for all members of that group.
Only the user portions need to change with each visit. So, separate the
group variables from the user variables.

In this type situation, I do a one-time "page generation" of the "group"
template to be used for subsequent user visits.
That user template is generated from a "master template" where all the
"group" level elements (like logo image, background and text colors, etc.)
are normal TMPL_VAR's to be handled during this page gen step. Portions that
pertain to user-specific variables are "renamed" (or purposely misnamed, if
you will) TMPL_VAR's so they are not recognized and handled by H::T during
this pass. So, the user's first name, which should be "ignored" during the
page gen might be in a "tag" named like -

	<my_special_VAR NAME=first>

In my page gen code I take the output H::T and rename the dummy VAR names to
"proper" H::T TMPL_VAR's before writing out the user version of the
template. Assuming you've got an H::T object, $template, and previously
opened FileHandle, $fh, the code would look something like this - 


    my $output = $template->output;

    ## Replace temporary tags with HTML::Temlate tags before write to file
    #
    $output =~ s/my_special_VAR/TMPL_VAR/g;

    print $fh $output;

The template output in the output file pointed to by $fh is then your "user"
version of the template. 
All the "group-level" elements have already been replaced with the
hard-coded equivalents.
Makes for a much faster end-user experience since there are less tags to
process at that level.


Steve Ragan 
Sr. Internet Developer
Harris Internet Services
2500 Westchester Ave.
Purchase, NY 10577
Phone: 914-641-3948
Fax    : 914-641-3901
sr...@bc...


-----Original Message-----
From: htm...@li...
[mailto:htm...@li...]On Behalf Of
Mark Fuller
Sent: Tuesday, January 18, 2005 12:26 PM
To: HTML::Template users
Subject: [htmltmpl] RFC: Persistent or 2-stage evaluation


Sam, earlier I said it would be useful if I could apply some evaluation
once. Then operate upon that partially evaluated template. I didn't realize
H::T applies everything at output(?).

If H::T applies everything at output, wouldn't it be relatively easy to
accomplish this if there was a way to tell H::T to perform an "output" *but
don't eliminate any H::T tags that are unevaluated*?

If I could do this, I could set all my one-time page evaluation and do a
"new_scalar_ref->" (using the output from my first "new->" from a file). If
there were a way to tell H::T to reload it internally there may be a way to
utilize H::T's caching mechanism (instead of me keeping my H::T object in
%hash_of_templates{language}). Doing a "new->" would have to tell me it
reloaded the template so that I could do the one-time processing again (and
output_internal-> to put it back into the state where it's mostely prepared
for repeated processing).

What do you think? Would it be easy to do by sub-classing?

Did you eventually agree there is a legitimate case for one-time page
evaluation? (One-time language replacement of title, headings, navigation,
etc.) I'd like to apply some heavy replacement and do it only once. Keep the
resulting text containing only the tags that are evaluated on a
display-by-display basis (messages, etc.).

This might have some application for select/option lists too. I won't
confuse the issue with that yet. My main concern is just to avoid repetitive
numerous replacement of text which is constant for a page.

Thanks!
Mark



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Html-template-users mailing list
Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users

[htmltmpl] RFC: Persistent or 2-stage evaluation

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

Sam, earlier I said it would be useful if I could apply some evaluation
once. Then operate upon that partially evaluated template. I didn't realize
H::T applies everything at output(?).

If H::T applies everything at output, wouldn't it be relatively easy to
accomplish this if there was a way to tell H::T to perform an "output" *but
don't eliminate any H::T tags that are unevaluated*?

If I could do this, I could set all my one-time page evaluation and do a
"new_scalar_ref->" (using the output from my first "new->" from a file). If
there were a way to tell H::T to reload it internally there may be a way to
utilize H::T's caching mechanism (instead of me keeping my H::T object in
%hash_of_templates{language}). Doing a "new->" would have to tell me it
reloaded the template so that I could do the one-time processing again (and
output_internal-> to put it back into the state where it's mostely prepared
for repeated processing).

What do you think? Would it be easy to do by sub-classing?

Did you eventually agree there is a legitimate case for one-time page
evaluation? (One-time language replacement of title, headings, navigation,
etc.) I'd like to apply some heavy replacement and do it only once. Keep the
resulting text containing only the tags that are evaluated on a
display-by-display basis (messages, etc.).

This might have some application for select/option lists too. I won't
confuse the issue with that yet. My main concern is just to avoid repetitive
numerous replacement of text which is constant for a page.

Thanks!
Mark

[htmltmpl] Fetching Remote Templates?

[Michael L. <mi...@go...>]

Has anyone ever attempted (or better yet finished) a filter or something
similar to fetch templates on a remote server using LWP? Perhaps the tag
looking like:

<TMPL_INCLUDE name="/path/to/file.tmpl" href="http://www.somewhere.com"
expires="3600">

I realize that this could (and probably should) be accomplished outside of
template the in other ways, just wondering if anyone has tried this.


Mike

Re: [htmltmpl] TMPL_IF and OR

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

On Fri, 14 Jan 2005, Thomas Gutzler wrote

> <TMPL_IF NAME=FOO>foo</TMPL_IF>

That should work fine now.

> <TMPL_IF NAME=FOO OR NAME=BAR>foo or bar</TMPL_IF>

Use HTML::Template::Expr and write it:

  <TMPL_IF EXPR="FOO || BAR">foo or bar</TMPL_IF>

-sam

Re: [htmltmpl] TMPL_IF and OR

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

From: "Thomas Gutzler" <gi...@gm...>
> Could something like this be possible:

Why not say:

<TMPL_VAR NAME=FOO_BAR>

And then perform the conditional processing in your Perl program to set
$my_foo_bar and output it to the template thusly:

$template->param(FOO_BAR => $my_foo_bar);

Otherwise you could do TMPL_IF and TMPL_ELSE

<TMPL_IF NAME=FOO>
  <TMPL_IF NAME=BAR>foo or bar
  <TMPL_ELSE>foo
  </TMPL_IF>
<TMPL_ELSE>bar
</TMPL_IF>

If it were me, I'd rather keep this kind of logic in your template or
script. TMPL_ELSE_IF would be kind of nice to reduce the clutter.

Mark

----- Original Message ----- 
From: "Thomas Gutzler" <gi...@gm...>
To: <htm...@li...>
Sent: Friday, January 14, 2005 1:35 PM
Subject: [htmltmpl] TMPL_IF and OR


> Hi,
> I'm new to this list and couldn't find anything comparable to this in
> the archives:
> I have a feature request.
> Could something like this be possible:
>
> <TMPL_IF NAME=FOO>foo</TMPL_IF>
> <TMPL_IF NAME=FOO OR NAME=BAR>foo or bar</TMPL_IF>
> <TMPL_IF NAME=BAR>bar</TMPL_IF>
>
> Wouldn't that be nice?
>
> Cheers, Tom
> -- 
> Mosher's Law of Software Engineering:
> Don't worry if it doesn't work right.  If everything did, you'd
> be out of a job.
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

[htmltmpl] TMPL_IF and OR

[Thomas G. <gi...@gm...>]

Hi,
I'm new to this list and couldn't find anything comparable to this in
the archives:
I have a feature request.
Could something like this be possible:

<TMPL_IF NAME=FOO>foo</TMPL_IF>
<TMPL_IF NAME=FOO OR NAME=BAR>foo or bar</TMPL_IF>
<TMPL_IF NAME=BAR>bar</TMPL_IF>

Wouldn't that be nice?

Cheers, Tom
-- 
Mosher's Law of Software Engineering:
	Don't worry if it doesn't work right.  If everything did, you'd
be out of a job.

Re: [htmltmpl] HTML::Template Caching Problems

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

On Wed, 12 Jan 2005, Patrick Humpal wrote:

> I have two standard templates that all my pages use: headers.shtml
> and footers.shtml.  However, it seems as if one of my CGI files is
> reading the headers.shtml file from an older cached version while my
> other CGI file is reading the the more recent one.

Are you sure you're looking at the right CGI?  What happens if you put
this right at the top of the bad CGI:

  die("HELLO!");

Do you see an ISE when you hit the CGI?  Do you see HELLO! in the
error logs?  I do this test whenever nothing I do seems to work right
just to be sure I'm editing the right file.

Do you see the bad behavior if you run the CGI from the command-line?
If not then you've probably got something wrong or different in the
server configuration which is affecting your script.

Are you running in Apache/mod_perl with Apache::Registry perhaps?  If
so you may be experiencing the effects of unintended closure usage.

> use HTML::Template;
> ...
> my $header_template = HTML::Template->new(filename=>'/var/www/html/headers.shtml');
> my $footer_template = HTML::Template->new(filename=>'/var/www/html/footers.shtml');

That's not really enough code to debug.  I can see you're not using
any caching options but I can't really see what else you might be
doing wrong...


-sam

[htmltmpl] HTML::Template Caching Problems

[Patrick H. <ph...@ex...>]

I have two standard templates that all my pages use: headers.shtml and =
footers.shtml.  However, it seems as if one of my CGI files is reading the =
headers.shtml file from an older cached version while my other CGI file is =
reading the the more recent one.

I've checked directories containing both files as well as the directory =
with the .shtml files to see if there are hidden or cache files but there =
are none.

The changes I made yesterday were simply adding two links.  I have a =
couple more html and shtml files that have picked up the changes just =
fine.   This is what's contained in both files:

use HTML::Template;
...
my $header_template =3D HTML::Template->new(filename=3D>'/var/www/html/head=
ers.shtml');
my $footer_template =3D HTML::Template->new(filename=3D>'/var/www/html/foot=
ers.shtml');
...
print $header_template->output;
...
print $footer_template->output;
...

I have also checked Template.pm to make sure caching was turned off.  Any =
ideas?

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

> > although I wouldn't consider some of the enhancements "feature
> > creep" (ie I think not having TMPL_ELSIF would mean that a feature
> > is missing) -> I thank him for producing a very use piece of code.
>=20
> Thanks, I appreciate that.  I'm certainly not above changing my mind
> if enough people see a need for a particular feature.  I'm definitely
> thinking about doing something about variable TMPL_INCLUDEs, for
> example.

ok - thats good to hear...
=20
> > And these enhancements show that H::T can undergo more enhancements
> > without 'breaking'... some of the features added to this version,
> > are based on ideas from the people on this list -> they were added
> > without a major re-architecture, more like a code evolution.
>=20
> When I think about the dangers of feature creep I think about
> global_vars.  It's a great feature which I've come to think of as the
> way HTML::Template should have worked from the beginning.  It's also a
> terrible hack which still doesn't work quite right and clutters the
> code in a number of places.

fair enough - the way I look at it is:

   if it works, then it will always be a better design that something =
which doesn't yet exist...

H::T may contain some hacks, but most of the cool stuff in this world, =
is a result of good hacks...  I consider H::T to be a good hack... :-)


> > - I absolutely needed some bug fixes which Sam hasn't fixed
>=20
> Can you refresh my memory about these?

The main one that needed fixing was that the wrong *fname *fcounter and =
*fmax where populated when reaching the end of more than one =
TMPL_INCLUDEd file.  Starting at line 2300, it reads:

    # count newlines in chunk and advance line count
    $fcounter +=3D scalar(@{[$chunk =3D~ m/(\n)/g]});
    # if we just crossed the end of an included file
    # pop off the record and re-alias to the enclosing file's info
    pop(@fstack), (*fname, *fcounter, *fmax) =3D \ ( =
@{$fstack[$#fstack]} )
      if ($fcounter > $fmax);


where as it should read:

    # count newlines in chunk and advance line count
    $fcounter +=3D scalar(@{[$chunk =3D~ m/(\n)/g]});
    # if we just crossed the end of an included file
    # pop off the record and re-alias to the enclosing file's info
    while ($fcounter > $fmax) {
      my $counter_offset =3D $fcounter - $fmax;
      pop(@fstack), (*fname, *fcounter, *fmax) =3D \ ( =
@{$fstack[$#fstack]} );
      $fcounter +=3D $counter_offset;
    }

Notice here that we pop() the current frame off multiple times, =
depending on how many TMPL_INCLUDEs deep were at.
I cant remember _why_ I needed it fixed, but I remember being bitten a =
few times when I forgot to apply the patch...


Another...

sub _normalise_options {...}  (line 1582) is used to push options into =
LOOPs, but doesn't work 100% of the time when used with H::T::E, as the:

   $template->{options}{expr}
   $template->{options}{expr_func}

values are not pushed into the LOOP.  Again I cant remeber why I fixed =
it, but it needed doing...  Note that this fix implies also pushing =
'expr ' and 'expr_func' onto the _new_from_loop(%hash) (ie where it is =
used in the '/TMPL_LOOP' test, line 2067)


And for the purests...  H::T::E should read (line 236):

  $self =3D $self->SUPER::output(...);

rather than :

  my $result =3D HTML::Template::output($self, ...);

just in case someone is overloading $self->output().


> > (note that most of these changes / enhancements cant be made by
> > subclassing H::T...)
>=20
> Which ones would you consider impossible?  I'm sure I could implement
> TMPL_xxx extensions and TMPL_ELSIF in a sub-class.

granted, if you can sub-class to create TMPL_xxx, you can quite easily =
create TMPL_ELSIF...  but TMPL_ELSIF is such a nice thing to have as =
part of the standard H::T....


As for custom TMPL_xxx, I dont see how you can simply subclass '_parse' =
to detect your custom tag, without impacting quite a large performance =
hit.   The simplest solution is to have H::T's big honking regex, =
capture TMPL_xxx directly; then if the user has the 'use_custom_tag' =
enabled in the options, call into the sub-class via a virtual function.


cheers,
Mathew

PS:  As for custom TMPL_VAR ESCAPE support (which I didn't mention =
before), I simply moved the package definitions into their own files so =
that H::T can dynamically load them.  This allows me to have as many =
useful/useless ESCAPE types that I care for, just by sub-classing from =
H::T::ESCAPE, ie, I can do the following:

   some html...<TMPL_VAR NAME=3D"data" ESCAPE=3D"MyCustomEscapeRoutine">

Where "MyCustomEscapeRoutine" gets auto-loaded by H::T...

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

On Tue, 11 Jan 2005, Mathew Robertson wrote:

> I respect Sam's opinion on what should and shouldn't go into H::T,
> although I wouldn't consider some of the enhancements "feature
> creep" (ie I think not having TMPL_ELSIF would mean that a feature
> is missing) -> I thank him for producing a very use piece of code.

Thanks, I appreciate that.  I'm certainly not above changing my mind
if enough people see a need for a particular feature.  I'm definitely
thinking about doing something about variable TMPL_INCLUDEs, for
example.

> And these enhancements show that H::T can undergo more enhancements
> without 'breaking'... some of the features added to this version,
> are based on ideas from the people on this list -> they were added
> without a major re-architecture, more like a code evolution.

When I think about the dangers of feature creep I think about
global_vars.  It's a great feature which I've come to think of as the
way HTML::Template should have worked from the beginning.  It's also a
terrible hack which still doesn't work quite right and clutters the
code in a number of places.

> - I absolutely needed some bug fixes which Sam hasn't fixed

Can you refresh my memory about these?

> (note that most of these changes / enhancements cant be made by
> subclassing H::T...)

Which ones would you consider impossible?  I'm sure I could implement
TMPL_xxx extensions and TMPL_ELSIF in a sub-class.

-sam

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

I respect Sam's opinion on what should and shouldn't go into H::T, =
although I wouldn't consider some of the enhancements "feature creep" =
(ie I think not having TMPL_ELSIF would mean that a feature is missing) =
-> I thank him for producing a very use piece of code. =20

And these enhancements show that H::T can undergo more enhancements =
without 'breaking'... some of the features added to this version, are =
based on ideas from the people on this list -> they were added without a =
major re-architecture, more like a code evolution.

That said, the reason that I put together the functionality in my =
version of the H::T bundle was that I very-much needed certain =
functionality, such as:

- TMPL_ELSIF make my templates a lot clearer to read (under some =
circumstances)
- I absolutely need support for custom TMPL_xxx constructs
- I absolutely needed some bug fixes which Sam hasn't fixed


As to putting it up on CPAN... what would I call it ?    =
HTML::TemplateEnhanced ?

(note that most of these changes / enhancements cant be made by =
subclassing H::T...)

Mathew



> OK, I understand. So I guess my question is redirected to Mathew, =
could
> you subclass H::T and put your version on CPAN?
>=20
> > > Your version has some nice features that I could use, especially =
the
> > > recursive HTML::Template invocation.  Is there a reason why Sam =
has
> > > not included your mods into the CPAN version?
> >=20
> > The discussion of these changes is available in the mailing-list
> > archive.  If memory serves I didn't think that most of them required
> > changes to HTML::Template itself.  My feeling is that if
> > HTML::Template::Expr could be done without changes to HTML::Template
> > then there's really no limit on the changes that can be accomplished
> > by a sub-class using filter.
> >=20
> > Put simply, HTML::Template has suffered from feature-creap through =
its
> > life and it's nearly at the breaking point now.  The current =
code-base
> > won't remain maintainable with many more features added without a
> > major rearchitecture.  Someday maybe I'll do that and then all kinds
> > of extension will be easier...

Re: [htmltmpl] Select/option lists (how to generate)

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

From: Philip Tellis <phi...@gm...>
>
>I do it by pushing the selected evaluation right to the SQL:
>
>SELECT foo, bar, baz, IF(bar='myval', 'selected', '') AS selected FROM 
>...
>
>and then just throw it into an arrayref.

That's the nifty SQL I mentioned seeing before. It was posted by Puneet.[1]

============================
SELECT val,
         text,
         (if then else to return "selected" or "") AS selected
 FROM table
 WHERE whatever...
 
 then in my template...
 
 <tmpl_loop occupations>
    <option value="<tmpl_var val>" <tmpl_var selected>>
      <tmpl_var text>
    </option>
 </tmpl_loop>
=============================

But, the other nifty part was posted by Jason. He suggested using DBI's fetchall_arrayref to directly populate the template without putting the values in your own hash:

=============================
 $sth->execute();
 $template->param( "OCCUPATION_LOOP" => $sth->fetchall_arrayref( {} ) );
=============================

[1] http://sourceforge.net/mailarchive/message.php?msg_id=8192715
[2] http://sourceforge.net/mailarchive/message.php?msg_id=8192723

Mark

Re: [htmltmpl] Using HTML::Template to prefill in values

[Clifton R. <cli...@ti...>]

On Mon, Jan 10, 2005 at 06:33:54PM +1100, Michael Kraus wrote:
> I'm curious about using HTML::Template to pre-fill in form field values.
...
> 
> What I'm currently using is this method
> 
> <input name="my_input_box"<TMPL_IF NAME="my_input_box_value">
> value="<TMPL_VAR NAME="my_input_box_value">"</TMPL_IF>>
> 
> This works great for filling in text boxes. However, how can this be
> done for select boxes (drop-down lists)?
> 
> Currently I've got a select box that looks like this:
> ---CUT---
> <select name="my_select">
>   <TMPL_LOOP NAME="my_select_loop">
>   <option value="<TMPL_VAR NAME="id">"><TMPL_VAR
> NAME="description"></option>
>   </TMPL_LOOP>
> </select>
> ---CUT---
> 
> I can't see how HTML::Template would cope with this in an automagic way.
> (???)
> 
> I'm guessing, I could use ecma-script/j-script/javascript in the HTML
> with variables set to HTML::Template variables.
> 
...
> Or something like the following:
> 
> In Template:
> ---CUT---
> <select name="my_select">
>   <TMPL_LOOP NAME="my_select_loop">
>   <option value="<TMPL_VAR NAME="id">"<TMPL_IF NAME="selected">
> selected</TMPL_IF>><TMPL_VAR NAME="description"></option>
>   </TMPL_LOOP>
> </select>
> ---CUT---
> 
> In code:
> ---CUT---
> for $item (@$my_select_loop) {
> 	$item->{selected} = 1 if $item->{id} eq $cgi->param("id");
> }
> [...]
> $template->param("my_select_loop" => $my_select_loop);
> print $cgi->header, $template->output;
> ---CUT---
> 
> Is there a simpler way, or am I just asking too much and should stop
> whinging and continue coding? :)

  That would be the proper way.  However, I've been known to cheat.

  It turns out you can have duplicate values in pull-down lists.
Therefore, in most cases, if you find it aesthetically acceptable, you
can simply do this:

<select name="my_select">
  <TMPL_IF NAME="my_select_value">
  <option selected value="<TMPL_VAR NAME="my_select_value">"><TMPL_VAR
NAME="my_select_description"></option></TMPL_IF>
  <TMPL_LOOP NAME="my_select_loop">
  <option value="<TMPL_VAR NAME="id">"><TMPL_VAR
NAME="description"></option>
  </TMPL_LOOP>
</select>

  The effect is that your selected value appears twice in the list -
once at the top, selected, and once down in the body.  I have not seen
either a browser or a user balk at this yet, though I personally find
it a bit less aesthetically pleasing.

  -- Clifton

-- 
          Clifton Royston  --  cli...@ti... 
         Tiki Technologies Lead Programmer/Software Architect
Did you ever fly a kite in bed?  Did you ever walk with ten cats on your head?
  Did you ever milk this kind of cow?  Well we can do it.  We know how.
If you never did, you should.  These things are fun, and fun is good.
                                                                 -- Dr. Seuss

Re: [htmltmpl] Select/option lists (how to generate)

[Philip T. <phi...@gm...>]

Sometime on Jan 10, Mark A. Fuller assembled some asciibets to say:

>    # %db_vals is automatically populated because the prepared statement
>    # has "bind_col" each column to a $db_vals{key}.
>
>      if ($db_vals{code} eq $selected_value) {
>        $sel = ' selected="selected"';
>      }

I do it by pushing the selected evaluation right to the SQL:

SELECT foo, bar, baz, IF(bar='myval', 'selected', '') AS selected FROM 
...

and then just throw it into an arrayref.

-- 
The days are all empty and the nights are unreal.

[htmltmpl] Select/option lists (how to generate)

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

>What I'm currently using is this method
>
> <input name="my_input_box"<TMPL_IF NAME="my_input_box_value">
> value="<TMPL_VAR NAME="my_input_box_value">"</TMPL_IF>>

I don't believe you need the conditional. You can let "my_input_box_value" evaluate always. If it contains nothing, it will evaluate to nothing. Your template won't be as cluttered. 

>However, how can this be done for select boxes (drop-down lists)?

This was the thing that was the most difficult for me. I thought H::T should have a mechanism to handle this more directly. What I do is loop selecting my values from a database into a hash (using DBI "fetch"). 

=======================================
while ($sth_select_some_list->fetch) {

    # %db_vals is automatically populated because the prepared statement
    # has "bind_col" each column to a $db_vals{key}.

      if ($db_vals{code} eq $selected_value) {
        $sel = ' selected="selected"';
      }
      else {
        $sel = '';
      }

    push @loop_data, {
         VAL      => $db_vals{code},
         TEXT     => $db_vals{display},
         SELECTED => $sel,
         LANG     => ' lang="en"'
    }

} # end loop

$template->param(MY_LOOP => \@loop_data);
==================================

And then the template looks like this:

==================================
<select id="my_list" name="my_list">
<TMPL_LOOP NAME=MY_LOOP><option value="<TMPL_VAR NAME=VAL>"<TMPL_VAR NAME=SELECTED>><TMPL_VAR NAME=TEXT></option></TMPL_LOOP>
</select>
==================================

A few months ago someone posted a nifty SQL select that created the array to be passed to the template (all in one SQL). 

I actually do a one-time select into a hash, and regenerate the select list with each display. I do this because I translate the values selected from a table into whatever language the visitor chose. I don't want to do that with each display. So, I select and translate when I detect the first time the page will be displayed in that language. I generate the select list from a those values which I keep in memory as long as my script is in memory.

This gets back to how I wish there was a way to perform evaluation upon the cached H::T template. I could evaluate the select list values with the language. And then only evaluate the "selected" attribute for each display.

Mark

Re: [htmltmpl] Using HTML::Template to prefill in values

[Carl F. <C.A...@du...>]

Micheal,

You've got the right idea there, that's generally how it's done and
yes, it's a bit of a pain.

One other option is to fill the template without the form selections,
then use HTML::FillInForm to set the form parameters.

Another option if you're just dealing with date / time select menus is
to use my HTML::Menu::DateTime to create the data structures suitable
for filling the template.
The distribution includes template files that you can use.
It's available at http://search.cpan.org or
http://sourceforge.net/projects/html-menu 

Cheers,
Carl


>>> "Michael Kraus" <mk...@wi...> 01/10/05 7:33 am >>>
G'day all...

I'm curious about using HTML::Template to pre-fill in form field
values.

What I'm currently using is this method

<input name="my_input_box"<TMPL_IF NAME="my_input_box_value">
value="<TMPL_VAR NAME="my_input_box_value">"</TMPL_IF>>

This works great for filling in text boxes. However, how can this be
done for select boxes (drop-down lists)?

Currently I've got a select box that looks like this:
---CUT---
<select name="my_select">
  <TMPL_LOOP NAME="my_select_loop">
  <option value="<TMPL_VAR NAME="id">"><TMPL_VAR
NAME="description"></option>
  </TMPL_LOOP>
</select>
---CUT---

I can't see how HTML::Template would cope with this in an automagic
way.
(???)

I'm guessing, I could use ecma-script/j-script/javascript in the HTML
with variables set to HTML::Template variables.

Or something like the following:

In Template:
---CUT---
<select name="my_select">
  <TMPL_LOOP NAME="my_select_loop">
  <option value="<TMPL_VAR NAME="id">"<TMPL_IF NAME="selected">
selected</TMPL_IF>><TMPL_VAR NAME="description"></option>
  </TMPL_LOOP>
</select>
---CUT---

In code:
---CUT---
for $item (@$my_select_loop) {
	$item->{selected} = 1 if $item->{id} eq $cgi->param("id");
}
[...]
$template->param("my_select_loop" => $my_select_loop);
print $cgi->header, $template->output;
---CUT---

Is there a simpler way, or am I just asking too much and should stop
whinging and continue coding? :)

TIA!

Regards,
 

Michael S. E. Kraus
B. Info. Tech. (CQU), Dip. Business (Computing)
Software Developer
Wild Technology Pty Ltd
_______________________________
ABN 98 091 470 692
Level 4 Tiara, 306/9 Crystal Street, Waterloo NSW 2017, Australia
Telephone 1300-13-9453 |  Facsimile 1300-88-9453
http://www.wildtechnology.net 
 
The information contained in this email message and any attachments
may
be confidential information and may also be the subject of client
legal
- legal professional privilege. If you are not the intended recipient,
any use, interference with, disclosure or copying of this material is
unauthorised and prohibited.   This email and any attachments are also
subject to copyright.  No part of them may be reproduced, adapted or
transmitted without the written permission of the copyright owner.  If
you have received this email in error, please immediately advise the
sender by return email and delete the message from your system.


--------------------------------------------------------------------------------

Wild Technology Pty Ltd , ABN 98 091 470 692
Sales - Ground Floor, 265/8 Lachlan Street, Waterloo NSW 2017
Admin - Level 4 Tiara, 306/9 Crystal Street, Waterloo NSW 2017
Telephone 1300-13-9453 |  Facsimile 1300-88-9453
http://www.wildtechnology.net 
DISCLAIMER & CONFIDENTIALITY NOTICE:  The information contained in this
email message and any attachments may be confidential information and
may also be the subject of client legal - legal professional privilege.
If you are not the intended recipient, any use, interference with,
disclosure or copying of this material is unauthorised and prohibited.  
This email and any attachments are also subject to copyright.  No part
of them may be reproduced, adapted or transmitted without the written
permission of the copyright owner.  If you have received this email in
error, please immediately advise the sender by return email and delete
the message from your system.




-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Html-template-users mailing list
Htm...@li... 
https://lists.sourceforge.net/lists/listinfo/html-template-users

Re: [htmltmpl] Using HTML::Template to prefill in values

[Daniel A. <dan...@sn...>]

On Monday 10 January 2005 2:33 am, Michael Kraus wrote:
> G'day all...
>
> I'm curious about using HTML::Template to pre-fill in form field values.
>
> What I'm currently using is this method
>
> <input name="my_input_box"<TMPL_IF NAME="my_input_box_value">
> value="<TMPL_VAR NAME="my_input_box_value">"</TMPL_IF>>
>
> This works great for filling in text boxes. However, how can this be
> done for select boxes (drop-down lists)?
>
Have you considered using CGI::FormBuilder?  It makes creating, populating and 
validating HTML forms a snap, and it's integrated with HTML::Template too.

[htmltmpl] Using HTML::Template to prefill in values

[Michael K. <mk...@wi...>]

G'day all...

I'm curious about using HTML::Template to pre-fill in form field values.

What I'm currently using is this method

<input name=3D"my_input_box"<TMPL_IF NAME=3D"my_input_box_value">
value=3D"<TMPL_VAR NAME=3D"my_input_box_value">"</TMPL_IF>>

This works great for filling in text boxes. However, how can this be
done for select boxes (drop-down lists)?

Currently I've got a select box that looks like this:
---CUT---
<select name=3D"my_select">
  <TMPL_LOOP NAME=3D"my_select_loop">
  <option value=3D"<TMPL_VAR NAME=3D"id">"><TMPL_VAR
NAME=3D"description"></option>
  </TMPL_LOOP>
</select>
---CUT---

I can't see how HTML::Template would cope with this in an automagic way.
(???)

I'm guessing, I could use ecma-script/j-script/javascript in the HTML
with variables set to HTML::Template variables.

Or something like the following:

In Template:
---CUT---
<select name=3D"my_select">
  <TMPL_LOOP NAME=3D"my_select_loop">
  <option value=3D"<TMPL_VAR NAME=3D"id">"<TMPL_IF NAME=3D"selected">
selected</TMPL_IF>><TMPL_VAR NAME=3D"description"></option>
  </TMPL_LOOP>
</select>
---CUT---

In code:
---CUT---
for $item (@$my_select_loop) {
	$item->{selected} =3D 1 if $item->{id} eq $cgi->param("id");
}
[...]
$template->param("my_select_loop" =3D> $my_select_loop);
print $cgi->header, $template->output;
---CUT---

Is there a simpler way, or am I just asking too much and should stop
whinging and continue coding? :)

TIA!

Regards,
=20

Michael S. E. Kraus
B. Info. Tech. (CQU), Dip. Business (Computing)
Software Developer
Wild Technology Pty Ltd
_______________________________
ABN 98 091 470 692
Level 4 Tiara, 306/9 Crystal Street, Waterloo NSW 2017, Australia
Telephone 1300-13-9453 |  Facsimile 1300-88-9453
http://www.wildtechnology.net
=20
The information contained in this email message and any attachments may
be confidential information and may also be the subject of client legal
- legal professional privilege. If you are not the intended recipient,
any use, interference with, disclosure or copying of this material is
unauthorised and prohibited.   This email and any attachments are also
subject to copyright.  No part of them may be reproduced, adapted or
transmitted without the written permission of the copyright owner.  If
you have received this email in error, please immediately advise the
sender by return email and delete the message from your system.


-------------------------------------------------------------------------=
-------

Wild Technology Pty Ltd , ABN 98 091 470 692
Sales - Ground Floor, 265/8 Lachlan Street, Waterloo NSW 2017
Admin - Level 4 Tiara, 306/9 Crystal Street, Waterloo NSW 2017
Telephone 1300-13-9453 |  Facsimile 1300-88-9453
http://www.wildtechnology.net
DISCLAIMER & CONFIDENTIALITY NOTICE:  The information contained in this =
email message and any attachments may be confidential information and =
may also be the subject of client legal - legal professional privilege. =
If you are not the intended recipient, any use, interference with, =
disclosure or copying of this material is unauthorised and prohibited.   =
This email and any attachments are also subject to copyright.  No part =
of them may be reproduced, adapted or transmitted without the written =
permission of the copyright owner.  If you have received this email in =
error, please immediately advise the sender by return email and delete =
the message from your system.

[htmltmpl] One-time evaluation (was conditional include)

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

From: "Sam Tregar" <sa...@tr...>
> Are you sure it needs to happen "only once"?  Your example doesn't
> support that meaning.  In your example the language-specific stuff
> needs to change when the language changes.

Sam. First, thank you for your consideration.

I only load a template for a language once. When I load it I perform all the
one-time language-specific value replacements. Otherwise I'd have to keep a
language-specific copy of the template in directory structures and "new" the
template from the correct structure. I used to do this. But now I prefer
keeping all the language specifics in Locale::Maketext and do a one-time
replacement of template values which heretofore had been kept in
language-specific templates.

The psuedo-code looks like this:

==============
if (!exists($template_hash{$visitor_language})) {
  template->new(template-path/name)
  $maketext_languageHandle_hash{$visitor_language} =
Locale::Maketext->get_handle($visitor_language);
  initialize_language_specific($template-hash{$visitor_language},
$maketext_language_handle_hash{$visitor_language});
}
===============

Inside "initialze_language_specific" I do *not* evaluate *everything* in the
template. There are some things that are specific to each display of the
page. So, that's done with each re-display.

Two problems with this mechanism are:

1. I'm effectively caching my own template so I can keep the one-time
evaluations across multiple displays.
   - Now I have to add my own test of whether a template has changed. An
unwelcome movement of functionality in H::T into my domain. :)
   - If I had concerns about how much memory I was consuming and/or how long
I keep a little-used template in memory, I have to build this into my logic.

2. My self-cached template's state is exactly as last output'ed. I can't
take for granted that default (think TMPL_ELSE) evaluations have their
default values. I always have to perform all evaluations (other than the
ones I did in the initialize).

To me this seems like something that could be useful to all H::T users. It
seems like it wouldn't burden H::T to have the option to specify that
evaluation be performed on the cached copy of the template?

Thanks!
Mark

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

On Fri, 7 Jan 2005, Mark Fuller wrote:

> > Why?  I still haven't heard a compelling use-case aside from dynamic
> > includes which I think can be handled in better ways.
> 
> Ooops. We're talking about two different things. What I said above concerns
> evaluation of a template which needs to be performed *only once*.

Are you sure it needs to happen "only once"?  Your example doesn't
support that meaning.  In your example the language-specific stuff
needs to change when the language changes.  It's not as often as the
rest of the variables (presumably) but it's surely not just once.

For transformations that really need to happen only once I suggest you
make them with a text editor!

> Does that sound like a reasonable usage?

Maybe, but I still don't see why you'd want to do it.  HTML::Template
is fast enough that it doesn't seem like a worthwhile optimization
versus the work it would take to implement.

-sam

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

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

> On Fri, 7 Jan 2005, Mark Fuller wrote:
> > However, if you think it would be useful to have a "persistent
evaluation"
> > of the *cached* template (so that the partially-evaluated template is
> > returned with each subsequent "new" method calls), I hope you'll keep it
in
> > mind if/when H::T is enhanced.
>
> Why?  I still haven't heard a compelling use-case aside from dynamic
> includes which I think can be handled in better ways.

Ooops. We're talking about two different things. What I said above concerns
evaluation of a template which needs to be performed *only once*.

For example: let's say a template's title, headings, field captions, etc.,
are generated using Locale::Maketext (to get a foreign language). The
template is evaluated to get this language-specific text into the template.
It wouldn't make sense to have to re-evaluate all this stuff for each
re-display of the page (in this language).

That's why I said that I "new" the same template (as needed for a language)
into a hash keyed by language. This way I have one template for each
language. The problem is: each time I "new" it (for each redisplay) I loose
all the one-time evaluation performed upon the template. I need these
one-time evaluations cached. I can perform my own caching, but then I have
to take steps concerning the state of non-one time evaluations and make sure
I don't take anything for granted. I can't get a fresh copy of the template
as it existed at the time I performed my one-time evaluations. I also have
to perform my own test of whether the template changed so I can discard my
cached copy.

Does that sound like a reasonable usage?

Thanks!
Mark

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

On Fri, 7 Jan 2005, Mark Fuller wrote:

> I'm not a big object guy. Subclassing H::T is probably beyond my capability.

I doubt that.  Give it a try.  If you have trouble, post here and I'll
be happy to give you a hand.  If you have no idea where to start I'd
suggest picking up Damian Conway's "Object Oriented Perl".  It's a
great book.

> However, if you think it would be useful to have a "persistent evaluation"
> of the *cached* template (so that the partially-evaluated template is
> returned with each subsequent "new" method calls), I hope you'll keep it in
> mind if/when H::T is enhanced.

Why?  I still haven't heard a compelling use-case aside from dynamic
includes which I think can be handled in better ways.

> Sorry if this is a dumb question, but is there an easy way I could clone the
> template object in $my_template_hash{$visitor_language}, perform my single
> display-specific evaluations upon it (without disturbing the original
> object), and then reclone it for the next display (discarding the earlier
> clone)? If there is a way, in your opinion would this be more or less
> efficient than me performing my own re-evaluation of things that otherwise
> would be default values (i.e., the problem mentioned in the previous
> paragraph)?

Easy?  No, I doubt it.  I can think of some hard ways...

-sam

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

Matthew,

I second Keith's request. Your feature to <tmpl_incl> a variable-substituted
filename would be valuable to me. But, I'm not comfortable departing from
H::T.

Sam,

I'm not a big object guy. Subclassing H::T is probably beyond my capability.
However, if you think it would be useful to have a "persistent evaluation"
of the *cached* template (so that the partially-evaluated template is
returned with each subsequent "new" method calls), I hope you'll keep it in
mind if/when H::T is enhanced. The only complication I can think of is that
the "new" method would have to provide some kind of result indicating that
it read the template from disk, not cache (so the caller can reinitialize
the cached copy).

I can get around this by by caching my own template object. Instead of
calling "new" with each display of the page (and relying upon any of H::T's
caching mechanisms), I can store the template in
$my_template_hash{$visitor_language} (once, when it is found to be undef),
perform my one-time language-specific evaluation upon that template, and
then use that template for each redisplay of the page.

The only problem here is that I have to be aware of anything that might be
optionally evaluated. Things that default to a certain display. I have to
always evaluate them to be sure they don't have a non-default value when
they should be default (that sounds confusing!).

Sorry if this is a dumb question, but is there an easy way I could clone the
template object in $my_template_hash{$visitor_language}, perform my single
display-specific evaluations upon it (without disturbing the original
object), and then reclone it for the next display (discarding the earlier
clone)? If there is a way, in your opinion would this be more or less
efficient than me performing my own re-evaluation of things that otherwise
would be default values (i.e., the problem mentioned in the previous
paragraph)?

Thanks!
Mark


----- Original Message ----- 
From: "Keith Jackson" <kja...@ey...>
To: "Sam Tregar" <sa...@tr...>
Cc: "Mathew Robertson" <mat...@re...>; "Mark Fuller"
<mar...@ea...>; "HTML::Template users"
<htm...@li...>
Sent: Wednesday, January 05, 2005 11:40 AM
Subject: Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE


> OK, I understand. So I guess my question is redirected to Mathew, could
> you subclass H::T and put your version on CPAN?
>
> Thanks!
>
> PS.  IMHO It doesn't get said enough, H::T is a GREAT module and all the
> people involved deserve tons of credit!  Thanks and have a great New
> Year.
>
> Keith
> On Wed, 2005-01-05 at 13:07, Sam Tregar wrote:
> > On Wed, 5 Jan 2005, Keith Jackson wrote:
> >
> > > Your version has some nice features that I could use, especially the
> > > recursive HTML::Template invocation.  Is there a reason why Sam has
> > > not included your mods into the CPAN version?
> >
> > The discussion of these changes is available in the mailing-list
> > archive.  If memory serves I didn't think that most of them required
> > changes to HTML::Template itself.  My feeling is that if
> > HTML::Template::Expr could be done without changes to HTML::Template
> > then there's really no limit on the changes that can be accomplished
> > by a sub-class using filter.
> >
> > Put simply, HTML::Template has suffered from feature-creap through its
> > life and it's nearly at the breaking point now.  The current code-base
> > won't remain maintainable with many more features added without a
> > major rearchitecture.  Someday maybe I'll do that and then all kinds
> > of extension will be easier...
> >
> > -sam
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by: Beat the post-holiday blues
> > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> > _______________________________________________
> > Html-template-users mailing list
> > Htm...@li...
> > https://lists.sourceforge.net/lists/listinfo/html-template-users
> -- 
> Keith Jackson <kja...@ey...>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users