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

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

[Keith J. <kja...@ey...>]

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

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

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

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

On Tue, 4 Jan 2005, Mark Fuller wrote:

> I just had a need to conditionally include one of a few templates dependnig
> on the value of a TMPL_VAR. One of the includes (which would not have been
> loaded) did not exist, but H::T died because it couldn't locate that file. I
> realized H::T probably loads everything at compile time and applies the
> conditions at the time the output method is called.

And just to explain why this was done in the first place,
HTML::Template allows includes to be syntactically invalid.  For
example, this is valid:

  <tmpl_loop foo>
     <tmpl_var bar>
  <tmpl_include foo_end.tmpl>

And foo_end.tmpl:

  </tmpl_loop>

Obviously there's no way to parse this without doing the include at
compile-time.

Now, maybe this was a mistake.  I've considered breaking this support
in my fantasy version 3 rewrite.  But at least for v2 it has to stay.

> However, I still feel like I have a need to conditionally load included
> templates and I know which ones they are at compile time. It's not going to
> change over repeated outputs called on the same cached template. I'm faced
> with either structuring the template includes differently (making it uglier
> and some duplicated HTML). Or, let it load all the stuff I know I don't need
> at compile time and use a TMPL_VAR (the same value for the life of the
> template) to tell the output method which included fragment to output.

I've thought about allowing something like:

  $t = HTML::Template->new(filename => 'foo.tmpl',
                           includes => { bar => 'bar.tmpl' });

And in foo.tmpl:

  <tmpl_include name="bar">

This would have to be factored into the cache-signature, but since
that's now centralized in a single place in the code that should be
easy enough.

Actually, it occurs to me that this would be pretty easy to do with
filter in a sub-class.  So you don't even have to wait for me!

> Question: Does this lead to the idea that it would be useful to have
> variables used only at compile time? When I tell it to load a
> template, why can't I give it variable name=value pairs to apply
> *only* at compile time?

Aside from doing variable includes, is there any other reason to want
this?  I doubt it would be much more efficient in the general case
for just a few variables.  Compared to the difficulty of coding it in
the current code-base it doesn't seem worthwhile.

-sam

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

From: "Keith Jackson" <kja...@ey...>
> On Wed, 2005-01-05 at 01:58, Mathew Robertson wrote:
> > http://members.optusnet.com.au/mathew/
>
> 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?
> I'd like to stay consistent and use versions from CPAN for our production
servers.

I agree. Matt's feature to do

       <TMPL_INCLUDE <TMPL_VAR NAME="VARIABLE_INCLUDE_FILE">>

would make H::T easier to use (in the example where I have a side navigation
bar used in 20 pages and the only thing different is the list element of
links).

I'd like to hear what Sam thinks of this.

I'd also like to hear what he or others think of my suggestion to be able to
perform "permanent" evaluation on a template. I really think this would be
useful such as the example where I language translate a template and all
that evaluation of the template is permanent for the life of the loaded
template.

I suppose the one complication is that a cached template is not gauranteed
to be present? Doesn't it discard cached templates after a certain cache
size is reached? I guess there would need to be a way to test if the
template is in cache and, if not, I'd have to re-execute my tmpl_load and
all the one-time evaluation. Or, the ability to mark a tmpl_load'ed template
as not discardable?

Mark

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

[Keith J. <kja...@ey...>]

On Wed, 2005-01-05 at 01:58, Mathew Robertson wrote:
> hmm... I'm not sure I can answer how you would go about making H::T do a compile-time parse, but I can solve your need for <TMPL_INCLUDE <TMPL_VAR num>>...
> 
> I use a modified version of H::T which does this (and a number of other useful things, such as custom TMPL tags).  Go to:
> 
> http://members.optusnet.com.au/mathew/
> 

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?
I'd like to stay consistent and use versions from CPAN for our production servers.

Keith

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

hmm... I'm not sure I can answer how you would go about making H::T do a =
compile-time parse, but I can solve your need for <TMPL_INCLUDE =
<TMPL_VAR num>>...

I use a modified version of H::T which does this (and a number of other =
useful things, such as custom TMPL tags).  Go to:

http://members.optusnet.com.au/mathew/

and download the version of H::T from there.  The perldoc explains how =
to enable recursive templates.

Mathew

PS.  I am very familar with Locale::Maketext, and I think it is a great =
step forward in handling language translation capabilities (compared to =
say 'catgets'),  however I found it to be limiting in some specific =
ways, thus I created Locale::MakePhrase which I believe to be much more =
powerful.



----- Original Message -----=20
From: "Mark Fuller" <mar...@ea...>
To: "Mathew Robertson" <mat...@re...>; =
<htm...@li...>
Sent: Wednesday, January 05, 2005 2:03 PM
Subject: Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE


> Here's another example.
>=20
> To accomodate multiple foreign languages I store my loaded templates =
in a
> hash keyed by language code. The loaded template is mostly the same =
template
> files with param information filled in specific to the language. My
> procedure is this: I always check if the template exists in the hash =
for
> each display of the page (using the visitor's language preference). If =
not,
> I go through my load process which involves "tmpl_load" and a series =
of
> Locale::Maketext calls to translate English into whatever language the
> template needs to be in. Generally, this means using the param method =
to set
> the xml:lang, the encoding, the stylesheet (to get the font for =
non-Roman
> languages), and a slew of Maketext calls to translate fill in form =
captions,
> heading values, etc.
>=20
> Not all the page text dynamically translated like this. Some larger
> paragraph text may exist in files included into the template from a
> directory structure representing  the language (like =
/templates/en-US). This
> gets back to the earlier example of how it's difficult to dynamically =
select
> includes. (In this case HTML_TEMPLATE_ROOT would work *if* all my =
templates
> (non-language specific) existed in that directory too.)
>=20
> Anyway, this language processing only needs to be done *at the time =
the
> template is loaded*. I don't need to do it for each output of the =
template.
> I'm keeping my own template objects for each language (in the hash). =
There
> are only a few output-time params that need to be re-evaluated at =
output
> time (status message, select lists because the selection may have =
changed,
> form fields). All the translated text performed when the template was =
first
> tmpl-loaded doesn't need to be re-evaluated.
>=20
> This case is a little different than the previous example. In the =
previous
> example, I needed substitution to occur at compile time. In this case, =
I
> need to specify that the evaluation of the param is *permanent*. If
> compile-time substitution were available I could setup all my =
name=3Dvalue
> pairs prior to the tmpl-load. But, in my mind I'd rather do the =
tmpl-load
> (specifying anything that needs to be done at compile time, like the
> conditional include mentioned previously) and then have a method to =
perform
> one-time, permanent substitution to the loaded template. This way I =
could
> issue my numerous Maketext calls after the template is loaded and let =
the
> results be stored in the template rather than creating my own =
temporary
> holder just to so the values are available at compile time (assuming =
there
> could be a feature to perform compile-time evaluation).
>=20
> Does that make sense? Am I completely missing something?
>=20
> Thanks,
> Mark
>=20
> 

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

Here's another example.

To accomodate multiple foreign languages I store my loaded templates in a
hash keyed by language code. The loaded template is mostly the same template
files with param information filled in specific to the language. My
procedure is this: I always check if the template exists in the hash for
each display of the page (using the visitor's language preference). If not,
I go through my load process which involves "tmpl_load" and a series of
Locale::Maketext calls to translate English into whatever language the
template needs to be in. Generally, this means using the param method to set
the xml:lang, the encoding, the stylesheet (to get the font for non-Roman
languages), and a slew of Maketext calls to translate fill in form captions,
heading values, etc.

Not all the page text dynamically translated like this. Some larger
paragraph text may exist in files included into the template from a
directory structure representing  the language (like /templates/en-US). This
gets back to the earlier example of how it's difficult to dynamically select
includes. (In this case HTML_TEMPLATE_ROOT would work *if* all my templates
(non-language specific) existed in that directory too.)

Anyway, this language processing only needs to be done *at the time the
template is loaded*. I don't need to do it for each output of the template.
I'm keeping my own template objects for each language (in the hash). There
are only a few output-time params that need to be re-evaluated at output
time (status message, select lists because the selection may have changed,
form fields). All the translated text performed when the template was first
tmpl-loaded doesn't need to be re-evaluated.

This case is a little different than the previous example. In the previous
example, I needed substitution to occur at compile time. In this case, I
need to specify that the evaluation of the param is *permanent*. If
compile-time substitution were available I could setup all my name=value
pairs prior to the tmpl-load. But, in my mind I'd rather do the tmpl-load
(specifying anything that needs to be done at compile time, like the
conditional include mentioned previously) and then have a method to perform
one-time, permanent substitution to the loaded template. This way I could
issue my numerous Maketext calls after the template is loaded and let the
results be stored in the template rather than creating my own temporary
holder just to so the values are available at compile time (assuming there
could be a feature to perform compile-time evaluation).

Does that make sense? Am I completely missing something?

Thanks,
Mark

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

From: "Mathew Robertson" <mat...@re...>
>
>which way is it?  either you are providing choice or you're not.

I'm sorry. I probably didn't explain the example very well.

This example is somewhat a problem of nesting, and somewhat a problem of
semi-static values.

Let's say I have 20 different top-level pages (represented by 20 CGI::App
modules). Each has its own set of sub-areas (pages produced by the module).
The side-bar navigation lists the sub-areas a visitor can go to from one
top-level page. Therefore, there is one side-bar structure which can have 20
different sets of values (depending on which module is using it).

I'd like have a top-level page include the side-bar structure which (here's
the important part) contains an include where the filename is partially
constructed by a TMPL_VAR. This way, the side-bar structure can be reused
across the 20 top-level templates, and each top-level template can specify
which list of values should be included in the structure by using a
TMPL_VAR.

      <TMPL_INCLUDE NAME="includes/navigation/area<TMPL_VAR
NAME=AREA_NUM>.html">

I can't do that because H::T (for good reason) loads all the includes at
compile time and performs variable substition at output time. This is a case
where it's not so static that the value can be hard-coded in the included
component. But, not so dynamic that all *20* list values need to be hauled
into the template and re-evaluated at output time using a gigantic <TMPL_IF>
construction. :)

I hope that's a clearer explanation.

I know I could do one of two things to get around this.

1. I could create 20 side-bar includes and simply include the correct one
for the top-level template.

The problem (possibly slight) is that I'll duplicate quite a bit of HTML to
surround the values with the entire construct. All 20 use the same general
construct, it's just the 5-10 list values comprising the actual links that
change.

2. I could organize it differently and include a side-bar_top, the specific
values, and a side-bar_bottom.

That's not the end of the world. But, it starts getting a little ugly when
what we're really talking about is nesting and semi-persistent values.

3. I could use a TMPL_LOOP and replace the values from within my CGI::App
module.

Again, not the end of the world. But, I don't need to re-evaluate with every
output of the template.

It's semi-persistant data. I can't hard code it. And, it doesn't change
after compile time.

I have another example (not involving nesting) regarding language support.
Let me think that one through and I'll write another email.

Thanks for considering this topic,

Mark

[htmltmpl] ANNOUNCE: Krang 1.100

[Peter L. <pe...@pe...>]

We're very pleased to announce that Krang v1.100 is now available.

Notable changes in this release:

  * A large series of UI tweaks have been made - based on feedback,
    button placement and functionality changes have been implemented
    throughout the UI.

  * Story/Media/Template search preferences are now cached during the
    session.

  * Comprehensive support of remote MySQL databases is now complete.

  * Media objects can now be searched by ALT tag.

  * Scheduled publishing of specific story versions now works.

  * A new script, krang_expunge, has been added to remove a single site
    in a multi-site instance.

  * Numerous other small bugfixes and enhancements to Krang.

For more information about Krang, visit the Krang website:

   http://krang.sourceforge.net/

There you can download Krang, view screenshots, read documentation,
join our mailing-lists and access the CVS tree.

Detailed change-log here: http://krang.sf.net/docs/changelog.html

Krang is an Open Source web-publisher / content-management system
designed for large-scale magazine-style websites.  It is a 100% Perl
application using Apache/mod_perl and MySQL, as well as numerous CPAN
modules.

Krang provides a powerful and easy to use story and media editing
environment for magazine editors, as well as a complete template
development environment for web designers. On the back-end, Perl
programmers can customize Krang to control the data entered in the
story editor and add code to drive the templates to build
output. Krang can be enhanced with add-ons containing new skins and
other new features.  Krang easily handles large data sets and can
manage multiple websites in a single installation.


   - the Krang team


----
Peter Leonard
pe...@pe...

Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

> I just had a need to conditionally include one of a few templates =
dependnig
> on the value of a TMPL_VAR. One of the includes (which would not have =
been
> loaded) did not exist, but H::T died because it couldn't locate that =
file. I
> realized H::T probably loads everything at compile time and applies =
the
> conditions at the time the output method is called.
>=20
> This makes sense since caching would be screwed up if it had to keep
> reloading conditional includes with every output.
>=20
> However, I still feel like I have a need to conditionally load =
included
> templates and I know which ones they are at compile time. It's not =
going to
> change over repeated outputs called on the same cached template. I'm =
faced
> with either structuring the template includes differently (making it =
uglier
> and some duplicated HTML). Or, let it load all the stuff I know I =
don't need
> at compile time and use a TMPL_VAR (the same value for the life of the
> template) to tell the output method which included fragment to output.
>=20
> Question: Does this lead to the idea that it would be useful to have
> variables used only at compile time? When I tell it to load a =
template, why
> can't I give it variable name=3Dvalue pairs to apply *only* at compile =
time?

Its an interesting idea...

> I know everyone's a fanatic about efficiency. But, couldn't this lead =
to
> more efficent template processing? If you know you have static values =
used
> for the life of the loaded template, wouldn't it be more efficient to =
apply
> them at the time the template is loaded? Instead of every time the =
output
> method is called?

certainly, except that if a template parameter never changes then just =
add it directly to the html.
=20
> Examples of such life-of-the-template variables might be the language =
and
> encoding variables used to specify the language being used within that
> template? Or, a variable used to pick a navigation side-bar based upon
> system-wide parm? (Customized navigation bars for seasonal occasions? =
Where
> the CGI decides at runtime which one it wants loaded based upon the =
time of
> year?)

umm... both of these examples prove that the template variables are =
dynamic - its just that the lifetime is extremely long compared to most =
template variables.  eg: If a webserver runs for 12 months, then you =
would have to use a different value for the seasonal variations.

> In my case, all my pages share a common sidebar layout, but different
> sidebar choices. I want to nest the set of choices within the common =
sidebar
> layout and let each page (different CGI::App modules) specify which =
set of
> choices should be loaded from that common sidebar layout. But, to do =
that,
> it has to load all of them at compile time and then reevaluate the =
decision
> for each output of the template. When, it's not going to change for =
the life
> of that loaded template.

"...nest the set of choices within the common sidebar layout..." =
precludes "it's not going to change for the life of that loaded =
template"

which way is it?  either you are providing choice or you're not.

> It's not the end of the world. But, it seemed like a potential =
opportunity
> to make H::T a little more efficient by allowing some evaluation =
criteria to
> be performed at compile time.
>=20
> Am I totally off base?

although the concept is interesting (eg compile-time evaluation of =
template variables), however it appears that you cant see the difference =
between static information and dynamic information.

Mathew

[htmltmpl] RFC: Conditional TMPL_INCLUDE

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

I just had a need to conditionally include one of a few templates dependnig
on the value of a TMPL_VAR. One of the includes (which would not have been
loaded) did not exist, but H::T died because it couldn't locate that file. I
realized H::T probably loads everything at compile time and applies the
conditions at the time the output method is called.

This makes sense since caching would be screwed up if it had to keep
reloading conditional includes with every output.

However, I still feel like I have a need to conditionally load included
templates and I know which ones they are at compile time. It's not going to
change over repeated outputs called on the same cached template. I'm faced
with either structuring the template includes differently (making it uglier
and some duplicated HTML). Or, let it load all the stuff I know I don't need
at compile time and use a TMPL_VAR (the same value for the life of the
template) to tell the output method which included fragment to output.

Question: Does this lead to the idea that it would be useful to have
variables used only at compile time? When I tell it to load a template, why
can't I give it variable name=value pairs to apply *only* at compile time?

I know everyone's a fanatic about efficiency. But, couldn't this lead to
more efficent template processing? If you know you have static values used
for the life of the loaded template, wouldn't it be more efficient to apply
them at the time the template is loaded? Instead of every time the output
method is called?

Examples of such life-of-the-template variables might be the language and
encoding variables used to specify the language being used within that
template? Or, a variable used to pick a navigation side-bar based upon
system-wide parm? (Customized navigation bars for seasonal occasions? Where
the CGI decides at runtime which one it wants loaded based upon the time of
year?)

In my case, all my pages share a common sidebar layout, but different
sidebar choices. I want to nest the set of choices within the common sidebar
layout and let each page (different CGI::App modules) specify which set of
choices should be loaded from that common sidebar layout. But, to do that,
it has to load all of them at compile time and then reevaluate the decision
for each output of the template. When, it's not going to change for the life
of that loaded template.

It's not the end of the world. But, it seemed like a potential opportunity
to make H::T a little more efficient by allowing some evaluation criteria to
be performed at compile time.

Am I totally off base?

Thanks,
Mark

[htmltmpl] Re: Re: Templates with template loops within templates

[Eric F. <er...@dm...>]

Hi Joel,

Bad Voodo that you suggest! :)

What I ended up doing is that grand either.. I just put the problem var 
into the hash for the template loop, so it can't miss..

my %inside_hash = ('S_ICON'        => 
$ship_list_hash->{$key}{'courier_icon_url'},
                              'S_COURIER'   => 
$ship_list_hash->{$key}{'courier_name'},
                              'S_METHOD'    => 
$ship_list_hash->{$key}{'courier_method'} ,
                              'S_METHOD_ID' => 
$ship_list_hash->{$key}{'ship_method_id'},
                              'S_COST'      => 
$ship_list_hash->{$key}{'shipping_cost'},
                              'URL_BASE'    => 
$self->param('URL_BASE') 

                    );


But I can see if this was an even more complex problem then I would 
remember your suggestion.
It sounds to me like this qualifies as a bug, not just an oddity or a no 
big deal thing to work around.



Thanks,

Eric

Re: [htmltmpl] Re: Templates with template loops within templates

[Joel L. <joe...@fo...>]

I've seen this problem before. Basically the 'tag' that you have 
returned is being treated as pure data and not a tag at all. A solution? 
Reparse!

Here's what I did:

[GENERAL]
TITLE=HOHOHO
LOGO1=plish

Nevermind the key value pairs, think of the keys as matching TMPL_VARs 
for the purposes of this example. I took the output from one output() 
and basically fed it into a new template with the new_scalar_ref() 
method of the HTML::Template object, like so:

sub _html_from_univ {
    my ($univ, $target ) = @_;
    my $bodyText = _get_universe_data($target);
    my $aRef = HTML::Template->new_scalar_ref(\$bodyText, 
die_on_bad_params=>$bix{'html_die_on_bad_params'});
    return $aRef;
 }

In this implementation the first 'template' is actually a HASH of HASHES 
structure:

{
  'TITLE'=>'<TMPL_VAR NAME="TITLE">',
  'LOGO1'=>'<TMPL_VAR NAME="TITLE"><TMPL_VAR NAME="LOGO1">'
}

Fed to a second template:

<html>
<head>
<title><TMPL_VAR NAME="title"></title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">
...

Yields:

HOHOHOplish

Mind you that with lots of data this reparsing business is SLOW AS HELL. 
I only included it to show you what is happening. A much better way is 
to alter the data itself prior to pushing it onto the template. Writing 
to the template should, ideally, be the last thing you do for 
efficiency's sake.

Sincerely,

Joel 

[htmltmpl] Re: Templates with template loops within templates

[Eric F. <er...@dm...>]

Hi,

I just thought this might be worth posting. This is the template that is in 
the DB that is loaded
as a template var in the main page. The line:

<img src="<TMPL_VAR NAME=URL_BASE>images/shipping/<TMPL_VAR NAME=S_ICON>

is where the problem comes up. Every other URL_BASE in here is replaced 
correctly and of course all of the loop vars are fine as well.

Thanks,

Eric


  <!-- H::T BUG: <TMPL_VAR URL_BASE> -->

<!--Start of Shipping type Section 
-->
   <TABLE  WIDTH=700 class="bord" BORDER=0 CELLPADDING=2 CELLSPACING=0 
align="center">
           <TR> 

                 <TD class="bord" align="center"><span 
class="title">Shipping Method</span></TD>
           </TR> 

           <TR> 

                 <TD> 

                         <!--second color 
table-->
                         <TABLE  WIDTH=700 class="main" BORDER=0 
CELLPADDING=10 CELLSPACING=0 align="center">
                                 <TR> 

                                   <TD class="main" 
align="center">
                                   <!--pieces 
table-->
                             <TABLE WIDTH=95% BORDER=0 CELLPADDING=0 
CELLSPACING=0 align="center">
                     <tr> 

                                   <td><IMG SRC="<TMPL_VAR 
NAME=URL_BASE>images/spacer.gif" WIDTH=10 HEIGHT=5></TD>
                               </tr> 

                     <tr>
                       <td>
                         <table align="center">
                           <tr>
                  <!--start loop-->
                 <TMPL_LOOP NAME=SHIP_LOOP>

<label for="ship<TMPL_VAR 
NAME=S_METHOD_ID>"> 

<TD width=15 align="right"><input type=radio id="ship<TMPL_VAR 
NAME=S_METHOD_ID>" name="ship_option" value="<TMPL_VAR NAME=S_METHOD_ID>" 
<TMPL_VAR NAME=DEFAULT>></TD>
<TD width=65 class="boxfields" align="center" valign="top">
<img src="<TMPL_VAR NAME=URL_BASE>images/shipping/<TMPL_VAR NAME=S_ICON>" 
alt="<TMPL_VAR NAME=S_COURIER> <TMPL_VAR NAME=S_METHOD>"><br><b>$<TMPL_VAR 
NAME=S_COST></b></TD>
</label>
                       </TMPL_LOOP>
                           <!--end 
loop-->
                     </tr>
                   </table>
                 </td>
               </tr> 

                         <tr> 

                                 <td><IMG SRC="<TMPL_VAR 
NAME=URL_BASE>images/spacer.gif" WIDTH=10 HEIGHT=5></TD>
                               </tr> 

                       </table> 

                       <!--end of pieces 
table-->
               </td> 

               </tr> 

                 </table> 

                 <!--end of second color 
table-->
                 </TD> 

           </TR> 

         </table> 

   <!--end of Shipping type Section-->




>Hi,
>
>I think I understand what you are saying, but that was part of the 
>confusion. The URL_BASE is used before the loop in the top level 
>template.(Sorry I didn't show the entire thing) At least I think I 
>understood what you said, that there is a bug where if the first time a 
>var is referenced is in a loop it won't be replaced. If that is so, then 
>that bug can't be the reason I am sorry to say :)
>
>Thanks very much for the reply,
>
>Eric
>
>
>
>
>>
>>It sounds like you have hit the dreaded "top level param, not referenced 
>>before use in
>>template loop, so I"ll just do nothing" bug... try this somewhere before 
>>your first
>>TMPL_LOOP (say at the top of the file), in your first template:
>>
>>      <!-- H::T BUG: <TMPL_VAR URL_BASE> -->
>>
>>  which _should_ do absolutely nothing useful/harmful to the html 
>> output.  However, it will
>>result in H:T actually getting a reference to the URL_BASE variable.
>

[htmltmpl] Re: Avoiding resend warning when refreshing html page

[Joel L. <joe...@fo...>]

Well, turns out that you can include a META tag in your HTML page that 
will force a reloading of the form. After that you can refresh safely 
without problem. Here is an example:

[GENERAL]
META=%%if (param('entirebody') ne '') { '<META http-equiv="refresh" 
content="3; URL=bixchange.cgi?f=bxfm">'} %%
TITLE=BXFM
DEFAULTTEMPLATE=./tmpl/bxmgr.tmpl
PAGETYPE=FORM
...
In the template: 
<HTML>
<HEAD>

<TMPL_INCLUDE NAME="header1.tmpl">
<TMPL_VAR NAME="META">
</HEAD>
<BODY>
...

Just change the time above from three seconds to 1.

[htmltmpl] Templates with template loops within templates

[Eric F. <er...@dm...>]

Hi,

I think I understand what you are saying, but that was part of the 
confusion. The URL_BASE is used before the loop in the top level 
template.(Sorry I didn't show the entire thing) At least I think I 
understood what you said, that there is a bug where if the first time a var 
is referenced is in a loop it won't be replaced. If that is so, then that 
bug can't be the reason I am sorry to say :)

Thanks very much for the reply,

Eric




>It sounds like you have hit the dreaded "top level param, not referenced 
>before use in
>template loop, so I"ll just do nothing" bug... try this somewhere before 
>your first
>TMPL_LOOP (say at the top of the file), in your first template:
>
>      <!-- H::T BUG: <TMPL_VAR URL_BASE> -->
>
>  which _should_ do absolutely nothing useful/harmful to the html 
> output.  However, it will
>result in H:T actually getting a reference to the URL_BASE variable.

[htmltmpl] Andreas Jablonowski ist =?ISO-8859-1?Q?au=DFer_Haus=2E?=

[Andreas J. <And...@t-...>]

Ich werde ab  17.12.2004 nicht im B=FCro sein. Ich kehre zur=FCck am
10.01.2005.

Sehr geehrte Damen und Herren,

Aus diesem Grund werde Ihre Nachricht erst nach meiner R=FCckkehr beant=
worten
k=F6nnen. Ihre Nachricht wird nicht weitergeleitet.


Freundliche Gr=FC=DFe

Dipl.Ing. Andreas Jablonowski
T-Systems International GmbH
Leiter Web & Knowledge Management Solutions

Hausadresse: Roermonder Str. 615, 52072 Aachen
Postanschrift: Postfach 10 06 55, 52006 Aachen
Telefon: (0241) 93 79-499
Telefax: (0241) 93 79-619
E-Mail: And...@t-...
Internet: http://www.t-systems.de=

[htmltmpl] Avoiding resend warning when refreshing html page

[bradford <bra...@hi...>]

I have Googled and searched Perlmonks for ways of refreshing a page containing
a form that has just been submitted to my Perl script, and not getting the
"Resend" warning from the browser. 

Scenario: 1) Perl script and HTML::Template supplies a page with a blank form.
 2) User fills out and submits form.  3) Perl script parses form, saves data,
etc., and returns exact page with HTML::Template.  4) User tries to refresh
page and gets "Form data will be resent" error dialog.

It looks like I might have found a way to do this using a standard "location:
" redirect, but not one using HTML::Template
(http://www.perlmonks.org/?node_id=33033):

"A simple way of handling this is to issue an external redirect once the new
data has been successfully saved on POST. This will force the browser to GET
the page again, and it will be safe to use the 'Reload' button."

In all my reading, I've discovered this is a tricky one, even without using
H::T. Has anyone had any experience with this?

Thanks, Brad

Re: [htmltmpl] Templates with template loops within templates

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

Hi Eric,

It sounds like you have hit the dreaded "top level param, not referenced =
before use in template loop, so I'll just do nothing" bug... try this =
somewhere before your first TMPL_LOOP (say at the top of the file), in =
your first template:

    <!-- H::T BUG: <TMPL_VAR URL_BASE> -->

which _should_ do absolutely nothing useful/harmful to the html output.  =
However, it will result in H:T actually getting a reference to the =
URL_BASE variable.

What you were expecting to happen (ie template variable used in some =
child template, when being set at the top-level), is what most people =
expect to happen...  In my own templates, I have also hit this problem.


This bug is a result of how H::T handles TMPL_LOOP invocations... it =
basically does a recursive call of itself, passing the known params from =
the previous instance, into this new invocation.  Since the previous =
invocation hasn't referenced the TMPL_VAR, that value isn't passed into =
the TMPL_LOOP invocation.

Hope this helps,
Mathew


----- Original Message -----=20
From: "Eric Frazier" <er...@dm...>
To: <htm...@li...>
Sent: Friday, December 17, 2004 10:39 AM
Subject: [htmltmpl] Templates with template loops within templates


> Hi,
>=20
> Great subject line huh? :)
>=20
> Ok we have a template.
> Inside that template we load in from a database a template with its =
own=20
> vars which makes use of a template loop.
> In that second template we have a var called URL_BASE which is the =
base=20
> path. It works inside the second template, except for within the =
template=20
> loop output.
>=20
>=20
> So imagine we already have template object: $template (it by the way =
has a=20
> var called URL_BASE also that I thought would be passed down to this =
inside=20
> template as well)
>=20
> my $shipping_temp =3D=20
> $config->getShipping_temp($self->param('DEFAULT_PRODUCT')); ## returns =

> array ref
> my $ship_list_hash =3D $config->getShipping_list($instance,$dom_int);
>=20
> $template->param(SHIPPING =3D> '1'); ## part of the top level template
>=20
> my $shipref =3D \$shipping_temp->[0];
>=20
> my $ship_html =3D HTML::Template->new( scalarref =3D> $shipref,
>                                         die_on_bad_params =3D>0);
> my @loop_values =3D ();
> my $num_options =3D keys(%$ship_list_hash);
>=20
>          foreach my $key( keys(%$ship_list_hash) ){
>=20
>            my %inside_hash =3D ('S_ICON'      =3D>=20
> $ship_list_hash->{$key}{'courier_icon_url'},
>                 'S_COURIER'   =3D> =
$ship_list_hash->{$key}{'courier_name'},
>                  'S_METHOD'    =3D> =
$ship_list_hash->{$key}{'courier_method'} ,
>                  'S_METHOD_ID' =3D> =
$ship_list_hash->{$key}{'ship_method_id'},
>                  'S_COST'      =3D>=20
> $ship_list_hash->{$key}{'shipping_cost'}=20
>=20
>                     );
>=20
>            if ($shipping_temp->[1] eq=20
> $ship_list_hash->{$key}{'ship_method_id'}){
>                  $inside_hash{'DEFAULT'} =3D 'Checked';
>            }
>=20
>            if ($num_options < 2){
>                  $inside_hash{'DEFAULT'} =3D 'Checked';
>            }
>=20
>=20
>            push(@loop_values,\%inside_hash);
>=20
> }
>          $ship_html->param(URL_BASE      =3D> =
$self->param('URL_BASE'));   ##=20
> the problem var
>          $ship_html->param(SHIP_LOOP =3D> \@loop_values);
>=20
>=20
>          my $tmpout =3D $ship_html->output();
>=20
>=20
>=20
> Below is the raw HTML output produced, notice the spacer.gif has a =
full url=20
> where the ups_2D.gif which comes from the loop does not.
>=20
> I was a little confused to start off with because I thought the =
presence of=20
> the URL_BASE in the second template would be parsed as a result of =
being=20
> set in the original top level template. So not only does that not seem =
to=20
> be happening, but also when setting the var again in the second =
template it=20
> is not working inside the template loop. So my first question, is this =
the=20
> way HTML::Template should be working? I didn't expect this problem. =
The=20
> next question of course is how can I get this var to be parsed inside =
the=20
> loop?
>=20
> Using the current versions of both HTML::Template and CGI::Application
>=20
> Please let me know if this is enough info or too much, I wanted to =
give as=20
> much detail as I could because I found it hard to explain what I am =
doing=20
> with just words.
>=20
>=20
> Thanks,
>=20
> Eric
>=20
>=20
> <!--Start of Shipping type Section=20
> -->
>    <TABLE  WIDTH=3D700 class=3D"bord" BORDER=3D0 CELLPADDING=3D2 =
CELLSPACING=3D0=20
> align=3D"center">
>            <TR>=20
>=20
>                  <TD class=3D"bord" align=3D"center"><span=20
> class=3D"title">Shipping Method</span></TD>
>            </TR>=20
>=20
>            <TR>=20
>=20
>                  <TD>=20
>=20
>                          <!--second color=20
> table-->
>                          <TABLE  WIDTH=3D700 class=3D"main" BORDER=3D0 =

> CELLPADDING=3D10 CELLSPACING=3D0 align=3D"center">
>                                  <TR>=20
>=20
>                                    <TD class=3D"main"=20
> align=3D"center">
>                                    <!--pieces=20
> table-->
>                              <TABLE WIDTH=3D95% BORDER=3D0 =
CELLPADDING=3D0=20
> CELLSPACING=3D0 align=3D"center">
>                      <tr>=20
>=20
>                                    <td><IMG=20
> SRC=3D"https://www.host.com/htmltemp_consol/images/spacer.gif" =
WIDTH=3D10=20
> HEIGHT=3D5></TD>
>                                </tr>=20
>=20
>                      <tr>
>                        <td>
>                          <table align=3D"center">
>                            <tr>
>=20
>=20
>=20
>                  <label=20
> for=3D"ship4">=20
>=20
>                  <TD width=3D15 align=3D"right"><input type=3Dradio =
id=3D"ship4"=20
> name=3D"ship_option" value=3D"4" Checked></TD>
>                  <TD width=3D65 class=3D"boxfields" align=3D"center" =
valign=3D"top">
>                  <img src=3D"images/shipping/ups_2D.gif" alt=3D"LEM =
Domestic=20
> "><br><b>$10.00</b></TD>
>                  </label>
>=20
>                      </tr>
>                    </table>
>                  </td>
>                </tr>=20
>=20
>                          <tr>=20
>=20
>                                  <td><IMG=20
> SRC=3D"https://www.host.com/htmltemp_consol/images/spacer.gif" =
WIDTH=3D10=20
> HEIGHT=3D5></TD>
>                                </tr>=20
>=20
>                        </table>=20
>=20
>                        <!--end of pieces=20
> table-->
>                </td>=20
>=20
>                </tr>=20
>=20
>                  </table>=20
>=20
>                  <!--end of second color=20
> table-->
>                  </TD>=20
>=20
>            </TR>=20
>=20
>          </table>=20
>=20
>    <!--end of Shipping type Section-->
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real =
users.
> Discover which products truly live up to the hype. Start reading now.=20
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
> 

[htmltmpl] Templates with template loops within templates

[Eric F. <er...@dm...>]

Hi,

Great subject line huh? :)

Ok we have a template.
Inside that template we load in from a database a template with its own 
vars which makes use of a template loop.
In that second template we have a var called URL_BASE which is the base 
path. It works inside the second template, except for within the template 
loop output.


So imagine we already have template object: $template (it by the way has a 
var called URL_BASE also that I thought would be passed down to this inside 
template as well)

my $shipping_temp = 
$config->getShipping_temp($self->param('DEFAULT_PRODUCT')); ## returns 
array ref
my $ship_list_hash = $config->getShipping_list($instance,$dom_int);

$template->param(SHIPPING => '1'); ## part of the top level template

my $shipref = \$shipping_temp->[0];

my $ship_html = HTML::Template->new( scalarref => $shipref,
                                        die_on_bad_params =>0);
my @loop_values = ();
my $num_options = keys(%$ship_list_hash);

         foreach my $key( keys(%$ship_list_hash) ){

           my %inside_hash = ('S_ICON'      => 
$ship_list_hash->{$key}{'courier_icon_url'},
                'S_COURIER'   => $ship_list_hash->{$key}{'courier_name'},
                 'S_METHOD'    => $ship_list_hash->{$key}{'courier_method'} ,
                 'S_METHOD_ID' => $ship_list_hash->{$key}{'ship_method_id'},
                 'S_COST'      => 
$ship_list_hash->{$key}{'shipping_cost'} 

                    );

           if ($shipping_temp->[1] eq 
$ship_list_hash->{$key}{'ship_method_id'}){
                 $inside_hash{'DEFAULT'} = 'Checked';
           }

           if ($num_options < 2){
                 $inside_hash{'DEFAULT'} = 'Checked';
           }


           push(@loop_values,\%inside_hash);

}
         $ship_html->param(URL_BASE      => $self->param('URL_BASE'));   ## 
the problem var
         $ship_html->param(SHIP_LOOP => \@loop_values);


         my $tmpout = $ship_html->output();



Below is the raw HTML output produced, notice the spacer.gif has a full url 
where the ups_2D.gif which comes from the loop does not.

I was a little confused to start off with because I thought the presence of 
the URL_BASE in the second template would be parsed as a result of being 
set in the original top level template. So not only does that not seem to 
be happening, but also when setting the var again in the second template it 
is not working inside the template loop. So my first question, is this the 
way HTML::Template should be working? I didn't expect this problem. The 
next question of course is how can I get this var to be parsed inside the 
loop?

Using the current versions of both HTML::Template and CGI::Application

Please let me know if this is enough info or too much, I wanted to give as 
much detail as I could because I found it hard to explain what I am doing 
with just words.


Thanks,

Eric


<!--Start of Shipping type Section 
-->
   <TABLE  WIDTH=700 class="bord" BORDER=0 CELLPADDING=2 CELLSPACING=0 
align="center">
           <TR> 

                 <TD class="bord" align="center"><span 
class="title">Shipping Method</span></TD>
           </TR> 

           <TR> 

                 <TD> 

                         <!--second color 
table-->
                         <TABLE  WIDTH=700 class="main" BORDER=0 
CELLPADDING=10 CELLSPACING=0 align="center">
                                 <TR> 

                                   <TD class="main" 
align="center">
                                   <!--pieces 
table-->
                             <TABLE WIDTH=95% BORDER=0 CELLPADDING=0 
CELLSPACING=0 align="center">
                     <tr> 

                                   <td><IMG 
SRC="https://www.host.com/htmltemp_consol/images/spacer.gif" WIDTH=10 
HEIGHT=5></TD>
                               </tr> 

                     <tr>
                       <td>
                         <table align="center">
                           <tr>



                 <label 
for="ship4"> 

                 <TD width=15 align="right"><input type=radio id="ship4" 
name="ship_option" value="4" Checked></TD>
                 <TD width=65 class="boxfields" align="center" valign="top">
                 <img src="images/shipping/ups_2D.gif" alt="LEM Domestic 
"><br><b>$10.00</b></TD>
                 </label>

                     </tr>
                   </table>
                 </td>
               </tr> 

                         <tr> 

                                 <td><IMG 
SRC="https://www.host.com/htmltemp_consol/images/spacer.gif" WIDTH=10 
HEIGHT=5></TD>
                               </tr> 

                       </table> 

                       <!--end of pieces 
table-->
               </td> 

               </tr> 

                 </table> 

                 <!--end of second color 
table-->
                 </TD> 

           </TR> 

         </table> 

   <!--end of Shipping type Section-->

[htmltmpl] Re: [cgiapp] 2 New(?) Ideas

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

On Fri, 3 Dec 2004, Jason Purdy wrote:

> 1) Class::DBI Integration
> I'm just starting to pick up CDBI (I know, I'm late to the party ;)) and it's
> kind of frustrating to get the data into the template.  Or it could be made
> easier.  I'm not sure if we're talking Plugin or an update to the core, but
> what would be really cool is to accept CDBI objects in the 'associate'
> parameter:
> 
> $user_record = CDBI::Subclass->retrieve( $primary_key );
> $template = $self->load_tmpl(
>     'main.TMPL',
>     'die_on_bad_params' => 0,
>     'associate'         => [ $query, $user_record ],
>   );

The associate feature is a pretty brutal hack as it is.  I think you'd
be better off creating a sub-class of HTML::Template which supported a
new option like 'class_dbi' for this functionality.  You could then
call param() using some pre-defined translation between Class::DBI
space and HTML::Template space.

> Another cool tweak would be to HTML::Template such that you could do a search
> on the CDBI object and just pass along the results:
> 
> @results = CDBI::Subclass->search(
>     'year' => '1980'
>   );
> $template->param( 'results' => \@results );

That should also be reasonably easy to do in a sub-class.

> 2) Status Messages
> In an app flow like A -> B -> A, I would like to have a status message on A
> when B has been successfully processed, but what's the best way to do this?
> Stuff the message in cgiapp's param?  Pass along a param to the runmode
> method?  Then pass that to the template as a param?

I wrote a message about this on the CGI-App mailing-list a while
back.  Let's see if I can find it.  Here it is:

  http://www.mail-archive.com/cg...@li.../msg01987.html

I'm still planning to write that article...

-sam

Re: [htmltmpl] 2 New(?) Ideas

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

On Fri, Dec 03, 2004 at 03:52:17PM -0500, Jason Purdy wrote:
> While I'm thinking about this, what do you guys think about these?
> 
> 1) Class::DBI Integration
> I'm just starting to pick up CDBI (I know, I'm late to the party ;)) and 
> it's kind of frustrating to get the data into the template.  Or it could 
> be made easier.  I'm not sure if we're talking Plugin or an update to 
> the core, but what would be really cool is to accept CDBI objects in the 
> 'associate' parameter:

  This can/should happen in your code - simply create a CDBI-derived
CDBI::Extended object which has a CGI/HT compatible "params" method,
and pass that to associate.  Hey presto!

  If you're wanting to create a bunch of CDBI subclasses, then you just
subclass that CDBIE instead.  Done.  If you think this would be really
useful to a lot of people then encapsulate the CDBIE neatly and publish
it in CPAN.

  (Alternatively, you could subclass HT, but since HT already has a
well-defined interface for feeding params in, which already
interoperates with some Perl modules, it seems more logical to add it
on the other side.)

  -- 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] 2 New(?) Ideas

[David H. <da...@ho...>]

On 3 Dec 2004, at 21:16, Jason Purdy wrote:

> I'm not sure if you're just trolling me here w/ that simple response, 
> but I did talk about how I didn't want to use TT.  I don't believe 
> adding support for CDBI would be overloading it, just making it easier 
> to use.  If you're still skeptical, it could be done as an extension 
> or plugin such that it doesn't add any "bloat" to the core.

HTML::Template's strength is its simplicity. It does a couple of things 
perfectly
and leaves the rest to "real" code. The separation of almost everything 
except
display is strong. Build the data structure and let H::T do the rest.

The project I'm working on right now has HTML::Template, Text::Template 
*and*
TT, each used for specific purposes.



>
> Jason
>
> David Hodgkinson wrote:
>> On 3 Dec 2004, at 20:52, Jason Purdy wrote:
>>> While I'm thinking about this, what do you guys think about these?
>> Use the Template Toolkit.
>> HTML::Template does what it does very well. Don't overload it.
>
>


-- 
Dave Hodgkinson
CTO, Rockit Factory Ltd.
http://www.rockitfactory.com/
Web sites for rock bands

Re: [htmltmpl] 2 New(?) Ideas

[David H. <da...@ho...>]

On 3 Dec 2004, at 20:52, Jason Purdy wrote:

> While I'm thinking about this, what do you guys think about these?

Use the Template Toolkit.

HTML::Template does what it does very well. Don't overload it.


-- 
Dave Hodgkinson
CTO, Rockit Factory Ltd.
http://www.rockitfactory.com/
Web sites for rock bands

[htmltmpl] 2 New(?) Ideas

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

While I'm thinking about this, what do you guys think about these?

1) Class::DBI Integration
I'm just starting to pick up CDBI (I know, I'm late to the party ;)) and 
it's kind of frustrating to get the data into the template.  Or it could 
be made easier.  I'm not sure if we're talking Plugin or an update to 
the core, but what would be really cool is to accept CDBI objects in the 
'associate' parameter:

$user_record = CDBI::Subclass->retrieve( $primary_key );
$template = $self->load_tmpl(
     'main.TMPL',
     'die_on_bad_params' => 0,
     'associate'         => [ $query, $user_record ],
   );

Another cool tweak would be to HTML::Template such that you could do a 
search on the CDBI object and just pass along the results:

@results = CDBI::Subclass->search(
     'year' => '1980'
   );
$template->param( 'results' => \@results );

It could be an easy tweak to the code, where if when trying to fill out 
a <TMPL_VAR NAME="foo"> from the template's internal param hash or from 
the associated objects' param methods fail, it will try a last-ditch 
effort of going through associated objects' methods named after the same 
parameter name (i.e. foo()).

These thoughts aren't that well-organized, so I hope you get the jist of 
what I'm aiming for.  I'm mostly hoping to instigate some thoughts on 
how we can get CDBI better supported in cgiapp & htmltmpl.  I know we 
could add a param() method to the CDBI subclass, but that seems kind of 
a pain to me.

I just dug around the htmltmpl list and found this post[1] that's very 
similiar to what I'm trying to address.  Cees (& another poster) says 
that he adds something to his CDBI subclass, but again, we could do 
better by centralizing that same code in the htmltmpl core or a plugin, 
so we don't have to copy/paste that code in every CDBI subclass we have 
(and just for one app, I have about 6).  Cees also points to Template, 
but I don't see why we can't also have it in htmltmpl.  I'm kinda stuck 
on htmltmpl, personally -- it's very simple and it keeps me from 
bleeding logic into the template layer of my applications.

2) Status Messages
In an app flow like A -> B -> A, I would like to have a status message 
on A when B has been successfully processed, but what's the best way to 
do this?  Stuff the message in cgiapp's param?  Pass along a param to 
the runmode method?  Then pass that to the template as a param?

Cheers,

Jason

[1]: http://sourceforge.net/mailarchive/message.php?msg_id=8629899