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

Re: [htmltmpl] Re: H::T future

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

On Tue, 9 Dec 2003, Lance A. Brown wrote:

>      # we allow tags like this in our templates that will define values
>      # to be set as parameters
>      # <TMPL_VALUE NAME="name" VALUE="value">

My eyes!  It burns!  Arrrrrrrgh...

-sam

[htmltmpl] Re: H::T future

[Lance A. B. <la...@be...>]

Lance A. Brown wrote:
> Argh.  I can't remember where, but I ran across a Website package using
> HTML::Template that had this feature.

Aha!  Found it!

Yapcom, the CGI::App-based application to handle registration and 
workshops for YAP conferences!

Here is the relevant piece of code.  Personally, I think this is a VERY 
tasty hack.  It lets page designers plug parameters back into the 
templating system for use elsewhere.  Very cool.

sub _server_page {
     my $self = shift;
     my ($page) = @_;
     my $q = $self->query;

     # we allow tags like this in our templates that will define values
     # to be set as parameters
     # <TMPL_VALUE NAME="name" VALUE="value">
     my %h;
     my $filter = sub {
        my $text_ref = shift;
        while ($$text_ref =~ 
s/<\s*TMPL_VALUE\s+NAME="([^"]*)"\s+VALUE="([^"]*)"\s*>//) {
           $h{$1} = $2;
        }
     };

     my $t = $self->load_tmpl(
         "$page.tmpl",
         die_on_bad_params => 0,
         filter => $filter,
         associate => $q,
         path => $templates_dir,
     );

     $t->param(%h);
     $t->param(VERSION => $YAPC::Organizer::VERSION);

     return $t;
}

--[Lance]


> 
> The templates in the package have <TMPL_VALUE name="foo" value="bar">
> tags and used a filter function to extract them from the templates and
> insert them into the template params.  It was a very neat hack.
> 
> --[Lance]
> 

-- 
  Carolina Spirit Quest:  http://www.carolinaspiritquest.org/
  Celebrate The Circle: http://www.angelfire.com/nc/celebratethecircle/
  My LiveJournal: http://www.livejournal.com/users/labrown/

RE: [htmltmpl] Re: H::T future

[Paulsen, B. <BPa...@le...>]

I wrote something that takes Dreamweaver template files and does roughly
what you suggest.

The syntax on that is something like this:
<!-- TemplateParam name="foo" value="bar" -->

Alternatively, you can use the DEFAULT function already built into
HTML::Template
<!-- TMPL_VAR NAME="foo" DEFAULT="bar" -->

The name of the package that I wrote is called
HTML::Template::Filter::Dreamweaver and is downloadable from CPAN.

Brian

-----Original Message-----
From: Cees Hek [mailto:ce...@si...] 
Sent: Tuesday, December 09, 2003 9:04 AM
To: Lance A. Brown
Cc: HTML Users
Subject: Re: [htmltmpl] Re: H::T future


Lance A. Brown wrote:
> On Mon, 2003-12-08 at 20:31, Karen J. Cravens wrote:
> Argh.  I can't remember where, but I ran across a Website package 
> using HTML::Template that had this feature.
> 
> The templates in the package have <TMPL_VALUE name="foo" value="bar"> 
> tags and used a filter function to extract them from the templates and 
> insert them into the template params.  It was a very neat hack.

I spent about an hour last night trying to find the same website with no 
success :)  It really was a cool little feature, but I can't for the 
life of me remember where I saw it...

Hoping someone else remembers and is kind enough to post an URL.

Cheers,

Cees



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Html-template-users mailing list Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users


------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the
designated recipient(s) named above.  If you are not the intended recipient of
this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited.  This
communication is for information purposes only and should not be regarded as
an offer to sell or as a solicitation of an offer to buy any financial
product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers.  Email transmission cannot be guaranteed to be
secure or error-free.  Therefore, we do not represent that this information is
complete or accurate and it should not be relied upon as such.  All
information is subject to change without notice.

Re: [htmltmpl] Re: H::T future

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

Lance A. Brown wrote:
> On Mon, 2003-12-08 at 20:31, Karen J. Cravens wrote:
> Argh.  I can't remember where, but I ran across a Website package using
> HTML::Template that had this feature.
> 
> The templates in the package have <TMPL_VALUE name="foo" value="bar">
> tags and used a filter function to extract them from the templates and
> insert them into the template params.  It was a very neat hack.

I spent about an hour last night trying to find the same website with no 
success :)  It really was a cool little feature, but I can't for the 
life of me remember where I saw it...

Hoping someone else remembers and is kind enough to post an URL.

Cheers,

Cees

[htmltmpl] Re: H::T future

[Lance A. B. <la...@be...>]

On Mon, 2003-12-08 at 20:31, Karen J. Cravens wrote:
> Okay, I did think of a teeny-tiny thing I'd like to have.  It's not
> exactly an addition to H::T itself, though.
> 
> I occasionally find myself wanting to be able to define things in the
> template.  That is, setting parameters, a sort of tiny configuration file.
> 
> I've been meaning to write a standard bit of code to do something like
> that whenever I need some parameters that I don't want to hardcode, but
> that I don't really need a full-fledged configuration file manager for...
> something with just enough brains to parse a file, populate variables as
> needed, and recognize when the configuration ends and the template begins,
> and hand the rest of the file off to a new H::T instance.

Argh.  I can't remember where, but I ran across a Website package using
HTML::Template that had this feature.

The templates in the package have <TMPL_VALUE name="foo" value="bar">
tags and used a filter function to extract them from the templates and
insert them into the template params.  It was a very neat hack.

--[Lance]

-- 
  Carolina Spirit Quest:  http://www.carolinaspiritquest.org/
  Celebrate The Circle: http://www.angelfire.com/nc/celebratethecircle/ 
  My LiveJournal: http://www.livejournal.com/users/labrown/ 

[htmltmpl] enhancements to H::T

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

> > But, since not being able to visualize the form of H-T's future =
might be
> > due to my lack of imagination, I am curious -- what are the ways in
> > which the developer-kind want to see H-T to be in a few =
years/versions
> > or so...

I have modifie a local copy of H::T which includes some changes which =
may or may not be of use to others.  The changes include:

- TMPL_ELSIF tag, eg <TMPL_ELSIF somevar>
- support for custom tags, eg <TMPL_CATGETS ...>
- trailing slash in tags, aka <TMPL... />
- TVPL_VAR support for HTML=3DTEXT which allows paragraphs of text to be =
formatted to respect newlines
- dot syntax, eg 'user.name'
- dot syntax with autovivification of leading template variable, eg =
'user.name' results in autovivification of 'user'

I have included documentation to support the enhancements.
Also, I have bumped the revision number to 2.7 so as to indicate a =
non-standard release.

I can sen this modified/enhanced version to anyone who is interested.

regards,
Mathew

[htmltmpl] test - please ignore

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

test - please ignore

Re: H::T future (was Re: [htmltmpl] xml complant tags)

[Andrew J. <ajh...@ex...>]

Paulsen, Brian wrote:

>I think a few bug fixes and performance tweaks have been offered.  Other
>than that, I agree with your assessment - it is near perfect.
>
>What surprises me is how few people know about it.  I have a copy of the
>"Perl Black Book" and the second edition of the "Perl Cookbook".  Neither
>one mentions HTML::Template in the discussion of HTML templating solutions.
>  
>
I also find the general ignorance of HTML::Template's existence 
surprising.  HTML::Template's caching options in particular are more 
advanced than several other template solutions I'm aware of, yet somehow 
they seem to have more 'mindshare.'

And yes, IMHO HTML::Template is nearly perfect!

Re: H::T future (was Re: [htmltmpl] xml complant tags)

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

Sam Tregar wrote:
> I've considered doing an HTML::Template version 3 a few times, but
> never found the time to do it.  I even went so far as to draft a
> design document.  Here it is!  (Note, I have no plans to actually do
> this work anytime soon.)

Hi Sam,

Something that might be of interest to you that I came across just the 
other day, is the design documents for the up coming Template Toolkit 3.

I have always found that HTML::Template and Template Toolkit complement 
each other, and each have their own niche.  However, if you haven't 
already done so, I would recommend reading the following document by 
Andy Wardley where he talks about some of the changes he plans to 
implement in TT 3.

http://www.template-toolkit.org/tt3/design/namespace.html

He seems to mirror several of the suggestions that you are making in 
your notes.  The most interesting thing I noticed is that he hopes to 
include 'Language Packs', where the module can support other templating 
languages, like HTML::Template and Mason...

I would be very interested in seeing a module that was able to gather 
the best of both modules under one roof (still allowing the strict 
simplicity of HTML::Template, or if warrented turning on some of the 
power of TT).  One concern I see is that one of the key reasons people 
use HTML::Template is the blazing speed that it performs at.  I fear 
that too much abstraction and generalization may hamper that (it doesn't 
have to, but it may).

For now I will continue to use HTML::Template and TT2 where I see fit...

Cheers,

Cees

[htmltmpl] Re: H::T future

[Karen J. C. <si...@ph...>]

Okay, I did think of a teeny-tiny thing I'd like to have.  It's not
exactly an addition to H::T itself, though.

I occasionally find myself wanting to be able to define things in the
template.  That is, setting parameters, a sort of tiny configuration file.

I've been meaning to write a standard bit of code to do something like
that whenever I need some parameters that I don't want to hardcode, but
that I don't really need a full-fledged configuration file manager for...
something with just enough brains to parse a file, populate variables as
needed, and recognize when the configuration ends and the template begins,
and hand the rest of the file off to a new H::T instance.

-- 
Karen J. Cravens  si...@ph...

Re: H::T future (was Re: [htmltmpl] xml complant tags)

[Karen J. C. <si...@ph...>]

On Mon, 8 Dec 2003, Wayne Walker wrote:

WW>I would actually like a function to tell me what variables and or loops
WW>in the template were NOT populated.  That way I can email or log the
WW>fact.  This often happens when a web designer includes a component the
WW>developer doesn't know about so it is not getting populated.

That's relatively simple: just loop through $template->param() and find
everything that's !defined $template->param($_).  (Or something like
that... blame antihistamines for anything goofy in the preceding.)

That might be a good recipe (a la Perl Cookbook) to include in the
documentation, though.  Especially fancy variations that can look inside
loops.

-- 
Karen J. Cravens  si...@ph...

Re: H::T future (was Re: [htmltmpl] xml complant tags)

[Wayne W. <ww...@by...>]

I would actually like a function to tell me what variables and or loops
in the template were NOT populated.  That way I can email or log the
fact.  This often happens when a web designer includes a component the
developer doesn't know about so it is not getting populated.

On Mon, Dec 08, 2003 at 05:21:26PM -0600, Karen J. Cravens wrote:
> On Mon, 8 Dec 2003, Sam Tregar wrote:
> 
> ST>Make global_vars=1 the default mode and build it in right from the
> ST>start.  It's what everyone expects when they first use the module and
> ST>I think it was a mistake to have it default off.  In fact, I lean
> ST>towards removing the option entirely.
> 
> I could go for this.
> 
> I also almost always have die-on-invalid shut off, because I tend to want
> my code to shove as many parameters as possible out for use, but my
> templates don't always use them.  I may be in the minority there, though.
> (If I was doing thorough debugging, I suppose I'd have it turned on at
> first, and have test templates that accept all of them and make sure
> they're showing properly, and then turn it off for production use.)
> 
> -- 
> Karen J. Cravens  si...@ph...
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

-- 

Wayne Walker
ww...@by...                 Do you use Linux?!
http://www.bybent.com              Get Counted!  http://counter.li.org/
Perl - http://www.perl.org/        Perl User Groups - http://www.pm.org/
Jabber IM:  ww...@ja...       AIM:     lwwalkerbybent

Re: H::T future (was Re: [htmltmpl] xml complant tags)

[Karen J. C. <si...@ph...>]

On Mon, 8 Dec 2003, Roger Burton West wrote:

RBW>I have not yet used global_vars=1 in 3+ years of using H::T. I am after
RBW>all a coder, and I _expect_ local variables... I'd certainly like to
RBW>keep local variables as an option, at least, though most of my templates
RBW>don't care.

This may just depend on the sort of things we each typically code for...
I end up with quite a lot of nested tables, with repeated information from
higher levels inside.  I could get by without the globals, but it'd mean
building bulkier loop-parameter arrays.

Some of that's probably due to my penchant for constructing URLs inside
the templates rather than in the code, of course.

-- 
Karen J. Cravens  si...@ph...

Re: H::T future (was Re: [htmltmpl] xml complant tags)

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

On Mon, Dec 08, 2003 at 05:21:26PM -0600, Karen J. Cravens wrote:
>On Mon, 8 Dec 2003, Sam Tregar wrote:
>ST>Make global_vars=1 the default mode and build it in right from the
>ST>start.  It's what everyone expects when they first use the module and
>ST>I think it was a mistake to have it default off.  In fact, I lean
>ST>towards removing the option entirely.
>I could go for this.

I have not yet used global_vars=1 in 3+ years of using H::T. I am after
all a coder, and I _expect_ local variables... I'd certainly like to
keep local variables as an option, at least, though most of my templates
don't care.

>I also almost always have die-on-invalid shut off, because I tend to want
>my code to shove as many parameters as possible out for use, but my
>templates don't always use them.  I may be in the minority there, though.

If so, I am too. Highly useful.

I sometimes think about a "production mode" H::T module that would strip
out all the syntax checking stuff and simply assume that the templates
are valid (thereby running even faster).

Roger

Re: H::T future (was Re: [htmltmpl] xml complant tags)

[Karen J. C. <si...@ph...>]

On Mon, 8 Dec 2003, Sam Tregar wrote:

ST>Make global_vars=1 the default mode and build it in right from the
ST>start.  It's what everyone expects when they first use the module and
ST>I think it was a mistake to have it default off.  In fact, I lean
ST>towards removing the option entirely.

I could go for this.

I also almost always have die-on-invalid shut off, because I tend to want
my code to shove as many parameters as possible out for use, but my
templates don't always use them.  I may be in the minority there, though.
(If I was doing thorough debugging, I suppose I'd have it turned on at
first, and have test templates that accept all of them and make sure
they're showing properly, and then turn it off for production use.)

-- 
Karen J. Cravens  si...@ph...

Re: H::T future (was Re: [htmltmpl] xml complant tags)

[Karen J. C. <si...@ph...>]

On Mon, 8 Dec 2003, Puneet Kishor wrote:

PK>Just making it a part of core Perl would be a serious benefit for the
PK>use of Perl for web-apps. Where do I cast my vote? Where do I lobby?

I think first it needs a name change.  It should have "Simple" or "Lite"
in it somewhere, and "HTML" in it nowhere.  Aside from the appearance of
the TMPL_ tags, it's not especially HTML-centric, and certainly some of us
use it for generic templating.

Course, that'd add work for us existing users, so I'm not going to lobby
too hard for that change...

-- 
Karen J. Cravens  si...@ph...

Re: H::T future (was Re: [htmltmpl] xml complant tags)

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

> speaking of which, I have often wondered what could be improved in =
H-T,=20
> and have failed to come up with anything. It just seems to be that=20
> perfect program that does perfectly what it said to do. Simple to=20
> install and understand, well-documented, and fast. In fact, imho, it=20
> should be made a core part of Perl as is CGI.pm.
>=20
> But, since not being able to visualize the form of H-T's future might =
be=20
> due to my lack of imagination, I am curious -- what are the ways in=20
> which the developer-kind want to see H-T to be in a few years/versions =

> or so...


Attached is my local copy of H::T which includes some changes which may =
or may not be of use.  The changes include:

- TMPL_ELSIF tag, eg <TMPL_ELSIF somevar>
- support for custom tags, eg <TMPL_CATGETS ...>
- trailing slash in tags, aka <TMPL... />
- TVPL_VAR support for HTML=3DTEXT which allows paragraphs of text to be =
formatted to respect newlines
- dot syntax, eg 'user.name'
- dot syntax with autovivification of leading template variable, eg =
'user.name' results in autovivification of 'user'

I have included documentation to support the enhancements.
Also, I have bumped the revision number to 2.7 so as to indicate a =
non-standard release.

Feel free to suggest / flame me.
Mathew

Re: H::T future (was Re: [htmltmpl] xml complant tags)

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

Sam Tregar wrote:

> On Mon, 8 Dec 2003, Puneet Kishor wrote:
> 
> 
>>speaking of which, I have often wondered what could be improved in H-T,
>>and have failed to come up with anything. It just seems to be that
>>perfect program that does perfectly what it said to do. Simple to
>>install and understand, well-documented, and fast. In fact, imho, it
>>should be made a core part of Perl as is CGI.pm.
> 
> 
..
> I've considered doing an HTML::Template version 3 a few times, but
> never found the time to do it.  I even went so far as to draft a
> design document.  Here it is!  (Note, I have no plans to actually do
> this work anytime soon.)

thank heavens! (just rename the darn thing version 3.142 since some 
folks don't like upgrading to whole numbers -- pi in their face).

Seriously, both those who create with H-T and those who are 
current/potential users of H-T-driven applications would benefit the 
most if H-T were a part of core Perl. None of asking users to install 
H-T or including it in applications. H-T is so much more useful that 
CGI.pm (in my opinion), and if anything, CGI.pm is made worthwhile 
because of H-T.

Just making it a part of core Perl would be a serious benefit for the 
use of Perl for web-apps. Where do I cast my vote? Where do I lobby?

Re: H::T future (was Re: [htmltmpl] xml complant tags)

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

On Mon, 8 Dec 2003, Puneet Kishor wrote:

> speaking of which, I have often wondered what could be improved in H-T,
> and have failed to come up with anything. It just seems to be that
> perfect program that does perfectly what it said to do. Simple to
> install and understand, well-documented, and fast. In fact, imho, it
> should be made a core part of Perl as is CGI.pm.

Thanks!

> But, since not being able to visualize the form of H-T's future might be
> due to my lack of imagination, I am curious -- what are the ways in
> which the developer-kind want to see H-T to be in a few years/versions
> or so...

I've considered doing an HTML::Template version 3 a few times, but
never found the time to do it.  I even went so far as to draft a
design document.  Here it is!  (Note, I have no plans to actually do
this work anytime soon.)


=head1 HTML Template Version 3

HTML::Template needs work.  The module is being put to uses today that
are far outside the scope of the original design.  Adventures in
syntax enhancement (tmpl_if, HTML::Template::Expr, filter),
performance enhancement (HTML::Template::JIT) and CGI frameworks
(CGI::Application, HTML::Pager) have pushed HTML::Template's code to
the limit.  Options have been added incrementally, and the complexity
of the code has grown exponentially with each addition (global_vars,
case_insensitive, cache).

However, I have no plans to throw the baby out with the bath-water.  I
think HTML::Template has a lot going for it.  First, it's fast and
that won't change.  Second, the default template syntax is, in my
never humble opinion, basically perfect.  Finally, the API is pretty
good.  In particular, the simplicity of new(), param() and output() is
not something I want to mess with.

So, what am I going to change?  Here's an unordered list of
possibilities.  Take a look through and tell me what you think.  Am I
out of my mind?  Did I leave out the feature you've always wanted?

=over 4

=item *

Pluggable interface for parsers, file loaders, parameter collectors,
cachers, compilers and executors.  I want to break up HTML::Template's
implementation into a handful of well-defined modules.  Each of these
modules will have an interface which may be implemented independently.

This will make building stuff like HTML::Template::Expr and
HTML::Template::JIT much easier, as well as opening up the field for
simpler, faster implementations of the standard components.

=item *

Make the parser module accessible outside of HTML::Template.  This
will make building tools that work with HTML::Template format
templates much simpler.

=item *

Pluggable interface for custom tags and attributes.  You'd think after
writing HTML::Template::Expr I'd realize that this was a necessity,
but it still feels like treason.  However, I think I'm just going to
have to accept that people are going to want to invent their own tags.
Making them use a filter is just not convenient enough.

This should also address the recurring ESCAPE=foo requests.

=item *

Make global_vars=1 the default mode and build it in right from the
start.  It's what everyone expects when they first use the module and
I think it was a mistake to have it default off.  In fact, I lean
towards removing the option entirely.

=item *

Parse and cache <tmpl_include>s separately.  This will break some
things that currently work, like putting the top of a <tmpl_loop> in
one include and the </tmpl_loop> in another.  However, for the vast
majority of uses this should provide a nice decrease in memory usage
and increase in performance.

=item *

Work out a mechanism for variable includes.  With include files being
parsed and cache separately this is will probably be easier.

=item *

Better user-error detection.  Many common cases could be caught
automatically and reported to the user.  For example, assigning a loop
row the same hash-ref multiple times should trigger an error.

=back


-sam

Re: H::T future (was Re: [htmltmpl] xml complant tags)

[Karen J. C. <si...@ph...>]

On Mon, 8 Dec 2003, Puneet Kishor wrote:

PK>But, since not being able to visualize the form of H-T's future might be
PK>due to my lack of imagination, I am curious -- what are the ways in
PK>which the developer-kind want to see H-T to be in a few years/versions
PK>or so...

Aside from the bugfix in nested loops, I can't think of anything in
particular I'd like to change.

*Maybe* something formal to "comment" the fields in the template without
having anything show in the final output, but right now I can do that with
a filter and judiciously formatted HTML comments, so I don't know that
it'd be worth adding code to the module for.  I like minimalistic modules.

-- 
Karen J. Cravens  si...@ph...

Re: [htmltmpl] xml complant tags

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

On Mon, 8 Dec 2003, paul POULAIN wrote:

> For instance, h::t tags are not html valid <TMPL_VAR name="X"> is NOT
> valid. It should be : <TMPL_VAR name="X"/>.

You mean "XML valid" right?  HTML::Template has nothing to do with XML
so of course it's not valid XML!

> Is it possible to add this feature in a future version ? (with <TMPL_VAR
>  > still possible to avoid rewritting all templates, of course)

You can do it yourself with a filter.  Something like (untested):

  sub allow_trailing_slash {
     my $text = shift;
     $$text =~ m!(<tmpl_[^>]*)/>!$1>!g;
  }

  $t = HTML::Template->new(filter => \&allow_trailing_slash, ...);

-sam

RE: :T future (was Re: [htmltmpl] xml complant tags)

[Paulsen, B. <BPa...@le...>]

I think a few bug fixes and performance tweaks have been offered.  Other
than that, I agree with your assessment - it is near perfect.

What surprises me is how few people know about it.  I have a copy of the
"Perl Black Book" and the second edition of the "Perl Cookbook".  Neither
one mentions HTML::Template in the discussion of HTML templating solutions.

Brian


-----Original Message-----
From: htm...@li...
[mailto:htm...@li...] On Behalf Of Puneet
Kishor
Sent: Monday, December 08, 2003 5:49 PM
To: htm...@li...
Subject: H::T future (was Re: [htmltmpl] xml complant tags)


Paulsen, Brian wrote:

..
> And, given how frequent H::T gets updated, it would be a MUCH quicker 
> solution.
> 
..

speaking of which, I have often wondered what could be improved in H-T, 
and have failed to come up with anything. It just seems to be that 
perfect program that does perfectly what it said to do. Simple to 
install and understand, well-documented, and fast. In fact, imho, it 
should be made a core part of Perl as is CGI.pm.

But, since not being able to visualize the form of H-T's future might be 
due to my lack of imagination, I am curious -- what are the ways in 
which the developer-kind want to see H-T to be in a few years/versions 
or so...



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Html-template-users mailing list Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users



------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the
designated recipient(s) named above.  If you are not the intended recipient of
this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited.  This
communication is for information purposes only and should not be regarded as
an offer to sell or as a solicitation of an offer to buy any financial
product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers.  Email transmission cannot be guaranteed to be
secure or error-free.  Therefore, we do not represent that this information is
complete or accurate and it should not be relied upon as such.  All
information is subject to change without notice.

H::T future (was Re: [htmltmpl] xml complant tags)

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

Paulsen, Brian wrote:

..
> And, given how frequent H::T gets updated, it would be a MUCH quicker
> solution.
> 
..

speaking of which, I have often wondered what could be improved in H-T, 
and have failed to come up with anything. It just seems to be that 
perfect program that does perfectly what it said to do. Simple to 
install and understand, well-documented, and fast. In fact, imho, it 
should be made a core part of Perl as is CGI.pm.

But, since not being able to visualize the form of H-T's future might be 
due to my lack of imagination, I am curious -- what are the ways in 
which the developer-kind want to see H-T to be in a few years/versions 
or so...

RE: [htmltmpl] xml complant tags

[Paulsen, B. <BPa...@le...>]

Alternatively, it wouldn't be too difficult to write a filter function that
would transform a template with a trailing slash to one that H::T would
understand.

And, given how frequent H::T gets updated, it would be a MUCH quicker
solution.

Brian

-----Original Message-----
From: Mathew Robertson [mailto:mat...@re...] 
Sent: Monday, December 08, 2003 5:21 PM
To: htm...@li...
Subject: Re: [htmltmpl] xml complant tags

In any case, it wouldn't be too hard to change H::T to optionally support
the trailing slash.

regards,
Mathew


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Html-template-users mailing list Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users

------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the
designated recipient(s) named above.  If you are not the intended recipient of
this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited.  This
communication is for information purposes only and should not be regarded as
an offer to sell or as a solicitation of an offer to buy any financial
product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers.  Email transmission cannot be guaranteed to be
secure or error-free.  Therefore, we do not represent that this information is
complete or accurate and it should not be relied upon as such.  All
information is subject to change without notice.

Re: [htmltmpl] xml complant tags

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

> For instance, h::t tags are not html valid <TMPL_VAR name=3D"X"> is =
NOT=20
> valid. It should be : <TMPL_VAR name=3D"X"/>.
> Same thing for <TMPL_ELSE> :
> <TMPL_IF name=3D"x">
> ...
> <TMPL_ELSE/>
> ...
> </TMPL_IF>
> would be valid.

> Is it possible to add this feature in a future version ? (with =
<TMPL_VAR=20
>  > still possible to avoid rewritting all templates, of course)

> Note : the Koha project uses H::T, i'm writting a "translator tool" =
with=20
> HTML::TreeBuilder, and TreeBuilder is a little bit lost with =
<tmpl_else>=20
> & <tmpl_var>

In that case, I would say that HTML::TreeBuilder is the one that is =
broken in that it doesn't support HTML 4 transitional markup.

In any case, it wouldn't be too hard to change H::T to optionally =
support the trailing slash.

regards,
Mathew