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

Re: [htmltmpl] Getting data from template?

[Roger B. W. <ro...@fi...>]

On Thu, Jan 29, 2009 at 03:21:59AM +0000, Lyle wrote:

>But that doesn't work. Is there a way to pickup data from a template 
>you've read in?

This is quite a common question, and the answer is "yes". My own
HTML::Template::Set extension is one approach. See the list archives.

Roger

Re: [htmltmpl] Getting data from template?

[Wood, B. <Bra...@Le...>]

I would advise you to check out the following write up on using html::template.

http://www.perlmonks.org/?node_id=65642

You need to set all of your param and then::
print $template->output;
Level 3 Communications
Brandon Wood
(Via Blackberry)

----- Original Message -----
From: Lyle <web...@co...>
To: htm...@li... <htm...@li...>
Sent: Wed Jan 28 20:21:59 2009
Subject: [htmltmpl] Getting data from template?

Hi All,
  I'm trying to find a way to get data into my script from my template.
I've tried:-
<tmpl_var name=test default="HELLO!">
And then after loading the template in my code:-
print $template->param( 'test' );

But that doesn't work. Is there a way to pickup data from a template
you've read in?


Lyle


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Html-template-users mailing list
Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users

[htmltmpl] Getting data from template?

[Lyle <web...@co...>]

Hi All,
  I'm trying to find a way to get data into my script from my template.
I've tried:-
<tmpl_var name=test default="HELLO!">
And then after loading the template in my code:-
print $template->param( 'test' );

But that doesn't work. Is there a way to pickup data from a template 
you've read in?


Lyle

Re: [htmltmpl] Making a Copy of a template object

[Michael P. <mp...@pl...>]

cfaust-dougot wrote:

> I'm really trying to split the current template object into 2 different 
> objects after I've assigned a bunch of things to it (one ends up being 
> for display and the other gets emailed),

Why don't you just create 2 template variables that use the same underlying template. Then you can 
use the same process that you're using to fill in one to fill in the other.

-- 
Michael Peters
Plus Three, LP

Re: [htmltmpl] Making a Copy of a template object

[cfaust-dougot <cf...@do...>]

Thanks Sébastien, Damien and Michael.
 
I'm really trying to split the current template object into 2 different objects after I've assigned a bunch of things to it (one ends up being for display and the other gets emailed), so I guess I should check out that storable module as if I just invoked the "new" method again I would have to reassign everything again to the new object, right?
 
Thanks!
-Chris

________________________________

From: Damien Clark [mailto:d....@cq...]
Sent: Thu 12/18/2008 6:15 PM
To: cfaust-dougot; htm...@li...
Subject: Re: [htmltmpl] Making a Copy of a template object


Hi Chris,

Where you have the statement:

$template2 = $template ;

Essentially what you are doing here is creating a variable $template2 that points to the same object as referenced by $template.  An object in perl is a blessed reference and so you have just made a copy of a reference.  So $template2 and $template point to the same object.  

If you wish to make a true copy of the object, you will need to look at things like Data::Dumper or better still the Storage module which has freeze and thaw subroutines.  Hopefully this will achieve what you want.

All the best.

Regards,
Damien.


On 19/12/08 7:32 AM, "cfaust-dougot" <cf...@do...> wrote:



	Folks,
	
	I'm trying to create 2 different vars from the same template object and it appears once I do so that whatever I set in one gets set in the other. What am I missing? Is it because I'm creating a reference? (I didn't think that was the case).
	
	Here is an example of what I mean
	
	my $template_object = qq|<TMPL_IF NAME="Var1"> Var 1 is set</TMPL_IF><TMPL_IF NAME="Var2"> Var 2 is set</TMPL_IF>|;
	
	my $template = HTML::Template->new(scalarref    => \$template_object);
	 
	$template->param(Var1   =>      1);
	
	my $template2 = $template;
	
	$template2->param(Var2  =>      1);
	 
	print $template->output();
	 
	The output I get is: "Var 1 is set Var 2 is set" even though I set "Var2" only in $template2 only
	 
	 
	TIA!
	-Chris
	
	
________________________________

	------------------------------------------------------------------------------
	SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
	The future of the web can't happen without you.  Join us at MIX09 to help
	pave the way to the Next Web now. Learn more and register at
	http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
	
________________________________

	_______________________________________________
	Html-template-users mailing list
	Htm...@li...
	https://lists.sourceforge.net/lists/listinfo/html-template-users
	

Re: [htmltmpl] Making a Copy of a template object

[Sébastien Aperghis-T. <mad...@fr...>]

cfaust-dougot wrote:

> I'm trying to create 2 different vars from the same template object  
> and it appears once I do so that whatever I set in one gets set in  
> the other. What am I missing? Is it because I'm creating a  
> reference? (I didn't think that was the case).


This is the case: you're just copying the reference, so both  
variables points at the same object.
Simply create a new object with new(), or, if you really want to  
clone the object, use Storable::dclone() or the Clone module.

   » http://perldoc.perl.org/Storable.html
   » http://search.cpan.org/dist/Clone/Clone.pm


-- 
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: [htmltmpl] Making a Copy of a template object

[Michael P. <mp...@pl...>]

Damien Clark wrote:

> If you wish to make a true copy of the object, you will need to look at 
> things like Data::Dumper or better still the Storage module which has 
> freeze and thaw subroutines.  Hopefully this will achieve what you want.

I think you mean Storable. If you need to have your object persist or be "stored" (clever name huh) 
somewhere then Storable is what you want. If you just want to clone the object, then use the Clone 
module.

-- 
Michael Peters
Plus Three, LP

Re: [htmltmpl] Making a Copy of a template object

[Damien C. <d....@cq...>]

Hi Chris,

Where you have the statement:

$template2 = $template ;

Essentially what you are doing here is creating a variable $template2 that
points to the same object as referenced by $template.  An object in perl is
a blessed reference and so you have just made a copy of a reference.  So
$template2 and $template point to the same object.

If you wish to make a true copy of the object, you will need to look at
things like Data::Dumper or better still the Storage module which has freeze
and thaw subroutines.  Hopefully this will achieve what you want.

All the best.

Regards,
Damien.


On 19/12/08 7:32 AM, "cfaust-dougot" <cf...@do...> wrote:

> Folks,
>  
> I'm trying to create 2 different vars from the same template object and it
> appears once I do so that whatever I set in one gets set in the other. What am
> I missing? Is it because I'm creating a reference? (I didn't think that was
> the case).
>  
> Here is an example of what I mean
>  
> my $template_object = qq|<TMPL_IF NAME="Var1"> Var 1 is set</TMPL_IF><TMPL_IF
> NAME="Var2"> Var 2 is set</TMPL_IF>|;
> 
> my $template = HTML::Template->new(scalarref    => \$template_object);
>  
> $template->param(Var1   =>      1);
> 
> my $template2 = $template;
> 
> $template2->param(Var2  =>      1);
>  
> print $template->output();
>  
> The output I get is: "Var 1 is set Var 2 is set" even though I set "Var2" only
> in $template2 only
>  
>  
> TIA!
> -Chris
> 
> 
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> 
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

[htmltmpl] Making a Copy of a template object

[cfaust-dougot <cf...@do...>]

Folks,
 
I'm trying to create 2 different vars from the same template object and it appears once I do so that whatever I set in one gets set in the other. What am I missing? Is it because I'm creating a reference? (I didn't think that was the case).
 
Here is an example of what I mean
 
my $template_object = qq|<TMPL_IF NAME="Var1"> Var 1 is set</TMPL_IF><TMPL_IF NAME="Var2"> Var 2 is set</TMPL_IF>|;

my $template = HTML::Template->new(scalarref    => \$template_object);
 
$template->param(Var1   =>      1);

my $template2 = $template;

$template2->param(Var2  =>      1);
 
print $template->output();
 
The output I get is: "Var 1 is set Var 2 is set" even though I set "Var2" only in $template2 only
 
 
TIA!
-Chris

Re: [htmltmpl] PATCH: adding auto-detection for file types

[David K. <da...@gi...>]

Hi Mark,

"Mark Stosberg" <ma...@su...> wrote...
>
> HTML::Template currently supports 4 formats
> for the input file, with three different APIs
> to specify it [...] I find these more verbose
> and confusing than it needs to be. [...]
> Before proceeding further, I wanted to get
> some feedback about heading in this direction.

+1 to this idea!

I think this would be a very nice improvement.  I always have to consult 
the docs to use anything but a filename, too.  Please finish the patch!  As 
long as it is maintains compatibility with existing code, includes docs and 
tests, I bet Sam would include it in the next release.

-dave

Re: [htmltmpl] PATCH: adding auto-detection for file types

[Brad B. <bm...@ma...>]

I have a couple of comments below...

On Sun, Nov 30, 2008 at 7:02 PM, Mark Stosberg <ma...@su...> wrote:

>
> HTML::Template currently supports 4 formats for the input file, with three
> different APIs
> to specify it:
>
>  First:
>   new( filename   => $f, ... );
>   new( scalarref  => $f, ... );
>   new( arrayref   => $f, ... );
>   new( filehandle => $f, ... );
>
>  Second:
>   new_file($f, ... );
>   new_scalar_ref($f, ... );
>   new_array_ref($f, ... );
>   new_filehandle($f, ... );
>
>  Third:
>   new(type => 'filename'  , source => $f, ...);
>   new(type => 'scalarref' , source => $f, ...);
>   new(type => 'arrayref'  , source => $f, ...);
>   new(type => 'filehandle', source => $f, ...);
>
> ###
>
> I find these more verbose and confusing than it needs to be. Beecause the
> second option provides alternate spellings for 3 out of 4 options, it's
> hard to
> ever get the spelling right without consulting the docs.
>

First, I'd like to see alternatives for the unfortunately misspelled :-)
methods:

new_filename()
new_scalarref()
new_arrayref()

Since those are practically one-liners anyway, a few additions ought not be
a big deal.



>
> I would like to contribute a patch that cleans all this up to this:
>
>  new(source => $filehandle);
>  new(source => $filename);
>  new(source => $scalarref);
>  new(source => $arrayref);
>
> Since we can detect the difference between a string, a scalarref, an
> arrayref
> and a filehandle, we don't need to user to repeat this information for us.
> It
> can "just work". The auto-detection logic would come into play if "source"
> is
> specified, but 'type' is not.
>
> HTML::FillInForm had a similar interface and is a precendent for this kind
> of API overhaul.
> You can see their old API:
>
>
> http://search.cpan.org/~tjmather/HTML-FillInForm-2.00/lib/HTML/FillInForm.pm#Old_syntax<http://search.cpan.org/%7Etjmather/HTML-FillInForm-2.00/lib/HTML/FillInForm.pm#Old_syntax>
>
> And the new API:
>
>
> http://search.cpan.org/~tjmather/HTML-FillInForm-2.00/lib/HTML/FillInForm.pm#SYNOPSIS<http://search.cpan.org/%7Etjmather/HTML-FillInForm-2.00/lib/HTML/FillInForm.pm#SYNOPSIS>
>
> The attach patch includes working code and tests which head in this
> direction,
> but it is not complete. (The current patch auto-detects the first arg,
> instead of
> the value for 'source').
>
> The final patch would update the docs to highlight the simpler new syntax
> and
> de-emphasize the other interfaces (The same approach used by
> HTML::FillInForm).
> This would simplify things for new users, while users migrating from older
> versions would still find the reference docs for the older APIs.
>
> Before proceeding further, I wanted to get some feedback about heading in
> this
> direction.
>

I think this is an okay idea.  But I'm leery of the technique of shoehorning
alternative syntax over existing syntax the way your patch seems to imply.

Instead, I would look at this spot in the code:

  # handle the "type", "source" parameter format (does anyone use it?)
  if (exists($options->{type})) {
    exists($options->{source}) or croak("HTML::Template->new() called
with 'type' parameter set, but no 'source'!");
    ($options->{type} eq 'filename' or $options->{type} eq 'scalarref' or
     $options->{type} eq 'arrayref' or $options->{type} eq 'filehandle') or
       croak("HTML::Template->new() : type parameter must be set to
'filename', 'arrayref', 'scalarref' or 'filehandle'!");

    $options->{$options->{type}} = $options->{source};
    delete $options->{type};
    delete $options->{source};
  }

It looks like this is the only place that needs to change.

Finally, at least one other package, HTML::Template::Compiled, may
also benefit from these API changes.

Regards,

Brad

[htmltmpl] PATCH: adding auto-detection for file types

[Mark S. <ma...@su...>]

HTML::Template currently supports 4 formats for the input file, with three different APIs 
to specify it:

 First: 
   new( filename   => $f, ... );
   new( scalarref  => $f, ... );
   new( arrayref   => $f, ... );
   new( filehandle => $f, ... );
 
 Second:
   new_file($f, ... );
   new_scalar_ref($f, ... );
   new_array_ref($f, ... );
   new_filehandle($f, ... ); 
 
 Third: 
   new(type => 'filename'  , source => $f, ...);
   new(type => 'scalarref' , source => $f, ...);
   new(type => 'arrayref'  , source => $f, ...);
   new(type => 'filehandle', source => $f, ...);

###

I find these more verbose and confusing than it needs to be. Beecause the
second option provides alternate spellings for 3 out of 4 options, it's hard to
ever get the spelling right without consulting the docs.

I would like to contribute a patch that cleans all this up to this:

  new(source => $filehandle);
  new(source => $filename);
  new(source => $scalarref);
  new(source => $arrayref);

Since we can detect the difference between a string, a scalarref, an arrayref
and a filehandle, we don't need to user to repeat this information for us. It
can "just work". The auto-detection logic would come into play if "source" is
specified, but 'type' is not.

HTML::FillInForm had a similar interface and is a precendent for this kind of API overhaul. 
You can see their old API:

http://search.cpan.org/~tjmather/HTML-FillInForm-2.00/lib/HTML/FillInForm.pm#Old_syntax

And the new API:

http://search.cpan.org/~tjmather/HTML-FillInForm-2.00/lib/HTML/FillInForm.pm#SYNOPSIS

The attach patch includes working code and tests which head in this direction,
but it is not complete. (The current patch auto-detects the first arg, instead of 
the value for 'source').

The final patch would update the docs to highlight the simpler new syntax and
de-emphasize the other interfaces (The same approach used by HTML::FillInForm).
This would simplify things for new users, while users migrating from older
versions would still find the reference docs for the older APIs.

Before proceeding further, I wanted to get some feedback about heading in this
direction.

    Mark

-- 
http://mark.stosberg.com/blog/

Re: [htmltmpl] Leaving tmp_var intact inside template

[Roger B. W. <ro...@fi...>]

On Tue, Jul 29, 2008 at 09:01:45AM -0400, Brad Baxter wrote:

>Using !TMPL_VAR would allow for "3-pass" or "n-pass" templating.  That
>is, change !TMPL_VAR to TMPL_VAR on each pass.  If you then have
>!!TMPL_VAR, it survives to the third pass.
>
>I actually do this (albeit with a different templating system), though I can
>recall only a couple of times I ever needed !!.

I'm using something similar at work - though my syntax is "2MPL_VAR"
(which is similarly extensible, though I haven't needed a 3-pass system
yet). The entire static page tree of the site is run through an H::T
pass before upload to generate navigation data (headers, footers, etc.),
so any actual template-based content needs special treatment.

Roger

Re: [htmltmpl] Leaving tmp_var intact inside template

[Brad B. <bm...@ma...>]

On Mon, Jul 28, 2008 at 5:29 PM, city crew <cit...@ho...> wrote:

>
> I like that, I was experimenting with !TMPL_VAR but yours seems more
> semantically appealing. (I'm practicing my impressive technical speak
> there...)
>

Using !TMPL_VAR would allow for "3-pass" or "n-pass" templating.  That
is, change !TMPL_VAR to TMPL_VAR on each pass.  If you then have
!!TMPL_VAR, it survives to the third pass.

I actually do this (albeit with a different templating system), though I can
recall only a couple of times I ever needed !!.

Brad

Re: [htmltmpl] Leaving tmp_var intact inside template

[Vijay R. <vij...@po...>]

I've done a similar thing, albeit in a very different circumstance (having "templates" within templates, that get sent with an ajax-form and populated by a response from CGI::Ajax, sent back to the dom, and stuck in wherever they are supposed to go). In this case, I need to keep the <TMPL_VAR WHATEVER> information in that format, so when the template-chunk gets sent back to perl, it can be seen as such, filled in as necessary, and returned as a populated template.  To accomplish this, I rewrite any and all tmpl_vars within a certain div id, something like $div_html = s/<(\/?)TMPL_(.*?)\s*(.*?)> /__$1TMPL_$2 $3__/ig  (turning < and > into __ ) and then rewrite this upon receiving the template-chunk, before parsing it.

It works well enough, although it is a bit nasty introducing randomly-chosen syntax...

On 7/28/08 5:29 PM, "city crew" <cit...@ho...> wrote:

> Date: Mon, 28 Jul 2008 17:13:58 -0400
> Subject: Re: [htmltmpl] Leaving tmp_var intact inside template
>
> city crew wrote:
>
> > 2. store template output into a scalar and to a regexp subst on the
> > scalar before printint that to the file.
> >
> > my $templateRef = $template->output;
> > $templateRef =~ s/&lt;TMPL_/<TMPL_/g;
> > print TEMP $templateRef;
> >
> > As I am writing this I think I'm going to go with solution 2 as it
> > outputs the file and doesn't require any filter on loading the second
> > template.
>
> We do something similar to your #2. We use a slightly more obvious
> syntax though. We use <TMPL_VAR> for things that are being loaded on the
> first pass and <DYN_VAR> for things on the 2nd pass.

I like that, I was experimenting with !TMPL_VAR but yours seems more semantically appealing. (I'm practicing my impressive technical speak there...)

>
> Just FYI, I've heard this technique named a couple of different things,
> in case you want to impress anyone :) It's usually called "2 pass
> templating" or "Write-thru cache templating".

Nice! I'll try impress my wife with "Write-thru cache templating", maybe I'll get lucky. =o)

Grant

>
> --
> Michael Peters
> Plus Three, LP
>


________________________________
Click here. Want to help Windows Live Messenger plant more Aussie trees? <http://livelife.ninemsn.com.au/article.aspx?id=443698>

Re: [htmltmpl] Leaving tmp_var intact inside template

[city c. <cit...@ho...>]

> Date: Mon, 28 Jul 2008 17:13:58 -0400> Subject: Re: [htmltmpl] Leaving tmp_var intact inside template> > city crew wrote:> > > 2. store template output into a scalar and to a regexp subst on the > > scalar before printint that to the file.> > > > my $templateRef = $template->output;> > $templateRef =~ s/&lt;TMPL_/<TMPL_/g;> > print TEMP $templateRef;> > > > As I am writing this I think I'm going to go with solution 2 as it > > outputs the file and doesn't require any filter on loading the second > > template.> > We do something similar to your #2. We use a slightly more obvious > syntax though. We use <TMPL_VAR> for things that are being loaded on the > first pass and <DYN_VAR> for things on the 2nd pass.
I like that, I was experimenting with !TMPL_VAR but yours seems more semantically appealing. (I'm practicing my impressive technical speak there...)
 
> > Just FYI, I've heard this technique named a couple of different things, > in case you want to impress anyone :) It's usually called "2 pass > templating" or "Write-thru cache templating".
 
Nice! I'll try impress my wife with "Write-thru cache templating", maybe I'll get lucky. =o)
 
Grant
> > -- > Michael Peters> Plus Three, LP> 
_________________________________________________________________
Want to help Windows Live Messenger plant more Aussie trees?
http://livelife.ninemsn.com.au/article.aspx?id=443698

Re: [htmltmpl] Leaving tmp_var intact inside template

[Michael P. <mp...@pl...>]

city crew wrote:

> 2. store template output into a scalar and to a regexp subst on the 
> scalar before printint that to the file.
>  
> my $templateRef = $template->output;
> $templateRef =~ s/&lt;TMPL_/<TMPL_/g;
> print TEMP $templateRef;
>  
> As I am writing this I think I'm going to go with solution 2 as it 
> outputs the file and doesn't require any filter on loading the second 
> template.

We do something similar to your #2. We use a slightly more obvious 
syntax though. We use <TMPL_VAR> for things that are being loaded on the 
first pass and <DYN_VAR> for things on the 2nd pass.

Just FYI, I've heard this technique named a couple of different things, 
in case you want to impress anyone :) It's usually called "2 pass 
templating" or "Write-thru cache templating".

-- 
Michael Peters
Plus Three, LP

[htmltmpl] Leaving tmp_var intact inside template

[city c. <cit...@ho...>]

 
I am creating a HTML template that I want populate only some of the variables (TMPL_VARs) in it, then output it to a file that I will call again at a later date to populate the rest of the variables. So basically I want to escape some of the TMPL variables so they can be populated on the second pass.
 
eg.
 
<DIV>
<TMPL_VAR NAME="title_pass1">
<TMPL_VAR NAME="content_pass2">
<TMPL_VAR NAME="footer_pass1">
</DIV>
 
The only solutions i can think of is to set the second pass of vars to &lt;TMPL_VAR NAME=test> and either:
 
1. output the first pass to a file, then call the new template with the filter param which converts all /&lt;TMPL/<TMPL/g. I don't like this way as it has to run a regexp subst on each template as it's loaded, and the second pass is the one that is used more often, the first pass is just to create the structure for the second pass.
 
2. store template output into a scalar and to a regexp subst on the scalar before printint that to the file.
 
my $templateRef = $template->output;
$templateRef =~ s/&lt;TMPL_/<TMPL_/g;
print TEMP $templateRef;
 
As I am writing this I think I'm going to go with solution 2 as it outputs the file and doesn't require any filter on loading the second template. 
 
Any feedback on this would be great though, otherwise maybe this might help someone else who is looking for a similar solution.
 
Grant
_________________________________________________________________
Windows Live Messenger treats you to 30 free emoticons - Bees, cows, tigers and more!
http://livelife.ninemsn.com.au/article.aspx?id=567534

Re: [htmltmpl] No filter on includes?

[Vijay R. <vij...@po...>]

So, I found a different way to solve this problem, by making the append JSON-dump not a filter, but rather an additional process step after getting the HTML::Template output, before sending it back to the mod_perl script (we have a Web-App layer in-between the two).  Since I'm able to access $template->{options}->{some_created_option} I was able to use that to store the JSON-dump and access it after doing $template->output (calling HTML::Template output).

If anybody else still sees the need for having a "no_filter_includes" (for example, when including external templates?) the code below should still allow for this, but I officially withdraw my request!



On 7/26/08 12:56 PM, "Vijay Ramesh" <vij...@po...> wrote:

I've been running into an issue with a Web-App system the company I work for has built around HTML::Template.  Basically, to summarize the problem, I am creating a JSON-dump of everything in the handler (e.g., all tmpl_*, including a bunch of environmental, config, and session stuff that we set automatically) and - given a parameter on this our-Web-App=>HTML::Template=>parse call, want to append this JSON-dump as a div at the bottom of the template. It is then loaded by a javascript object that uses it to generate ajax-calls among other things. Anyhow, the problem isn't with this, per se, but with the way that HTML::Template automatically applies filters to all tmpl_includes.  I can get around this by some nasty regexps before sending the output of the parsed template, making sure only one JSON-dump div is present, but that really breaks the whole programming/design paradigm (that I like very much).  Now, there might be a better way to append this generated JSON-dump as a TMPL_VAR to the end of the parsed template than using a filter (as using a filter comes pretty close to adding design - e.g., appending a qq/<div id="js_thandler"><TMPL_VAR ESCAPE=HTML JS_THANDLER><\/div>/ to the template as a filter) but this current method works well, making it so the individual mod_perl script does not have to do anything except set a parameter in the custom parse call indicating this JSON-dump should be created and appended to the output.  I really don't want to lose this automation - and so am resigned to having the slightest bit of HTML + TMPL_VAR in an App-level filter. But, so long as filters automatically run for all tmpl_includes as well, I'm ending up with as many of these divs as there are tmpl_includes, plus one for the main template.  Now, I certainly understand why - as they are normally used - filters run for all tmpl_includes. What I was wondering was would it be terrible to add a "no_filter_includes" parameter to the HTML::Template parse call, and then having something like

$self->_call_filters(\$included_template) if @{$options->{filter}} && $options{no_filter_includes} != 1

At line 2252 of HTML::Template 2.8?

That would be the only change required - and it wouldn't effect anything if the option isn't set (i.e., it wouldn't mess up existing uses of HTML::Template).  I'm not sure if anybody else has ever had cause for a similar option, or if my use of filters is just too far off the HTML::Template paradigm to warrant this change, but it would save me from having some nasty regexp parsing after getting the output....

I would gladly commit this change - or anybody who is actively working with the project, you'd just have to make the change detailed above - if anybody else sees this as a potentially beneficial  option to have? Or if anybody has suggestions for a different way to append a qq/<div id="js_thandler"><TMPL_VAR ESCAPE=HTML JS_THANDLER><\/div>/ line to the template before it gets parsed without using a filter, that'd be great as well.

Thanks for the input
/ Vijay K Ramesh

[htmltmpl] No filter on includes?

[Vijay R. <vij...@po...>]

I've been running into an issue with a Web-App system the company I work for has built around HTML::Template.  Basically, to summarize the problem, I am creating a JSON-dump of everything in the handler (e.g., all tmpl_*, including a bunch of environmental, config, and session stuff that we set automatically) and - given a parameter on this our-Web-App=>HTML::Template=>parse call, want to append this JSON-dump as a div at the bottom of the template. It is then loaded by a javascript object that uses it to generate ajax-calls among other things. Anyhow, the problem isn't with this, per se, but with the way that HTML::Template automatically applies filters to all tmpl_includes.  I can get around this by some nasty regexps before sending the output of the parsed template, making sure only one JSON-dump div is present, but that really breaks the whole programming/design paradigm (that I like very much).  Now, there might be a better way to append this generated JSON-dump as a TMPL_VAR to the end of the parsed template than using a filter (as using a filter comes pretty close to adding design - e.g., appending a qq/<div id="js_thandler"><TMPL_VAR ESCAPE=HTML JS_THANDLER><\/div>/ to the template as a filter) but this current method works well, making it so the individual mod_perl script does not have to do anything except set a parameter in the custom parse call indicating this JSON-dump should be created and appended to the output.  I really don't want to lose this automation - and so am resigned to having the slightest bit of HTML + TMPL_VAR in an App-level filter. But, so long as filters automatically run for all tmpl_includes as well, I'm ending up with as many of these divs as there are tmpl_includes, plus one for the main template.  Now, I certainly understand why - as they are normally used - filters run for all tmpl_includes. What I was wondering was would it be terrible to add a "no_filter_includes" parameter to the HTML::Template parse call, and then having something like

$self->_call_filters(\$included_template) if @{$options->{filter}} && $options{no_filter_includes} != 1

At line 2252 of HTML::Template 2.8?

That would be the only change required - and it wouldn't effect anything if the option isn't set (i.e., it wouldn't mess up existing uses of HTML::Template).  I'm not sure if anybody else has ever had cause for a similar option, or if my use of filters is just too far off the HTML::Template paradigm to warrant this change, but it would save me from having some nasty regexp parsing after getting the output....

I would gladly commit this change - or anybody who is actively working with the project, you'd just have to make the change detailed above - if anybody else sees this as a potentially beneficial  option to have? Or if anybody has suggestions for a different way to append a qq/<div id="js_thandler"><TMPL_VAR ESCAPE=HTML JS_THANDLER><\/div>/ line to the template before it gets parsed without using a filter, that'd be great as well.

Thanks for the input
/ Vijay K Ramesh

Re: [htmltmpl] htree - building static HTML pages from templates

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

Hi Jason,

I have had a look at it -> I have some comments which you should 
probably ignore, since I am not a guru, but here goes...

- I'm not sure I understand what it actually provides, that using 
caching wont already give you?

- where there are no '.txt' files in the directory, it generates a file 
"htree-help.html"

cheers,
Mathew Robertson




Jason A. Crome wrote:
> Hello,
>
> Been hacking on a little utility for a project I'm working on.  htree  
> takes a bunch of page fragments and embeds them in the HTML::Template  
> of your choice, allowing you to easily generate a number of static  
> pages in one fell swoop.  This is greatly easing the deployment and  
> updating of my project content.
>
> It's rough, I won't lie.  It can read into subdirectories, but it can  
> only write out to a single directory.  It's lacking any meaningful  
> tests (which to say, it's pretty well missing any).  It hasn't been  
> well checked for bugs.  But it has done what I've needed it to, so  
> far ;)
>
> You can get it here:  http://cromedome.net/downloads/HTML-Template-Htree-0.1.tar.gz
>
> I'll upload to CPAN in a few days based upon feedback, etc.
>
> Enjoy!  Patches and tests are very, very, very welcome!
> Jason
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>   

[htmltmpl] htree - building static HTML pages from templates

[Jason A. C. <cro...@gm...>]

Hello,

Been hacking on a little utility for a project I'm working on.  htree  
takes a bunch of page fragments and embeds them in the HTML::Template  
of your choice, allowing you to easily generate a number of static  
pages in one fell swoop.  This is greatly easing the deployment and  
updating of my project content.

It's rough, I won't lie.  It can read into subdirectories, but it can  
only write out to a single directory.  It's lacking any meaningful  
tests (which to say, it's pretty well missing any).  It hasn't been  
well checked for bugs.  But it has done what I've needed it to, so  
far ;)

You can get it here:  http://cromedome.net/downloads/HTML-Template-Htree-0.1.tar.gz

I'll upload to CPAN in a few days based upon feedback, etc.

Enjoy!  Patches and tests are very, very, very welcome!
Jason

Re: [htmltmpl] TMPL_INCLUDE doubt

[Mark F. <azf...@gm...>]

On Sun, Jul 13, 2008 at 5:37 PM, Mathew Robertson
<mat...@ne...> wrote:
> Hi Rajesh,
>
> I dont think anyone has answered this yet...

I replied to him. But, didn't notice it was only to him (not the
list). I pointed out how the filter function can be used at the time
the template is loaded. Also the possibility of preprocessing
templates if he's trying to be too dynamic.

Mark

Re: [htmltmpl] TMPL_INCLUDE doubt

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

Hi Rajesh,

I dont think anyone has answered this yet...  This question gets asked 
quite frequently - if you search through the archives, you will find 
numerous answers, most of which boil down to one of:

- use something like:

   <TMPL_IF FILENAME1><TMPL_INCLUDE filename1.tmpl>
   <TMPL_ELSE>
     <TMPL_IF FILENAME2>...etc
   </TMPL_IF>

- a variation of above, using <TMPL_IF EXPR="filename eq 'blah'">
- the problem you are trying to solve actually has a better solution 
that doesn't depend on using a variable as the filename
- using one of the various modified versions HTML::Template (aka 
modified by various users of this email list) which has explicit support 
for this syntax.

hope this helps,
Mathew Robertson


Rajesh Raghammudi wrote:
> I would like to include a file
>
> I can do so by  <tmpl_include NAME=index.html>
>
> But I need include different pages depends on my conditions, I tried 
> below, it did not workout.
>
>  <tmpl_include NAME=<tmpl_var name=FILENAME>>
>
> Please suggest me if any other way to handle this situation.
>
> Thank you.
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ------------------------------------------------------------------------
>
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>   

[htmltmpl] TMPL_INCLUDE doubt

[Rajesh R. <raj...@gm...>]

I would like to include a file

I can do so by  <tmpl_include NAME=index.html>

But I need include different pages depends on my conditions, I tried below,
it did not workout.

 <tmpl_include NAME=<tmpl_var name=FILENAME>>

Please suggest me if any other way to handle this situation.

Thank you.