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

Re: [htmltmpl] RFC: Objects in templates

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

At 10:26 PM 6/2/04 +0530, Philip Tellis wrote:
>Sometime Today, michael assembled some asciibets to say:
>
> > I was wanting to use Class::DBI to Model my data and H::T to View it.
> > When I do this I end up with a lot of code that looks like this
> >
> > $tmpl->param(
> >      ObjAtt1 => $obj->att1,
> >      ObjAtt2 => $obj->att2,
> >      ObjAtt3 => $obj->att3,
> >      ObjAtt4 => $obj->att4,
> >      ObjAtt5 => $obj->att5,
> >       );
>
>Just implement the param() method and include your object in the
>associate list to new.  Simple as that.
<>

That doesn't solve things on the template end:

<TMPL_VAR obj.attr1>

Which gets into how to define a more structured namespace convention than 
the flat one currently used by HTML::Template.

Re: [htmltmpl] RFC: Template Tag Attributes

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

At 01:10 PM 6/2/04 -0400, Sam Tregar wrote:
>On Wed, 2 Jun 2004, Timm Murray wrote:
>
> > I have a project which involves changing our current pages using SSI
> > #includes into using an HTML::Template-based solution instead.  The
> > question of how to search these templates came up, and I've suggested using
> > htdig:// with a filter program that will convert the templates into text
> > for indexing.
>
>I suggest you use a web-spider to index your site, which would of
>course run HTML::Template to produce output.  That way you index
>everything the end-user sees, not just the static parts of the page.
>I don't know for sure but I bet htdig:// comes with a web spider.  If
>not 'wget -r' is handy in a pinch!

See other responses.


> > Inevitably, there will be certain pages using TMPL_INCLUDE tags.  I imagine
> > that most of these will contain data that will not want to be searched for,
> > such as footers, and therefore my filter program can simply ignore
> > them.  However, I don't feel safe in making the blanket assumption that
> > /all/ included files don't need to be searchable.
>
>Now you've lost me.  There's lots of stuff in an HTML page that
>shouldn't be searched for.  Stuff like headers and footers in includes
>is just the tip of the ice-berg.  Why obsess over this?

I want to give content authors more control over what portions of a 
document are searched for.


> > Is it possible to add a flexible attribute system to the current
> > HTML::Template design?  I'm thinking of something like this:
> >
> > <TMPL_INCLUDE NAME="file.txt" SEARCHABLE="no">
>
>I'd write that:
>
>   <TMPL_INCLUDE NAME="file.txt"><!-- SEARCHABLE="no" -->
>
>That way HTML::Template does its job, same as always, and your code
>can key on the special comment.

Yes, I think this is the way to go.


> > I'm sure it can be done with a filter, but frankly, I think that's a
> > cop-out solution, being that the current filter mechanism does not have a
> > way to hook into HTML::Template's parser.
>
>Why would you need to hook into the parser to implement this?

For the attribute syntax I originally suggested, it needs to be notified of 
the extra attributes (which I think would be useful for more than just this 
instance).  More generally, filters should hook into the parser directly 
instead of merely being fed the content to be processed.

Re: [htmltmpl] RFC: Template Tag Attributes

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

At 09:45 AM 6/2/04 -0700, Bill Moseley wrote:
<>
> > I don't think either solution is particularly difficult to implement,
> > but scanning the content files directly also lets us have an easier
> > time analyzing the structure of the document.
>
>All the server does is supply the content.  Analyzing the content
>happens after that, regardless of using the server or the file system.
>Spidering lets you index the content as people see it on their browser.

Take a look at the system being 
used:  http://www.perlmonks.org/index.pl?node_id=357248, particularly the 
'Documents' subsection.

Essentially, the actual content is stored in a POD-like format.  The 
'=NAME' part specifies the TMPL_VAR or TMPL_IF that the given section 
should be placed into.  By having a section '=content' or some such in 
every content file which specifies the regular content (this being defined 
as part of our coding standards), we can have the indexer focus only on 
that.  There is no need to strip away the additional information of 
headers, footers, etc. that shouldn't be searched, because that information 
simply won't be in the text in the first place.  With spidering, I either 
get all the content or none of it, which causes more processing.

Now, the system allows TMPL_INCLUDE tags in the content files (actually, 
it's implemented by passing it through HTML::Template a second time, so any 
TMPL_* tag will be processed, but this might change).  Included files 
occasionally need to be part of the search, but most likely won't.  But I 
don't feel I can make that assumption in all cases.  So I need some way of 
saying which ones should be searched on if we should ever need that 
functionality (but default to not searching).


>Spidering isn't as expensive as people tend to think.  If you are
>running dynamic content as plain CGI then there's your costs.  Sounds
>like you have mostly static content, so that shouldn't be an issue.

With this system, all "HTML" files are being run through an Apache mod_perl 
handler.


>If you can avoid spidering (say your content is in a database) then,
>yes, I'd always just index the content.
>
> > In the case I'm suggesting using, the content files would be
> > re-processed by HTML::Template for any TMPL_INCLUDE tags (however, not
> > much has been created under this system besides some examples, so now
> > is a good time to make incompatible changes if need be).
>
>   <TMPL_INCLUDE NAME="file.txt" SEARCHABLE="no">
>
>So the point is to have some other program not based on HTML::Template
>to parse that?  In that case why not just look for:
>
>    <!-- don't index this section -->
>
>And then use HTML::Template to generate the output for indexing.
>
>
>--
>Bill Moseley
>mo...@ha...

Re: [htmltmpl] RFC: Objects in templates

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

Quoting michael <mi...@pe...>:

> Since others are in the mood for RFCing, here's something that I was
> thinking about implementing for myself and I just wanted to know how
> others felt about it as well. 

This has come up many times on the list.  Search the archives for some other
opinions on this subject.

> I was wanting to use Class::DBI to Model my data and H::T to View it. When I
> do this I end up with a lot of code that looks like this

Good choice, CLass::DBI is great at simplifying database access (at the cost of
performance)

In the past I have used the following in my Class::DBI modules to simplify its
use with HTML::Template.

sub hashref {
  my $self = shift;
  my $hashref = {};
  my @cols = @_ ? @_ : $self->columns();
  foreach my $column (@cols) {
    my $value = $self->get($column);
    $hashref->{$column} = "".$value if defined $value;   # Stringify
  }
  return $hashref;
}

That will flatten the Class::DBI object into a hashref.

> And then the accompanying tmpl_vars in the templates. I was thinking about
> using  something similar to the way Template Toolkit handles it where I can
> just specify an object and then have H::T pull the attributes (or methods)
> as needed.

If you know Template Toolkit can already do this, then why not use that?  It
can't be for performance reasons, cause you are also planning to use Class::DBI
which is slower that straight DBI calls.

I don't want to push you away from HTML::Template unnecesarily, but you should
use the right tool for the job regardless of your loyalties to any one
particular solution.

Cheers,

Cees

Re: [htmltmpl] RFC: Objects in templates

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

On Wed, 2 Jun 2004, michael wrote:

> And then the accompanying tmpl_vars in the templates. I was thinking about
> using  something similar to the way Template Toolkit handles it where I can
> just specify an object and then have H::T pull the attributes (or methods) as
> needed. Something like this...
>
> $tmpl->param(Obj => $obj);
>
> and then in the template have
>
> <tmpl_var name="Obj->att1"> <tmpl_var name="Obj->att2">... etc

I think it would be really easy to do this kind of thing in a
sub-class.  Just override param() to look for objects and turn them
into a set of "obj->attr" params.  I wouldn't use it but I bet some
people would.

-sam

Re: [htmltmpl] RFC: Template Tag Attributes

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

On Wed, 2 Jun 2004, Luke Valenty wrote:

> I use attributes in my template tags without using filters and without
> messing around with HTML::Template's internals.  Here is the format I
> use:
>
>   <TMPL_VAR NAME="name.arg1=val1.arg2=val2">

My eyes!  They burn!  AArrrrgh.

Serriously, that's a terribly idea.  Why are you using HTML::Template
if you want to drive your program from the template?  There are many
systems better suited to this use: Mason, Template Toolkit, Embperl,
etc.  HTML::Template was designed to support a one-way data-flow from
Perl code to HTML template.

-sam

Re: [htmltmpl] RFC: Template Tag Attributes

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

On Wed, 2 Jun 2004, Timm Murray wrote:

> I have a project which involves changing our current pages using SSI
> #includes into using an HTML::Template-based solution instead.  The
> question of how to search these templates came up, and I've suggested using
> htdig:// with a filter program that will convert the templates into text
> for indexing.

I suggest you use a web-spider to index your site, which would of
course run HTML::Template to produce output.  That way you index
everything the end-user sees, not just the static parts of the page.
I don't know for sure but I bet htdig:// comes with a web spider.  If
not 'wget -r' is handy in a pinch!

> Inevitably, there will be certain pages using TMPL_INCLUDE tags.  I imagine
> that most of these will contain data that will not want to be searched for,
> such as footers, and therefore my filter program can simply ignore
> them.  However, I don't feel safe in making the blanket assumption that
> /all/ included files don't need to be searchable.

Now you've lost me.  There's lots of stuff in an HTML page that
shouldn't be searched for.  Stuff like headers and footers in includes
is just the tip of the ice-berg.  Why obsess over this?

> Is it possible to add a flexible attribute system to the current
> HTML::Template design?  I'm thinking of something like this:
>
> <TMPL_INCLUDE NAME="file.txt" SEARCHABLE="no">

I'd write that:

  <TMPL_INCLUDE NAME="file.txt"><!-- SEARCHABLE="no" -->

That way HTML::Template does its job, same as always, and your code
can key on the special comment.

> I'm sure it can be done with a filter, but frankly, I think that's a
> cop-out solution, being that the current filter mechanism does not have a
> way to hook into HTML::Template's parser.

Why would you need to hook into the parser to implement this?

-sam

Re: [htmltmpl] RFC: Objects in templates

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

Sometime Today, michael assembled some asciibets to say:

> I was wanting to use Class::DBI to Model my data and H::T to View it.
> When I do this I end up with a lot of code that looks like this
>
> $tmpl->param(
>      ObjAtt1 => $obj->att1,
>      ObjAtt2 => $obj->att2,
>      ObjAtt3 => $obj->att3,
>      ObjAtt4 => $obj->att4,
>      ObjAtt5 => $obj->att5,
>       );

Just implement the param() method and include your object in the
associate list to new.  Simple as that.

Philip

-- 
"Art thou a witch, *viva espana*?"
        -- The Spanish Inquisition (Tadfield version) in action
           (Terry Pratchett & Neil Gaiman, Good Omens)

Re: [htmltmpl] RFC: Template Tag Attributes

[Bill M. <mo...@ha...>]

On Wed, Jun 02, 2004 at 11:29:47AM -0500, Timm Murray wrote:
> At 09:22 AM 6/2/04 -0700, Bill Moseley wrote:
> >On Wed, Jun 02, 2004 at 11:08:25AM -0500, Timm Murray wrote:
> >> At 09:01 AM 6/2/04 -0700, Bill Moseley wrote:
> >> <>
> >> >Spider your content instead.  Does htdig have anything like
> >> ><!-- noindex --> ?
> >>
> >> We discussed spidering and my boss is against the idea.  I personally 
> >would
> >> prefer not to do it if we can get away with it.
> >
> >Can you explain why?  I'm just curious why spidering would not be ok,
> >but scanning the file system would be.
> 
> Extra work on the server itself.  Scanning the file system is easier on the 
> system than making a request to Apache, even on localhost.

Set a delay on the spider or what I've done is run a separate httpd with
keep-alives way high and a low number of max clients.  Use a spider that
supports keep-alives.

If you spider then you are indexing content that people can find.  And
you don't have to worry about rewrites or aliases.

You also don't need a separate system to generate the content just for
spidering.

> I don't think either solution is particularly difficult to implement,
> but scanning the content files directly also lets us have an easier
> time analyzing the structure of the document.

All the server does is supply the content.  Analyzing the content
happens after that, regardless of using the server or the file system.
Spidering lets you index the content as people see it on their browser.

Spidering isn't as expensive as people tend to think.  If you are
running dynamic content as plain CGI then there's your costs.  Sounds
like you have mostly static content, so that shouldn't be an issue.

If you can avoid spidering (say your content is in a database) then,
yes, I'd always just index the content.

> In the case I'm suggesting using, the content files would be
> re-processed by HTML::Template for any TMPL_INCLUDE tags (however, not
> much has been created under this system besides some examples, so now
> is a good time to make incompatible changes if need be).

  <TMPL_INCLUDE NAME="file.txt" SEARCHABLE="no">

So the point is to have some other program not based on HTML::Template
to parse that?  In that case why not just look for:

   <!-- don't index this section -->

And then use HTML::Template to generate the output for indexing.


-- 
Bill Moseley
mo...@ha...

Re: [htmltmpl] RFC: Template Tag Attributes

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

At 09:22 AM 6/2/04 -0700, Bill Moseley wrote:
>On Wed, Jun 02, 2004 at 11:08:25AM -0500, Timm Murray wrote:
> > At 09:01 AM 6/2/04 -0700, Bill Moseley wrote:
> > <>
> > >Spider your content instead.  Does htdig have anything like
> > ><!-- noindex --> ?
> >
> > We discussed spidering and my boss is against the idea.  I personally 
> would
> > prefer not to do it if we can get away with it.
>
>Can you explain why?  I'm just curious why spidering would not be ok,
>but scanning the file system would be.

Extra work on the server itself.  Scanning the file system is easier on the 
system than making a request to Apache, even on localhost.  I don't think 
either solution is particularly difficult to implement, but scanning the 
content files directly also lets us have an easier time analyzing the 
structure of the document.  In the case I'm suggesting using, the content 
files would be re-processed by HTML::Template for any TMPL_INCLUDE tags 
(however, not much has been created under this system besides some 
examples, so now is a good time to make incompatible changes if need be).

Re: [htmltmpl] RFC: Template Tag Attributes

[Bill M. <mo...@ha...>]

On Wed, Jun 02, 2004 at 11:08:25AM -0500, Timm Murray wrote:
> At 09:01 AM 6/2/04 -0700, Bill Moseley wrote:
> <>
> >Spider your content instead.  Does htdig have anything like
> ><!-- noindex --> ?
> 
> We discussed spidering and my boss is against the idea.  I personally would 
> prefer not to do it if we can get away with it.

Can you explain why?  I'm just curious why spidering would not be ok,
but scanning the file system would be.

-- 
Bill Moseley
mo...@ha...

Re: [htmltmpl] RFC: Objects in templates

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

I've seen ideas like this suggested many times before, and it should be 
done.  Just needs someone to sit down and write the code :)

At 10:29 AM 6/2/04 -0500, michael wrote:
>Since others are in the mood for RFCing, here's something that I was thinking
>about implementing for myself and I just wanted to know how others felt about
>it as well.
>
>I was wanting to use Class::DBI to Model my data and H::T to View it. When I
>do this I end up with a lot of code that looks like this
>
>$tmpl->param(
>      ObjAtt1 => $obj->att1,
>      ObjAtt2 => $obj->att2,
>      ObjAtt3 => $obj->att3,
>      ObjAtt4 => $obj->att4,
>      ObjAtt5 => $obj->att5,
>       );
>
>And then the accompanying tmpl_vars in the templates. I was thinking about
>using  something similar to the way Template Toolkit handles it where I can
>just specify an object and then have H::T pull the attributes (or methods) as
>needed. Something like this...
>
>$tmpl->param(Obj => $obj);
>
>and then in the template have
>
><tmpl_var name="Obj->att1"> <tmpl_var name="Obj->att2">... etc
>
>or something like it. I think it should also allow the user to specify what
>token will be used to separate objects and methods (ie, change '->' to just
>'.' like in Perl6). I think some mechanism should also be given so that you
>can loop around objects as well (an array of objects).
>
>so that
>$tmpl->param(Obj_loop => \@array_of_objs);
>
>would work for
><tmpl_loop Obj_loop>
>   <tmpl_var Obj->att1> <tmpl_var Obj->att2>
></tmpl_loop>
>
>If there are serious reasons for not including this in standard H::T tags then
>maybe some new tags like TMPL_OBJ_VAR and TMPL_OBJ_LOOP.
>
>Questions, comments, verbal abuse welcome.
>
>Michael Peters
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
>installation-authoring solution that does it all. Learn more and
>evaluate today! http://www.installshield.com/Dev2Dev/0504
>_______________________________________________
>Html-template-users mailing list
>Htm...@li...
>https://lists.sourceforge.net/lists/listinfo/html-template-users

Re: [htmltmpl] RFC: Template Tag Attributes

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

At 09:01 AM 6/2/04 -0700, Bill Moseley wrote:
<>
>Spider your content instead.  Does htdig have anything like
><!-- noindex --> ?

We discussed spidering and my boss is against the idea.  I personally would 
prefer not to do it if we can get away with it.

Re: [htmltmpl] RFC: Template Tag Attributes

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

At 07:23 PM 6/2/04 +0400, Alex Kapranoff wrote:
>   I'd suppose supplying your filter program with a list of exclusions
>(regexps or whatever). If a particular file your program is run
>against is in the list then do not index it. This is much more easier
>compared to tagging all <TMPL_INCLUDE> constructs and is flexible too.
>Think that you could just exclude all qr/_header\.tmpl$/

We wouldn't need to tag all the TMPL_INCLUDE tags.  A reasonable default 
should be "no search".  It's also possible someone will want a given 
include indexed on one page but not anther.


>   And there's of course a question whether you really want to index
>templates which are metadata of your website or its content.

See my reply to Phillip.


>* Timm Murray <tm...@ag...> [June 02 2004, 17:55]:
> > I have a project which involves changing our current pages using SSI
> > #includes into using an HTML::Template-based solution instead.  The
> > question of how to search these templates came up, and I've suggested 
> using
> > htdig:// with a filter program that will convert the templates into text
> > for indexing.
> >
> > Inevitably, there will be certain pages using TMPL_INCLUDE tags.  I 
> imagine
> > that most of these will contain data that will not want to be searched 
> for,
> > such as footers, and therefore my filter program can simply ignore
> > them.  However, I don't feel safe in making the blanket assumption that
> > /all/ included files don't need to be searchable.
> >
> > Is it possible to add a flexible attribute system to the current
> > HTML::Template design?  I'm thinking of something like this:
> >
> > <TMPL_INCLUDE NAME="file.txt" SEARCHABLE="no">
> >
> > The additional attribute(s) could be ignored by HTML::Template, but hold
> > meaning for external programs that need additional information on the
> > template tag.
> >
> > I'm sure it can be done with a filter, but frankly, I think that's a
> > cop-out solution, being that the current filter mechanism does not have a
> > way to hook into HTML::Template's parser.
>
>--
>Alex Kapranoff.
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
>installation-authoring solution that does it all. Learn more and
>evaluate today! http://www.installshield.com/Dev2Dev/0504
>_______________________________________________
>Html-template-users mailing list
>Htm...@li...
>https://lists.sourceforge.net/lists/listinfo/html-template-users

Re: [htmltmpl] RFC: Template Tag Attributes

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

At 08:39 PM 6/2/04 +0530, Philip Tellis wrote:
>Sometime Today, Timm Murray assembled some asciibets to say:
>
> > I have a project which involves changing our current pages using SSI
> > #includes into using an HTML::Template-based solution instead.  The
> > question of how to search these templates came up, and I've suggested
> > using htdig:// with a filter program that will convert the templates
> > into text for indexing.
>
>Not sure exactly what you're looking for, but one doesn't generally
>index Templates for searching.  One indexes content, and that's
>generally stored in a database.

In this specific case, the "templates" are actually the content stored in 
individual files that need to be able to include something from another 
file.  In some cases, the include needs to be searchable, but often not.

The system being used is similar to the one documented at 
'http://www.perlmonks.org/index.pl?node_id=357248', which (as the comments 
on that page bring out) is something like Apache::Template, but with 
HTML::Template as the backend.

Re: [htmltmpl] RFC: Template Tag Attributes

[Bill M. <mo...@ha...>]

On Wed, Jun 02, 2004 at 08:55:43AM -0500, Timm Murray wrote:
> I have a project which involves changing our current pages using SSI 
> #includes into using an HTML::Template-based solution instead.  The 
> question of how to search these templates came up, and I've suggested using 
> htdig:// with a filter program that will convert the templates into text 
> for indexing.

Spider your content instead.  Does htdig have anything like 
<!-- noindex --> ?

If not, you can use swish-e (http://swish-e.org) and then wrap your
headers, footers and menus in <!-- noindex --> .... <!-- index -->

-- 
Bill Moseley
mo...@ha...

Re: [htmltmpl] RFC: Template Tag Attributes

[Luke V. <lu...@ms...>]

As I understand it, it looks like he's converting their existing web
pages from SSI includes to use HTML::Template instead.  Maybe that 
there is some dynamic content they want in their pages that apache
just doesn't want to do.  I'll be there is a better way to do this
though.

Luke

On Wed, Jun 02, 2004 at 10:40:51AM -0500, Puneet Kishor wrote:
> 
> On Jun 2, 2004, at 8:55 AM, Timm Murray wrote:
> 
> >I have a project which involves changing our current pages using SSI 
> >#includes into using an HTML::Template-based solution instead.  The 
> >question of how to search these templates came up, and I've suggested 
> >using htdig:// with a filter program that will convert the templates 
> >into text for indexing.
> >
> >Inevitably, there will be certain pages using TMPL_INCLUDE tags.
> 
> Timm,
> 
> This is a bit confusing. Templates, by general definition, are 
> templates which either don't contain any content, or contain content 
> not worth a hoot (logo, byline, and other such junk). Essentially, 
> templates are code. Why would you want to search them? Ostensibly you 
> are getting data from some other source that you are "pouring" into the 
> templates... index and search that data, and then use another template 
> to display the results.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

Re: [htmltmpl] RFC: Template Tag Attributes

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

On Jun 2, 2004, at 8:55 AM, Timm Murray wrote:

> I have a project which involves changing our current pages using SSI 
> #includes into using an HTML::Template-based solution instead.  The 
> question of how to search these templates came up, and I've suggested 
> using htdig:// with a filter program that will convert the templates 
> into text for indexing.
>
> Inevitably, there will be certain pages using TMPL_INCLUDE tags.

Timm,

This is a bit confusing. Templates, by general definition, are 
templates which either don't contain any content, or contain content 
not worth a hoot (logo, byline, and other such junk). Essentially, 
templates are code. Why would you want to search them? Ostensibly you 
are getting data from some other source that you are "pouring" into the 
templates... index and search that data, and then use another template 
to display the results.

[htmltmpl] RFC: Objects in templates

[michael <mi...@pe...>]

Since others are in the mood for RFCing, here's something that I was thinking
about implementing for myself and I just wanted to know how others felt about
it as well. 

I was wanting to use Class::DBI to Model my data and H::T to View it. When I
do this I end up with a lot of code that looks like this

$tmpl->param( 
     ObjAtt1 => $obj->att1,
     ObjAtt2 => $obj->att2,
     ObjAtt3 => $obj->att3,
     ObjAtt4 => $obj->att4,
     ObjAtt5 => $obj->att5,
      );

And then the accompanying tmpl_vars in the templates. I was thinking about
using  something similar to the way Template Toolkit handles it where I can
just specify an object and then have H::T pull the attributes (or methods) as
needed. Something like this...

$tmpl->param(Obj => $obj);

and then in the template have

<tmpl_var name="Obj->att1"> <tmpl_var name="Obj->att2">... etc

or something like it. I think it should also allow the user to specify what
token will be used to separate objects and methods (ie, change '->' to just
'.' like in Perl6). I think some mechanism should also be given so that you
can loop around objects as well (an array of objects).

so that 
$tmpl->param(Obj_loop => \@array_of_objs);

would work for
<tmpl_loop Obj_loop>
  <tmpl_var Obj->att1> <tmpl_var Obj->att2>
</tmpl_loop>

If there are serious reasons for not including this in standard H::T tags then
maybe some new tags like TMPL_OBJ_VAR and TMPL_OBJ_LOOP.

Questions, comments, verbal abuse welcome.

Michael Peters

Re: [htmltmpl] RFC: Template Tag Attributes

[Alex K. <ka...@ra...>]

  I'd suppose supplying your filter program with a list of exclusions
(regexps or whatever). If a particular file your program is run
against is in the list then do not index it. This is much more easier
compared to tagging all <TMPL_INCLUDE> constructs and is flexible too.
Think that you could just exclude all qr/_header\.tmpl$/

  And there's of course a question whether you really want to index
templates which are metadata of your website or its content.

* Timm Murray <tm...@ag...> [June 02 2004, 17:55]:
> I have a project which involves changing our current pages using SSI 
> #includes into using an HTML::Template-based solution instead.  The 
> question of how to search these templates came up, and I've suggested using 
> htdig:// with a filter program that will convert the templates into text 
> for indexing.
> 
> Inevitably, there will be certain pages using TMPL_INCLUDE tags.  I imagine 
> that most of these will contain data that will not want to be searched for, 
> such as footers, and therefore my filter program can simply ignore 
> them.  However, I don't feel safe in making the blanket assumption that 
> /all/ included files don't need to be searchable.
> 
> Is it possible to add a flexible attribute system to the current 
> HTML::Template design?  I'm thinking of something like this:
> 
> <TMPL_INCLUDE NAME="file.txt" SEARCHABLE="no">
> 
> The additional attribute(s) could be ignored by HTML::Template, but hold 
> meaning for external programs that need additional information on the 
> template tag.
> 
> I'm sure it can be done with a filter, but frankly, I think that's a 
> cop-out solution, being that the current filter mechanism does not have a 
> way to hook into HTML::Template's parser.

-- 
Alex Kapranoff.

Re: [htmltmpl] RFC: Template Tag Attributes

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

Sometime Today, Timm Murray assembled some asciibets to say:

> I have a project which involves changing our current pages using SSI
> #includes into using an HTML::Template-based solution instead.  The
> question of how to search these templates came up, and I've suggested
> using htdig:// with a filter program that will convert the templates
> into text for indexing.

Not sure exactly what you're looking for, but one doesn't generally
index Templates for searching.  One indexes content, and that's
generally stored in a database.


-- 
"Remember, extremism in the nondefense of moderation is not a virtue."
-- Peter Neumann, about usenet

Re: [htmltmpl] RFC: Template Tag Attributes

[Luke V. <lu...@ms...>]

I use attributes in my template tags without using filters and without
messing around with HTML::Template's internals.  Here is the format I 
use:

  <TMPL_VAR NAME="name.arg1=val1.arg2=val2">

In my perl script I use a few different routines to manage my templates.
I setup most of the subroutines so that they are called when their namesake
is used as a TMPL_VAR name in a template.  I created a function that binds
subroutines to template tags.  When a tag is present in the template, the
corresponding subrouting is executed with its arguments passed to it as
a hash reference.  Here is some code I use for this very purpose:


sub parseParameters {
  %parameter_hash = ();
  my @tags = $t->param(); # Get a list of tags present in the template
  foreach $tag (@tags) {  
    $tag =~ /^([^.]*)\.?(.*)?$/; # Split the tag names into 'name' and
    $function = $1;              # 'argument' parts
    $parameters = $2;
    if(exists $tagFunctions{$function}) {  # If a function exists for this tag...
      foreach $pair (split(/\./, $parameters)) {
        $pair =~ /^([^=]*)=(.*)$/;
        $parameter_hash{$1} = $2;          # Add its parameters to a hash
      }
      my $value = $tagFunctions{$function}->(\%parameter_hash); # call the function
      $t->param($tag => $value); # insert the return value into the tag
    }
  }
  #return 1;
}
# This subroutine works well for loops too.

sub regTags {
  foreach $tag (@_) {
    eval "\$tagFunctions{" . $tag . "} = \\&" . $tag . ";";
  }
}

regTags(qw(remoteInclude setVar otherFunction));
parseParameters();

Using code like this has drastically improved script creation time as the
only code I need to write when I create a new script is only the code that
is specific to that application.  This works very well for loops too.

The only drawback to this method is that you would have to create your on
function for including files so that you could pass your own arguments to it.

I even went as far as to create a tag function that allows me to set the
value of another tag function.  This helps a lot for managing headers and
footers, I can set the title of the page in just one spot.  I believe I
also created a function to do a remote include for that same reason.  So that
I can choose which sub-menu file I want to include into the header file from
the main template file.

Luke

On Wed, Jun 02, 2004 at 08:55:43AM -0500, Timm Murray wrote:
> I have a project which involves changing our current pages using SSI 
> #includes into using an HTML::Template-based solution instead.  The 
> question of how to search these templates came up, and I've suggested using 
> htdig:// with a filter program that will convert the templates into text 
> for indexing.
> 
> Inevitably, there will be certain pages using TMPL_INCLUDE tags.  I imagine 
> that most of these will contain data that will not want to be searched for, 
> such as footers, and therefore my filter program can simply ignore 
> them.  However, I don't feel safe in making the blanket assumption that 
> /all/ included files don't need to be searchable.
> 
> Is it possible to add a flexible attribute system to the current 
> HTML::Template design?  I'm thinking of something like this:
> 
> <TMPL_INCLUDE NAME="file.txt" SEARCHABLE="no">
> 
> The additional attribute(s) could be ignored by HTML::Template, but hold 
> meaning for external programs that need additional information on the 
> template tag.
> 
> I'm sure it can be done with a filter, but frankly, I think that's a 
> cop-out solution, being that the current filter mechanism does not have a 
> way to hook into HTML::Template's parser.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

[htmltmpl] RFC: Template Tag Attributes

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

I have a project which involves changing our current pages using SSI 
#includes into using an HTML::Template-based solution instead.  The 
question of how to search these templates came up, and I've suggested using 
htdig:// with a filter program that will convert the templates into text 
for indexing.

Inevitably, there will be certain pages using TMPL_INCLUDE tags.  I imagine 
that most of these will contain data that will not want to be searched for, 
such as footers, and therefore my filter program can simply ignore 
them.  However, I don't feel safe in making the blanket assumption that 
/all/ included files don't need to be searchable.

Is it possible to add a flexible attribute system to the current 
HTML::Template design?  I'm thinking of something like this:

<TMPL_INCLUDE NAME="file.txt" SEARCHABLE="no">

The additional attribute(s) could be ignored by HTML::Template, but hold 
meaning for external programs that need additional information on the 
template tag.

I'm sure it can be done with a filter, but frankly, I think that's a 
cop-out solution, being that the current filter mechanism does not have a 
way to hook into HTML::Template's parser.

Re: [htmltmpl] [Question] Clearing <TMPL_LOOP> content after first pass

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

 >Surely that should be:
   $template->param(res => $res);

Looks like that's correct, 'cause I made the change, and
all is well. Sometimes it's hell being a newbie ...

I guess what I just learned is that you can assign the
values from a select immediately to an individual template ...
I was taking the approach that I needed to assign the values
to the script's "global" object in order to be able to
utilize the variables in a template.

... guess that's why they call it a learning curve

Thanks, Sam

Carl Hagstrom


At 12:52 PM 5/21/2004, Sam Tregar wrote:
>On Fri, 21 May 2004, C Hagstrom wrote:
>
> > my $res = $sth->fetchall_arrayref({});
> >
> > ...................
> >
> > assign it to a parameter:
> >
> > $q->param(res => $res);
>
>Surely that should be:
>
>   $template->param(res => $res);
>
>There's no reason to give CGI::param() an array of hash-refs, is there?
>
>-sam


C. Hagstrom
hag...@ep...       

Re: [htmltmpl] [Question] Clearing <TMPL_LOOP> content after first pass

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

On Fri, 21 May 2004, C Hagstrom wrote:

> my $res = $sth->fetchall_arrayref({});
>
> ...................
>
> assign it to a parameter:
>
> $q->param(res => $res);

Surely that should be:

  $template->param(res => $res);

There's no reason to give CGI::param() an array of hash-refs, is there?

-sam