This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From the mod_perl list:
Subject: Re: Template techniques
From: "Andy Wardley" <abw@cre.canon.co.uk>
Date: Fri, 9 Jun 2000 14:58:24 +0100
On Jun 8, 1:56pm, Perrin Harkins wrote:
> Not quite. The current version uses its own system of opcodes (!) which
> are implemented as closures. Compiling to perl code gives much better
> performance, which is why Andy is changing this.
Yep, Perrin's right. Version 1 compiled templates to tree form. Items
in the tree were scalars (plain text) or references to directive objects
which performed some processing (like INCLUDE another template, and so
on).
This is actually pretty efficient when you have a limited directive set,
but doesn't scale very well. For version 1.00 I was more concerned
about getting it functioning correctly than running fast (it was already
an order of magnitude or two faster than Text::MetaText, the predecessor,
so I was happy). Also it was much easier to develop and evolve the toolkit
with the tree-form architecture than when compiling to Perl, so it had some
hidden benefit.
But the current alpha version of 2.00 compiles templates to Perl code. A
template like this:
[% INCLUDE header
title = "This is a test"
%]
Blah Blah Blah [% foo %]
[% INCLUDE footer %]
is compiled to something resembling
sub {
my $context = shift;
my $stash = $context->stash();
my $output = '';
$output .= $context->include('header', { title => 'This is a test' });
$output .= "\nBlah Blah Blah ";
$output .= $stash->get('foo');
return $output;
}
Apart from the benefits of speed, this also means that you can cache
compiled templates to disk (i.e. write the Perl to a file). Thus you
can run a web server directly from template components compiled to Perl
and you don't even need to load the template parser. Ideally, it should
be possible to integrate compiled TT templates with Mason components
and/or any other template form which gets compiled to Perl.
===
Subject: [OT now] Re: Template techniques
From: Drew Taylor <dtaylor@vialogix.com>
Date: Fri, 09 Jun 2000 13:20:34 -0400
I was wondering if anyone had done comparisions between some of the
major templating engines. I'm thinking specifically of Template Toolkit,
Mason, HTML::Template, and EmbPerl. I currently use HTML::Template, and
am happy with it. But I am always open to suggestions.
I really like the fact that templates can be compiled to perl code &
cached. Any others besides Mason & EmbPerl (and TT in the near future)?
===
Subject: Re: [OT now] Re: Template techniques
From: Perrin Harkins <perrin@primenet.com>
Date: Fri, 9 Jun 2000 14:05:12 -0700 (PDT)
On Fri, 9 Jun 2000, Drew Taylor wrote:
> I really like the fact that templates can be compiled to perl code &
> cached. Any others besides Mason & EmbPerl (and TT in the near future)?
Sure: Apache::ePerl, Apache::ASP, Text::Template, and about a million
unreleased modules that people wrote for their own use. (I think writing
a module that does this should be a rite of passage in Perl hacking.)
===
Subject: Templating system
From: Darko Krizic <DKrizic@ProDyna.de>
Date: Thu, 27 Jul 2000 11:26:45 +0200
I want to write a new application using mod_perl but this time I want to
completely divide the code from the HTML. Therefore I am seeking for a
powerfull and fast templating system.
Newly I did something with Enhydra (Java Servlets) and they have a pretty
neat templating system: They use standard HTML and one uses the "id"
attribute in HTML tags to access them and manipulate values/contents. For
example:
<table id="results">
<tr id="resultheader">
<th>Name</th>
<th>Count</th>
</tr>
<tr id="singlerow>
<td id="row_name">example name</td>
<td id="row_count">example count</td>
</tr>
</table>
The program now can repeat the tr "singlerow" for each table row and insert
it under the tr "resultheader". The values can be inserted into the tds
"row_name" and "row_count". The main advantage is: The designer can generate
HTML pages that can be viewed with a standard browser.
Does anybody know something similar for Perl?
===
Subject: Re: Templating system
From: Matt Sergeant <matt@sergeant.org>
Date: Thu, 27 Jul 2000 10:29:50 +0100 (BST)
On Thu, 27 Jul 2000, Darko Krizic wrote:
> I want to write a new application using mod_perl but this time I want to
> completely divide the code from the HTML. Therefore I am seeking for a
> powerfull and fast templating system.
>
> Newly I did something with Enhydra (Java Servlets) and they have a pretty
> neat templating system: They use standard HTML and one uses the "id"
> attribute in HTML tags to access them and manipulate values/contents. For
> example:
>
> <table id="results">
> <tr id="resultheader">
> <th>Name</th>
> <th>Count</th>
> </tr>
> <tr id="singlerow>
> <td id="row_name">example name</td>
> <td id="row_count">example count</td>
> </tr>
> </table>
>
> The program now can repeat the tr "singlerow" for each table row and insert
> it under the tr "resultheader". The values can be inserted into the tds
> "row_name" and "row_count". The main advantage is: The designer can generate
> HTML pages that can be viewed with a standard browser.
>
> Does anybody know something similar for Perl?
No, but I was thinking of incorporating enhydra's XMLC technology into
AxKit. I'm not sure its a better method of working than XSLT or
XPathScript though, which allows you to be future looking (always
XML). But it could be kinda neat to do. Should be almost trivial with
HTML::Parser to generate perl out of that. Providing of course they don't
have some stupid patent on it (doubtful since its GPL'd).
Can you wait, or do you need something now?
===
Subject: Re: Templating system
From: David Hodgkinson <daveh@hodgkinson.org>
Date: 27 Jul 2000 10:38:02 +0100
Darko Krizic <DKrizic@ProDyna.de> writes:
> The program now can repeat the tr "singlerow" for each table row and insert
> it under the tr "resultheader". The values can be inserted into the tds
> "row_name" and "row_count". The main advantage is: The designer can generate
> HTML pages that can be viewed with a standard browser.
>
> Does anybody know something similar for Perl?
Hmmm. Depends what you mean. I think in your context, the Template
Toolkit has many more obvious tags that will litter themselves in the
HTML. However, using includes and macros effectively you reduce the
amount of cruft in the code.
Dave // Currently boring for England on the subject of the TT.
===
Subject: RE: Templating system
From: Darko Krizic <DKrizic@ProDyna.de>
Date: Thu, 27 Jul 2000 11:55:04 +0200
Newly I did something with Enhydra (Java Servlets) and they
> have a pretty
> > neat templating system: They use standard HTML and one uses the "id"
> > attribute in HTML tags to access them and manipulate
> values/contents.
> > [...]
> > Does anybody know something similar for Perl?
>
> No, but I was thinking of incorporating enhydra's XMLC technology into
> AxKit. I'm not sure its a better method of working than XSLT or
> XPathScript though, which allows you to be future looking (always
> XML). But it could be kinda neat to do. Should be almost trivial with
> HTML::Parser to generate perl out of that. Providing of
> course they don't
> have some stupid patent on it (doubtful since its GPL'd).
>
> Can you wait, or do you need something now?
As you know projects must be finished until yesterday. It would be a dream
if we could share the templates between Enhydra and Perl. The only problem I
see here is the performance. Enhydra compiles the java and the HTML pages
and creates methods and a DOM model. Doing this on the fly (for mod_perl)
would be a big drawback in performance. Maybe there should be some kind of
precompiling.
How long do you think would this last? I could wait for about 3 hours or so
;-)
The problem with many templating systems is the fact that they invent a new
language like "<td>$variable</td>" which is usually not displayable in the
Browser so that the designer and the programmer must work tightly.
What other templating systems do exists that are usefull?
===
Subject: Re: Templating system
From: David Hodgkinson <daveh@hodgkinson.org>
Date: 27 Jul 2000 10:52:08 +0100
Darko Krizic <DKrizic@prodyna.de> writes:
> What is the Template Toolkit?
www.template-toolkit.org
===
Subject: RE: Templating system
From: Matt Sergeant <matt@sergeant.org>
Date: Thu, 27 Jul 2000 10:58:51 +0100 (BST)
On Thu, 27 Jul 2000, Darko Krizic wrote:
> > > Newly I did something with Enhydra (Java Servlets) and they
> > have a pretty
> > > neat templating system: They use standard HTML and one uses the "id"
> > > attribute in HTML tags to access them and manipulate
> > values/contents.
> > > [...]
> > > Does anybody know something similar for Perl?
> >
> > No, but I was thinking of incorporating enhydra's XMLC technology into
> > AxKit. I'm not sure its a better method of working than XSLT or
> > XPathScript though, which allows you to be future looking (always
> > XML). But it could be kinda neat to do. Should be almost trivial with
> > HTML::Parser to generate perl out of that. Providing of
> > course they don't
> > have some stupid patent on it (doubtful since its GPL'd).
> >
> > Can you wait, or do you need something now?
>
> As you know projects must be finished until yesterday. It would be a dream
> if we could share the templates between Enhydra and Perl. The only problem I
> see here is the performance. Enhydra compiles the java and the HTML pages
> and creates methods and a DOM model. Doing this on the fly (for mod_perl)
> would be a big drawback in performance. Maybe there should be some kind of
> precompiling.
>
> How long do you think would this last? I could wait for about 3 hours or so
> ;-)
Well... longer than that. But even if I wrote something this afternoon -
you still wouldn't learn it very quickly.
> The problem with many templating systems is the fact that they invent a new
> language like "<td>$variable</td>" which is usually not displayable in the
> Browser so that the designer and the programmer must work tightly.
Thats a problem with _all_ template systems, including XMLC. With XMLC's
method you still have problems with bits that get conditionally
included. Sure, looping rows of tables look good, but wait until you start
using XMLC a lot. Then you'll find the flaws.
Better to start with a standard that you can build on, like XSLT, IMHO.
> What other templating systems do exists that are usefull?
Thats a huge question, here's a few:
EmbPerl
Template Toolkit
Apache::ASP
HTML::Template
XSLT
XPathScript (part of AxKit, which can also do XSLT)
Mason
I've probably offended some people by ommiting some :-)
===
Subject: Re: Templating system
From: David Hodgkinson <daveh@hodgkinson.org>
Date: 27 Jul 2000 10:55:20 +0100
Darko Krizic <DKrizic@ProDyna.de> writes:
> As you know projects must be finished until yesterday. It would be a dream
> if we could share the templates between Enhydra and Perl. The only problem I
> see here is the performance. Enhydra compiles the java and the HTML pages
> and creates methods and a DOM model. Doing this on the fly (for mod_perl)
> would be a big drawback in performance. Maybe there should be some kind of
> precompiling.
Smart templaters cache templates and results. The REALLY smart ones
compile the templates into perl code and hold them as a reference to
an anonymous sub.
> The problem with many templating systems is the fact that they invent a new
> language like "<td>$variable</td>" which is usually not displayable in the
> Browser so that the designer and the programmer must work tightly.
Read Andy Wardley's paper on www.template-toolkit.org. He talks about
its positioning between the programmer and designer.
For the record, I've just done a by-the-book mod_perl-ed Template
thing and it's very quick. I'll be doing a lot more on deep-purple.com
very soon.
===
Subject: RE: Templating system
From: Darko Krizic <DKrizic@ProDyna.de>
Date: Thu, 27 Jul 2000 12:16:09 +0200
How long do you think would this last? I could wait for
> about 3 hours or so
> > ;-)
>
> Well... longer than that. But even if I wrote something this
> afternoon -
> you still wouldn't learn it very quickly.
No stress here please. If you do something then send it to me and I will
take a closer look at it.
> > The problem with many templating systems is the fact that
> they invent a new
> > language like "<td>$variable</td>" which is usually not
> displayable in the
> > Browser so that the designer and the programmer must work tightly.
>
> Thats a problem with _all_ template systems, including XMLC.
> With XMLC's
> method you still have problems with bits that get conditionally
> included. Sure, looping rows of tables look good, but wait
> until you start
> using XMLC a lot. Then you'll find the flaws.
As I said: One problem with enhydra is that the id "x" is a <tr>.
> Better to start with a standard that you can build on, like
> XSLT, IMHO.
Sure.
> > What other templating systems do exists that are usefull?
>
> Thats a huge question, here's a few:
>
> EmbPerl -> mixing of HTML and logic
> Template Toolkit -> will take a look at it right now
> Apache::ASP -> nice (session management), but still mixing
> HTML::Template -> own language
> XSLT
> XPathScript (part of AxKit, which can also do XSLT) -> will take a look at
AxKit
> Mason -> AFAIK mixing
Comments start with ->
===
Subject: Re: Templating system
From: Joshua Chamas <joshua@chamas.com>
Date: Thu, 27 Jul 2000 03:26:02 -0700
Darko Krizic wrote:
>
> > > What other templating systems do exists that are usefull?
> >
> > Thats a huge question, here's a few:
> >
> > EmbPerl -> mixing of HTML and logic
> > Template Toolkit -> will take a look at it right now
> > Apache::ASP -> nice (session management), but still mixing
> > HTML::Template -> own language
> > XSLT
> > XPathScript (part of AxKit, which can also do XSLT) -> will take a look at
> AxKit
> > Mason -> AFAIK mixing
>
> Comments start with ->
>
I saw your note about Apache::ASP mixing...
with Apache::ASP a lead site engineer can define custom tags
with XMLSubsMatch that will make XML tags execute
as perl subs, check out: http://www.nodeworks.com/asp/xml.html
You could define a tag like
<my:bigtable>LOTS of BIG TEXT</my:bigtable>
and the site engineer could define the sub to handle
it like:
sub my::bigtable {
my($args, $text) = @_;
print "<table heigth=100% width=100%><tr><td><font size=+5>$text</font></td></td></table>";
}
Apache::ASP thus allows you to create your own set of
tags to lose the code mixing which is the bane of many
a web designer.
===
Subject: RE: Templating system
From: Darko Krizic <DKrizic@ProDyna.de>
Date: Thu, 27 Jul 2000 12:56:52 +0200
Apache::ASP -> nice (session management), but still mixing
> I saw your note about Apache::ASP mixing...
> with Apache::ASP a lead site engineer can define custom tags
> with XMLSubsMatch that will make XML tags execute
> as perl subs, check out: http://www.nodeworks.com/asp/xml.html
> Apache::ASP thus allows you to create your own set of
> tags to lose the code mixing which is the bane of many
> a web designer.
Sorry for my note. The last version of Apache::ASP I used was about 1.0 I
think. I don't know the new features of Apache::ASP.
I like Apache::ASP, it is implemented well and is the best tool for writing
some code that requires lots of interaction (forms and so), mainly because
of the transparent Session Management. I used to write ASP under IIS with VB
so I like to concept of Apache::ASP (especially because there is Perl
inside).
===
Subject: Re: Templating System
From: Roger Espel Llima <espel@iagora.net>
Date: Thu, 27 Jul 2000 12:57:32 +0200
Darko Krizic <DKrizic@ProDyna.de> wrote:
> ...
> <table id="results">
> <tr id="resultheader">
> <th>Name</th>
> <th>Count</th>
> </tr>
> <tr id="singlerow>
> <td id="row_name">example name</td>
> <td id="row_count">example count</td>
> </tr>
> </table>
> ...
> The problem with many templating systems is the fact that they invent a new
> language like "<td>$variable</td>" which is usually not displayable in the
> Browser so that the designer and the programmer must work tightly.
The designer has to learn 'id="row_name"' in one case, and $row_name in
the other. I'd say that the need to work tightly with the programmer is
pretty much the same: you have to agree on a syntax for gaps that code
can fill, and on the names of the individual gaps.
> What other templating systems do exists that are usefull?
There is a real plethora of templating modules: the Template Toolkit,
HTML::Mason, HTML::DynamicTemplate, Text::TagTemplate and HTML::Template
can all do things like these.
They often differ in the calling approach: does the URL map to a script
which inits and calls a template object giving it values, or does the
URL map to the final template, which calls perl code to fill the gaps?
Within this there are many approaches too, different ways to draw the
line between what goes in the perl and what goes in the template, and
what kind of object model (if any) they implement.
I'm just about to release (next week) a templating/content-handling
module for mod_perl, called iAct, which takes the approach that URLs map
to template files, which call perl if they want, but then the perl code
can also manipulate templates and sections. I'm not saying this is
necessarily the most appropriate for you, just letting people know about
it :)
Under iAct, you'd do it like this:
<table>
<tr>
<th>Name</th>
<th>Count</th>
</tr>
<% section "one_row" %>
<tr>
<td><$ row_name $>
<td><$ row_count $>
</tr>
<% /section %>
<% call sub="Your::Module::fill_rows" repeat="one_row" %>
</table>
and the code for Your::Module::fill_rows would be something like:
sub fill_rows {
my ($self, $args) = @_;
my ($sec, $ret) = ($args->{repeat}, "");
foreach my $nc (&get_name_counts()) {
$self->assign_raw(row_name => $nc->[0],
row_count => $nc->[1]);
$ret .= $self->fetch($sec);
}
$ret;
}
===
Subject: RE: Templating System
From: Darko Krizic <DKrizic@ProDyna.de>
Date: Thu, 27 Jul 2000 13:28:06 +0200
Darko Krizic <DKrizic@ProDyna.de> wrote:
> > ...
> > <table id="results">
> > <tr id="resultheader">
> > <th>Name</th>
> > <th>Count</th>
> > </tr>
> > <tr id="singlerow>
> > <td id="row_name">example name</td>
> > <td id="row_count">example count</td>
> > </tr>
> > </table>
> > ...
> > The problem with many templating systems is the fact that
> they invent a new
> > language like "<td>$variable</td>" which is usually not
> displayable in the
> > Browser so that the designer and the programmer must work tightly.
>
> The designer has to learn 'id="row_name"' in one case, and
> $row_name in
> the other. I'd say that the need to work tightly with the
> programmer is
> pretty much the same: you have to agree on a syntax for gaps that code
> can fill, and on the names of the individual gaps.
There is one big difference in the enhydra approach: The templates are
standard HTML, because the id tag is part of the HTML standard. The designer
can create the whole site and make a dry test, because all links even work.
The tags (with ids) can contain valid values.
===
Subject: Re: Templating System
From: JoshNarins@aol.com
Date: Thu, 27 Jul 2000 07:51:58 EDT
In a message dated 7/27/00 7:21:04 AM Eastern Daylight Time,
DKrizic@ProDyna.de writes:
<< There is one big difference in the enhydra approach: The templates are
standard HTML, because the id tag is part of the HTML standard. The designer
can create the whole site and make a dry test, because all links even work.
The tags (with ids) can contain valid values.
...darko >>
I hear you, yet I also know that the ID= tags are valid CSS. You are going to
screw
yourself up one way or the other with that.
For instance...
<STYLE>
TD {color: red;}
.oneTD { color: yellow }
</STYLE>
Now, your TD cells are going to get the red (assuming you aren't using
Netscape's
broken CSS). But how could you force one cell to get the yellow?
The normal way to do it would be
<TD ID="oneTD"> but you have already used up your ID tag.
Tell me if I am missing something.
===
Subject: Re: Templating System
From: Matt Sergeant <matt@sergeant.org>
Date: Thu, 27 Jul 2000 13:02:08 +0100 (BST)
On Thu, 27 Jul 2000 JoshNarins@aol.com wrote:
> I hear you, yet I also know that the ID= tags are valid CSS. You are going to
> screw
> yourself up one way or the other with that.
>
> For instance...
> <STYLE>
> TD {color: red;}
> .oneTD { color: yellow }
> </STYLE>
>
> Now, your TD cells are going to get the red (assuming you aren't using
> Netscape's
> broken CSS). But how could you force one cell to get the yellow?
> The normal way to do it would be
> <TD ID="oneTD"> but you have already used up your ID tag.
>
> Tell me if I am missing something.
The CLASS attribute.
===
Subject: Re: Templating System
From: Joshua Chamas <joshua@chamas.com>
Date: Thu, 27 Jul 2000 05:16:28 -0700
If you want a modperl based enhydra like system, check
out http://www.best.com/~pjl/software/html_tree/
by Paul J. Lucas, who tends to write incredibly fast
software, like his Swish++
http://www.best.com/~pjl/software/swish/
===
Subject: Fwd: Templating System
From: JoshNarins@aol.com
Date: Thu, 27 Jul 2000 08:33:46 EDT
In a message dated 7/27/00 7:57:16 AM Eastern Daylight Time,
matt@sergeant.org writes:
> On Thu, 27 Jul 2000 JoshNarins@aol.com wrote:
> > For instance...
> > <STYLE>
> > TD {color: red;}
> > .oneTD { color: yellow }
> > </STYLE>
> >
> > Now, your TD cells are going to get the red (assuming you aren't using
> > Netscape's
> > broken CSS). But how could you force one cell to get the yellow?
> > The normal way to do it would be
> > <TD ID="oneTD"> but you have already used up your ID tag.
> >
> > Tell me if I am missing something.
>
> The CLASS attribute.
Well, that takes care of the simple cases.
It's just simply bad style to name a fake attribute the same
as a preexisting real attribute.
And sometimes the tag already has a CLASS and the person is
using ID to override some aspects of the CLASS. That's what
it is there for.
-JoshNarins
PS The thing I thought I might be missing might have to do
with the ID tags after the preprocessor is done with
them. For instance, if the user has two ID tags, the first
one might get preprocessed, the second left for CSS.
===
Subject: Re: Templating System
From: Roger Espel Llima <espel@iagora.net>
Date: Thu, 27 Jul 2000 14:56:20 +0200
On Thu, Jul 27, 2000 at 01:28:06PM +0200, Darko Krizic wrote:
> There is one big difference in the enhydra approach: The templates are
> standard HTML, because the id tag is part of the HTML standard. The
> designer can create the whole site and make a dry test, because all
> links even work. The tags (with ids) can contain valid values.
That is neat :)
However, I contend that designers should be testing against a test
server, not their local hard drives, in which case the obvious thing to
do is put the templating engine on the test server (without the
app-specific perl code).
The advantage of this becomes obvious when you start using templating
techniques to share html code among pages: design bits, common
navigation for the site, for parts of the site, etc. Then the plain
files for each of the pages can't be used statically for a "dry test"
anymore.
===
Subject: Re: Templating System
From: "Ken Y. Clark" <kclark@boston.com>
Date: Thu, 27 Jul 2000 09:18:38 -0400 (EDT)
On Thu, 27 Jul 2000, Roger Espel Llima wrote:
> On Thu, Jul 27, 2000 at 01:28:06PM +0200, Darko Krizic wrote:
> > There is one big difference in the enhydra approach: The templates are
> > standard HTML, because the id tag is part of the HTML standard. The
> > designer can create the whole site and make a dry test, because all
> > links even work. The tags (with ids) can contain valid values.
i know it's already been mentioned in this thread in passing, but i'd like
to stress how easy i've found it is to work with HTML::Template. the
templates are straight HTML w/obvious and easy-to-work-with template tags
embedded, like so:
<html>
<head>
<title> ABC, Co. Website </title>
</head>
<body>
<h1> ABC, Co. Website </h1>
<hr>
Welcome, <tmpl_var name=customer_name>.
<p>
asdf asdf adsf asdf asdf asdf asdf afs asdf asdf asdf asdf
</p>
<p>
<tmpl_if name=print_data>
<table>
<tr>
<th> First Col </th>
<th> Second Col </th>
</tr>
<tmpl_loop name=data>
<tr>
<td> <tmpl_var name=column_one> </td>
<td> <tmpl_var name=column_two> </td>
</tr>
</tmpl_loop>
</table>
<tmpl_else>
I'm sorry, but no data was returned.
</tmpl_if>
</p>
</body>
</html>
that's a simple example, but you can see that you have some rudimentary
control structures (if, loop) and simple variable substitution. the perl
code controlling it can be fairly lightweight, too.
my $sth = $db->prepare($sql);
$sth->execute;
my (@data, $hashref);
push @data, $hashref while $hashref = $sth->fetchrow_hashref;
my $t = HTML::Template->new(filename => '/path/to/templates/foo.tmpl');
$t->param('customer_name' => 'Tom Jones',
'print_data' => (@data) ? 1 : 0,
'data' => \@data);
$r->print($t->output);
HTML::Template may not solve all your problems, but if you need something
quick, i think it's a pretty good solution.
ky
===
Subject: Re: Templating system
From: Drew Taylor <dtaylor@vialogix.com>
Date: Thu, 27 Jul 2000 09:38:22 -0400
David Hodgkinson wrote:
>
> Darko Krizic <DKrizic@ProDyna.de> writes:
>
> > As you know projects must be finished until yesterday. It would be a dream
> > if we could share the templates between Enhydra and Perl. The only problem I
> > see here is the performance. Enhydra compiles the java and the HTML pages
> > and creates methods and a DOM model. Doing this on the fly (for mod_perl)
> > would be a big drawback in performance. Maybe there should be some kind of
> > precompiling.
>
> Smart templaters cache templates and results. The REALLY smart ones
> compile the templates into perl code and hold them as a reference to
> an anonymous sub.
>
> > The problem with many templating systems is the fact that they invent a new
> > language like "<td>$variable</td>" which is usually not displayable in the
> > Browser so that the designer and the programmer must work tightly.
>
> Read Andy Wardley's paper on www.template-toolkit.org. He talks about
> its positioning between the programmer and designer.
>
> For the record, I've just done a by-the-book mod_perl-ed Template
> thing and it's very quick. I'll be doing a lot more on deep-purple.com
> very soon.
As have I. :-) Modifying the existing modules to use Template Toolkit
instead of HTML::Template (A great module for simpler tasks than what we
were doing) and redoing the whole site (about 25 _very_ dynamic pages)
took a month. Of course, we were killing ourselves to make that
deadline, but the point is that Template Toolkit is great! I can't wait
for version 2 to come out...
===
Subject: Re: Templating System
From: Kenneth Lee <kenneth.lee@alfacomtech.com>
Date: Thu, 27 Jul 2000 21:54:13 +0800
My ideal system would be those the designer can see the server-side
objects and data fields in the database, and only associate them with
the template by drag-n-drop.
The designer doesn't sees any special tags, and doesn't have to conform
to those "variables" with the programmer. The associations can be done by
the programmer too, and he can also be isolated from the HTML codes.
Just like those commercial application servers available on the net, but
I think no one would choose (mod)perl as the API/platform.
If there're any comparable large scale application server based on Perl,
I would like to hear about that. Some would say Perl is not good as
Java/C/C++ in doing that, but I think we can have the core written in C/C++
and use Perl as a glue between the developer and the system.
Just my daylight dreaming....
(I hear someone is saying "bull s**t!")
===
Subject: Re: Templating System
From: Matt Sergeant <matt@sergeant.org>
Date: Thu, 27 Jul 2000 15:02:11 +0100 (BST)
On Thu, 27 Jul 2000, Kenneth Lee wrote:
> My ideal system would be those the designer can see the server-side
> objects and data fields in the database, and only associate them with
> the template by drag-n-drop.
> The designer doesn't sees any special tags, and doesn't have to conform
> to those "variables" with the programmer. The associations can be done by
> the programmer too, and he can also be isolated from the HTML codes.
>
> Just like those commercial application servers available on the net, but
> I think no one would choose (mod)perl as the API/platform.
> If there're any comparable large scale application server based on Perl,
> I would like to hear about that. Some would say Perl is not good as
> Java/C/C++ in doing that, but I think we can have the core written in C/C++
> and use Perl as a glue between the developer and the system.
One of the larger vendors that most people haven't heard of is
mediasurface. Their whole system is just a perl httpd server. And I've
heard that Vignette is written in Perl (or was).
===
Subject: Re: Templating System
From: "Erich L. Markert" <emarkert@pace.edu>
Date: Thu, 27 Jul 2000 10:00:30 -0400
OK, I'm nearing the end of one project so I'm able to take a look at new
solutions so one question comes to mind. What does the template toolkit
offer above and beyond HTML::Embperl or some other templating solution?
On a side note, wouldn't the mod_perl community be better served
focusing on one of these solutions and building upon it and creating a
mod_perl based application server much like Python has Zope?
===
Subject: Re: Templating system
From: Christian Jaeger <christian.jaeger@sl.ethz.ch>
Date: Thu, 27 Jul 2000 16:20:09 +0200
At 11:26 Uhr +0200 27.7.2000, Darko Krizic wrote:
>Newly I did something with Enhydra (Java Servlets) and they have a pretty
...
>Does anybody know something similar for Perl?
I have lately written my own templating scheme, which is part of my
framework running on top of fastcgi (including transparent session
handling, too; see http://testwww.ethz.ch/eile/). Some days ago I looked at
Enhydra, too, and found it very similar to my approach (in the idea, not
the implementation).
Some words about my approach:
- it uses '$var' style variable substitution, curly quotes to markup parts
to be accessed as a whole, and additionally it offers methods to access
table rows, and to fill in form fields (which are recognized by the 'name'
attribute).
- additionally it offers some 'high level' methods, like filling a table
and reordering columns on the fly, or automatically copy all params from a
previous form post into the template again (i.e. for showing the user a
form again 'you have made a mistake .. please post again').
- it mainly uses perl regexps to fill in the data (exception: the table
handler compiles perl code on the fly, which makes it very fast). It's
really fast enough for me.
- it handles automatic html escaping where needed (with some possibility to
customize)
- all relevant links are rewritten automatically to include the session id
(transparent URL rewriting)
The framework is based on fastcgi, and the Html.pm module is in some points
integrated to the whole thing (sessions, caching). Contact me if you really
want to port it..
I wrote my own thing because I was too impatient to learn the details of
Apache::ASP.. :-) (and when I started my development mod_perl was not that
wide spread like today, fastcgi was promising)
The only thing I miss currently is a smart way to map variables to the
template parts so I don't handle dozens of variables or hash fields all the
time. (Some module/class to provide a simple way of
database--application--template data traffic.)
===
Subject: Re: Templating System
From: Alex Shnitman <alexs@livelinx.com>
Date: Thu, 27 Jul 2000 17:22:26 +0300
On Thu, Jul 27, 2000 at 10:00:30AM -0400, Erich L. Markert wrote:
> On a side note, wouldn't the mod_perl community be better served
> focusing on one of these solutions and building upon it and creating a
> mod_perl based application server much like Python has Zope?
A similar project is underway by members of the Israeli Linux Users
Group, and some others:
http://gamla.iglu.org.il/
(This project could use some new blood, please join the mailing list
if you are interested!)
===
Subject: Re: Templating System
From: Ian Kallen <spidaman@salon.com>
Date: Thu, 27 Jul 2000 07:26:26 -0700 (PDT)
I'm not going to disparage any of the other templating systems but since
noone has chimed in for HTML::Mason, I guess I'll have to. Important
aspects of such a beast is componentization, not just "mail merge"
behaviors.
Mason components can be just HTML (or XML or fooML) or just Perl or both.
The "heavy lifting" can be moved to the bottom of a page so you can get
away from top to bottom processing whih generall demands expressing
complex code in the middle of HTML. Caching by distilling components down
into Perl code. In many other respects, the API, the execution and the
object models are the most empowering.
My current focus is on using Mason as a component system but XSLT when I
need ad-hoc transformation a la AxKit, Cocoon and other XSLT
processor-based systems. Mixing AxKit and Mason may sound crazy but each
has compelling ideas in their architecture.
As far getting Zopely with mod_perl tools, in my talk in the Apache track
about the publishing and content management at Salon I discussed getting
there last week in Monterey.
===
Subject: Re: Templating System
From: Matt Sergeant <matt@sergeant.org>
Date: Thu, 27 Jul 2000 15:49:03 +0100 (BST)
On Thu, 27 Jul 2000, Erich L. Markert wrote:
> OK, I'm nearing the end of one project so I'm able to take a look at new
> solutions so one question comes to mind. What does the template toolkit
> offer above and beyond HTML::Embperl or some other templating solution?
It implements some wacky non-perl language, which might be great for
template developers. Thats what I gathered from the TT BOF anyway... :)
> On a side note, wouldn't the mod_perl community be better served
> focusing on one of these solutions and building upon it and creating a
> mod_perl based application server much like Python has Zope?
As I said to people at TPC: Come to ApacheCon Europe, I'll have something
to show you then (hopefully).
===
Subject: Re: Templating system
From: "Paul J. Lucas" <pjl@barefooters.org>
Date: Thu, 27 Jul 2000 08:54:43 -0700 (PDT)
On Thu, 27 Jul 2000, Darko Krizic wrote:
> I want to write a new application using mod_perl but this time I want to
> completely divide the code from the HTML. Therefore I am seeking for a
> powerfull and fast templating system.
http://www.best.com/~pjl/software/html_tree/
It does precisely what you're asking.
- Paul
===
Subject: RE: Templating system
From: "Paul J. Lucas" <pjl@barefooters.org>
Date: Thu, 27 Jul 2000 08:57:56 -0700 (PDT)
On Thu, 27 Jul 2000, Darko Krizic wrote:
> The only problem I see here is the performance. Enhydra compiles the java and
> the HTML pages and creates methods and a DOM model. Doing this on the fly
> (for mod_perl) would be a big drawback in performance. Maybe there should be
> some kind of precompiling.
My HTML Tree method (previously gave the URL) is several times
faster than conventional DOM parsers. Among other things, it
uses mmap(2) to read files and, by definition, you can't get
faster I/O.
- Paul
===
Subject: Re: Templating system
From: "Jeffrey W. Baker" <jwbaker@acm.org>
Date: Thu, 27 Jul 2000 09:10:57 -0700 (PDT)
On Thu, 27 Jul 2000, Paul J. Lucas wrote:
> On Thu, 27 Jul 2000, Darko Krizic wrote:
>
> > I want to write a new application using mod_perl but this time I want to
> > completely divide the code from the HTML. Therefore I am seeking for a
> > powerfull and fast templating system.
>
> http://www.best.com/~pjl/software/html_tree/
>
> It does precisely what you're asking.
Hey, that's really nice. And once the template HTML files are parsed, I
can just leave the $root_node in memory for future requests, right? ANd
since the parser isn't validating, I can extend HTML with tags like
<NODE>, <BANNER>, and <WHATEVER>, right?
Pant, pant.
===
Subject: Re: Templating System
From: Mark Hughes <mark@ismltd.com>
Date: Thu, 27 Jul 2000 17:20:31 +0100
One of the larger vendors that most people haven't heard of is
> mediasurface. Their whole system is just a perl httpd server. And I've
> heard that Vignette is written in Perl (or was).
>
Unfortunately not, TCL, and painful it is ...
===
Subject: Re: Templating System
From: Barry Hoggard <barry@investorama.com>
Date: Thu, 27 Jul 2000 12:46:01 -0400
At 07:26 AM 7/27/00 -0700, Ian Kallen wrote:
>I'm not going to disparage any of the other templating systems but since
>noone has chimed in for HTML::Mason, I guess I'll have to. Important
>aspects of such a beast is componentization, not just "mail merge"
>behaviors.
>
>Mason components can be just HTML (or XML or fooML) or just Perl or both.
>The "heavy lifting" can be moved to the bottom of a page so you can get
>away from top to bottom processing whih generall demands expressing
>complex code in the middle of HTML. Caching by distilling components down
>into Perl code. In many other respects, the API, the execution and the
>object models are the most empowering.
>
>My current focus is on using Mason as a component system but XSLT when I
>need ad-hoc transformation a la AxKit, Cocoon and other XSLT
>processor-based systems. Mixing AxKit and Mason may sound crazy but each
>has compelling ideas in their architecture.
Thanks for the information [...] Ian. Our site is very content-oriented,
and a lot of our business projects are starting to involve things like
co-branding and licensing content, so I'm very interested to hear more
about how you are integrating XSLT and Mason.
Do you generate XML documents in mason and then transform them via XSLT?
Are individual components responsible for their own transformations, or do
you do it all at the end with the whole page?
I agree that HTML::Mason is awesome, and the fact that it parses components
into anonymous perl subs gives it great performance. The other aspect
that's so great is its cacheing system, which can be so easily controlled
programmatically.
===
Subject: Re: Templating System
From: Matt Sergeant <matt@sergeant.org>
Date: Thu, 27 Jul 2000 17:58:38 +0100 (BST)
On Thu, 27 Jul 2000, Barry Hoggard wrote:
> Thanks for the information [...], Ian. Our site is very content-oriented,
> and a lot of our business projects are starting to involve things like
> co-branding and licensing content, so I'm very interested to hear more
> about how you are integrating XSLT and Mason.
>
> Do you generate XML documents in mason and then transform them via XSLT?
>
> Are individual components responsible for their own transformations, or do
> you do it all at the end with the whole page?
>
> I agree that HTML::Mason is awesome, and the fact that it parses components
> into anonymous perl subs gives it great performance. The other aspect
> that's so great is its cacheing system, which can be so easily controlled
> programmatically.
Jonathan and I spoke briefly at the conference about working together on a
combined effort of some sort - I could really use Mason's caching
technology, and he could really use my XML stuff. So maybe something will
come of that, who knows. Sadly we didn't really have enough time to talk
it through. [Jonathan; are you coming to ApacheCon Europe? Maybe we can
bash heads again there?]
===
Subject: Re: Templating System
From: "Paul J. Lucas" <pjl@barefooters.org>
Date: Thu, 27 Jul 2000 09:55:49 -0700 (PDT)
On Thu, 27 Jul 2000 JoshNarins@aol.com wrote:
> Now, your TD cells are going to get the red (assuming you aren't using
> Netscape's broken CSS). But how could you force one cell to get the yellow?
> The normal way to do it would be <TD ID="oneTD"> but you have already used up
> your ID tag.
...which is why the CLASS attribute is a better choice: it
specifically allows multiple classes, e.g.:
CLASS="one two three"
- Paul
===
Subject: Re: Templating system
From: "Paul J. Lucas" <pjl@barefooters.org>
Date: Thu, 27 Jul 2000 10:11:25 -0700 (PDT)
On Thu, 27 Jul 2000, Jeffrey W. Baker wrote:
> On Thu, 27 Jul 2000, Paul J. Lucas wrote:
>
> > http://www.best.com/~pjl/software/html_tree/
>
> Hey, that's really nice.
Thanks. :) Admitedly, the web site could use more example
other than what's in the manual pages, but where, oh where, to
find the time...
> And once the template HTML files are parsed, I can just leave the $root_node
> in memory for future requests, right?
Yes, I suppose so... I never thought hard about doing that.
The reason is that you have to be careful about doing it since
the Perl/mod_perl API *intends* for you to manipulate/change
the structure/content, hence what you're left with after a page
generation is not the same HTML tree you started with.
The HTML DOM parsing is really fast since that part of the
software is written natively in C++ with memory-mapped I/O.
(It's the same parsing engine used in SWISH++, FWIW.)
HTML Tree does, however, cache the associated Perl (.pm) code
for a page just like Apache::Registry does (based on timestamp).
> And since the parser isn't validating, I can extend HTML with tags like
> <NODE>, <BANNER>, and <WHATEVER>, right?
Not really, actually. The reason is that the HTML parser
doesn't know anything about non-standard HTML elements so it
can't know if an element (not "tag") you make up has a required
or optional end tag to get the parsing ("balancing") right. If
this were XML, it would be a different story.
Currently, "made up" elements are ignored entirely, i.e., *not*
added to the resultant HTML DOM tree and do not affect
"balancing" during parsing.
- Paul
===
Subject: Re: Templating System
From: Vivek Khera <khera@kciLink.com>
Date: Thu, 27 Jul 2000 13:48:39 -0400 (EDT)
BH" == Barry Hoggard <barry@investorama.com> writes:
BH> Thanks for the information below, Ian. Our site is very content-oriented,
BH> and a lot of our business projects are starting to involve things like
BH> co-branding and licensing content, so I'm very interested to hear more
BH> about how you are integrating XSLT and Mason.
Ditto here. Right now my top two contenders are AxKit and Mason. I
just have to decide which direction to go, but if there is a good way
to mix and match, I'd love to hear it. Mostly I need look and feel
templating (currently with Apache::Sandwich), and some content is
site-specific (right now if/else in SSI *ick*).
Is there some good forum specific to this topic? I've spent the last
few days reading on AxKit. Next few will be spent on Mason and
possibly Template Toolkit.
===
Subject: Re: Templating System
From: Jacob Davies <jacob@sfinteractive.com>
Date: Thu, 27 Jul 2000 10:57:24 -0700
I thought I'd drop a note on templating systems, since we seem to be having a
general discussion on it. I wrote the Text::TagTemplate module (on CPAN these
days, even!) and though I'm not going to actively suggest anyone using it (it
lacks good looping and conditional constructs, for one thing), it does two
or three things that I really like ('cause I wrote them) and I'd like to see in
some of the other templating packages.
The first is easy template-coder-controlled HTML-escaping of interpolated
values, so I (the Perl programmer) can just throw unescaped form data back into
the template, and the templater-coder can do:
<INPUT TYPE="TEXT" NAME="first_name" VALUE="<#FIRST_NAME HTMLESC>">
to use it safely in forms (or just in HTML body text sections).
The second is easy template-coder-controlled URL-escaping of interpolated
values, so I can just throw form data back into the template, and the
template-coder can do:
<A HREF="/somehandler?email=<#EMAIL URLESC>">
to use it safely in links.
The third is easy template-coder-controlled -- are you detecting a pattern
here? -- conversion of template data to SELECTED or CHECKED, so they can do
this:
<INPUT TYPE="CHECKBOX" NAME="option_1" <#OPTION_1 CHECKEDIF="on"> >
or this:
<SELECT NAME="country">
<OPTION VALUE="uk" <#COUNTRY SELECTEDIF="uk"> > The Mother Country
<OPTION VALUE="us" <#COUNTRY SELECTEDIF="us"> > Some Other Country
</SELECT>
That last saves me an *enormous* amount of time either coding the same thing
every time I want to save state in a pulldown menu, or generating the whole
HTML code for the menu in my Perl code.
I've seen features one & two in some packages, in HTML::Template maybe, but I
haven't seen the third one anywhere at all. Maybe I'm missing where someone
has already done it.
===
Subject: RE: Templating system
From: "Douglas Wilson" <dougw@racesearch.com>
Date: Thu, 27 Jul 2000 11:03:16 -0700
Original Message-----
> From: Paul J. Lucas [mailto:pjl@barefooters.org]
> Sent: Thursday, July 27, 2000 10:11 AM
> To: modperl@apache.org
> Subject: Re: Templating system
>
>
> On Thu, 27 Jul 2000, Jeffrey W. Baker wrote:
>
> > On Thu, 27 Jul 2000, Paul J. Lucas wrote:
> >
> > > http://www.best.com/~pjl/software/html_tree/
I've been researching templating systems for the past few days,
I come in this morning, and here's 40 or so posts on the very
subject. I've been wanting one where the template is as much like
plain html as possible, and this seems to fit the bill.
Until now I've been leaning toward the Template Toolkit, if only
because the template elements can be filled in with other templates
(maybe that's just in the beta version, I forget). We'd like to just
have a standard Header/Footer, but have the Header & Footer be
based on what client we're hosting, and the only template kit
I could see that had variable includes was HTML::DynamicTemplate.
I'm going to have to make some decision soon, so we can start getting
some work done :)
Can anyone point me to some examples (to accelerate the learning
curve) with this HTML::Tree?? Or any other pointers, opinions?
===
Subject: RE: Templating system
From: Perrin Harkins <perrin@primenet.com>
Date: Thu, 27 Jul 2000 11:30:33 -0700 (PDT)
On Thu, 27 Jul 2000, Douglas Wilson wrote:
> Until now I've been leaning toward the Template Toolkit, if only
> because the template elements can be filled in with other templates
> (maybe that's just in the beta version, I forget). We'd like to just
> have a standard Header/Footer, but have the Header & Footer be based
> on what client we're hosting, and the only template kit I could see
> that had variable includes was HTML::DynamicTemplate.
That should be pretty easy in most of these systems. TT can definitely do
it (version 1 and version 2), and so can perl-in-HTML systems like Mason.
===
Subject: Re: Templating System
From: Autarch <autarch@urth.org>
Date: Thu, 27 Jul 2000 13:26:35 -0500 (CDT)
On Thu, 27 Jul 2000, Jacob Davies wrote:
> <SELECT NAME="country">
> <OPTION VALUE="uk" <#COUNTRY SELECTEDIF="uk"> > The Mother Country
> <OPTION VALUE="us" <#COUNTRY SELECTEDIF="us"> > Some Other Country
> </SELECT>
In Mason that looks like:
<option value="uk" <% $country eq 'uk' ? 'selected' : '' %>>
Or
<option value="uk" <% 'selected' if $country eq 'uk' %>>
Seems pretty close to what you want, I think.
===
Subject: Re: Templating System
From: "Paul J. Lucas" <pjl@barefooters.org>
Date: Thu, 27 Jul 2000 11:28:03 -0700 (PDT)
On Thu, 27 Jul 2000, Jacob Davies wrote:
> <INPUT TYPE="TEXT" NAME="first_name" VALUE="<#FIRST_NAME HTMLESC>">
If I understand what this does, my HTML Tree can do this by
doing:
<INPUT TYPE=text NAME="first_name" VALUE="" CLASS="value::first_name">
where the VALUE would be filled in from the value stored in:
$this->{ first_name }
where $this is a reference to an object created by the
associated .pm file and first_name was (presumeably) read in
from a database via DBI.
> <A HREF="/somehandler?email=<#EMAIL URLESC>">
This can be done by doing:
<A HREF="/somehandler?email=REPLACE" CLASS="repl_email">
and in the .pm:
$node->atts->{ href } =~ s/REPLACE/$real_address/;
or just by changing the entire value:
<A HREF="/somehandler?email=bogus" CLASS="href::handler">
where "handler" is taken from:
$this->{ handler }
> <SELECT NAME="country">
> <OPTION VALUE="uk" <#COUNTRY SELECTEDIF="uk"> > The Mother Country
> <OPTION VALUE="us" <#COUNTRY SELECTEDIF="us"> > Some Other Country
> </SELECT>
This is specifically supported by doing (example take from
Apache::HTML::ClassParser man page):
<SELECT NAME="Flavor">
<OPTION CLASS="select::flavor_id" VALUE="0">Chocolate
<OPTION CLASS="select::flavor_id" VALUE="1">Strawberry
<OPTION CLASS="select::flavor_id" VALUE="2">Vanilla
</SELECT>
> I've seen features one & two in some packages, in HTML::Template maybe, but I
> haven't seen the third one anywhere at all. Maybe I'm missing where someone
> has already done it.
Yes, in HTML Tree.
==
Subject: Re: Templating System
From: "Paul J. Lucas" <pjl@barefooters.org>
Date: Thu, 27 Jul 2000 11:29:35 -0700 (PDT)
On Thu, 27 Jul 2000, Autarch wrote:
> <option value="uk" <% 'selected' if $country eq 'uk' %>>
>
> Seems pretty close to what you want, I think.
Except it puts Perl code in the HTML file and uses invalid
HTML.
===
Subject: RE: Templating System
From: "Gerald Richter" <richter@ecos.de>
Date: Thu, 27 Jul 2000 20:31:38 +0200
SELECT NAME="country">
> > <OPTION VALUE="uk" <#COUNTRY SELECTEDIF="uk"> > The Mother Country
> > <OPTION VALUE="us" <#COUNTRY SELECTEDIF="us"> > Some Other Country
> > </SELECT>
>
> In Mason that looks like:
>
> <option value="uk" <% $country eq 'uk' ? 'selected' : '' %>>
>
> Or
>
> <option value="uk" <% 'selected' if $country eq 'uk' %>>
>
In Embperl you simply write
<SELECT NAME="country">
<OPTION VALUE="uk">The Mother Country
<OPTION VALUE="us">Some Other Country
</SELECT>
Embperl select the option which value is found in $fdat{country} . (The hash
%fdat contains the form data posted to this page, so if you post a form to
itself, it will automaticly display the values the user just entered)
Gerald
===
Subject: Re: Templating System
From: Perrin Harkins <perrin@primenet.com>
Date: Thu, 27 Jul 2000 11:42:07 -0700 (PDT)
On Thu, 27 Jul 2000, Jacob Davies wrote:
> The first is easy template-coder-controlled HTML-escaping of
> interpolated values, so I (the Perl programmer) can just throw
> unescaped form data back into the template, and the templater-coder
> can do:
>
> <INPUT TYPE="TEXT" NAME="first_name" VALUE="<#FIRST_NAME HTMLESC>">
To do this with Template Toolkit, I map the Apache::Util escaping
functions in the data I pass when I execute the template:
$args{'DATA'}->{'html'} = \&Apache::Util::escape_html;
Then I can just say this:
[% html(first_name) %]
> The second is easy template-coder-controlled URL-escaping of
> interpolated values
Same deal, but with Apache::Util::escape_uri.
> The third is easy template-coder-controlled -- are you detecting a pattern
> here? -- conversion of template data to SELECTED or CHECKED, so they can do
> this:
>
> <INPUT TYPE="CHECKBOX" NAME="option_1" <#OPTION_1 CHECKEDIF="on"> >
I do this with IF constructs, which is not as compact as your example but
it works:
[% "checked" IF my_checkbox == option_1 %]
(This assumes I've put the name of the selected checkbox into
my_checkbox.)
I'm sure other systems allow something similar.
===
Subject: RE: Templating System
From: "Gerald Richter" <richter@ecos.de>
Date: Thu, 27 Jul 2000 20:43:49 +0200
SELECT NAME="country">
> > > <OPTION VALUE="uk" <#COUNTRY SELECTEDIF="uk"> > The Mother Country
> > > <OPTION VALUE="us" <#COUNTRY SELECTEDIF="us"> > Some Other Country
> > > </SELECT>
> >
> > In Mason that looks like:
> >
> > <option value="uk" <% $country eq 'uk' ? 'selected' : '' %>>
> >
> > Or
> >
> > <option value="uk" <% 'selected' if $country eq 'uk' %>>
> >
>
> In Embperl you simply write
>
> <SELECT NAME="country">
> <OPTION VALUE="uk">The Mother Country
> <OPTION VALUE="us">Some Other Country
> </SELECT>
>
> Embperl select the option which value is found in $fdat{country}
> . (The hash
> %fdat contains the form data posted to this page, so if you post a form to
> itself, it will automaticly display the values the user just entered)
>
Just missied the first part:
> <INPUT TYPE="TEXT" NAME="first_name" VALUE="<#FIRST_NAME HTMLESC>">
Embperl take $fdat{first_name} (if present) and generate the value atrribute
for you
<INPUT TYPE="TEXT" NAME="first_name">
> <A HREF="/somehandler?email=<#EMAIL URLESC>">
<A HREF="/somehandler?email=[+ $email +]">
Embperl knows the context and automaticly chooses the right escaping.
Normaly you don't have to care about it (also you can, if you don't like
Embperl selection)
Gerald
===
Subject: RE: Templating system
From: "Douglas Wilson" <dougw@racesearch.com>
Date: Thu, 27 Jul 2000 11:42:17 -0700
Original Message-----
> From: Paul J. Lucas [mailto:pjl@barefooters.org]
> Sent: Thursday, July 27, 2000 10:11 AM
> To: modperl@apache.org
> Subject: Re: Templating system
>
>
> On Thu, 27 Jul 2000, Jeffrey W. Baker wrote:
>
> > On Thu, 27 Jul 2000, Paul J. Lucas wrote:
> >
> > > http://www.best.com/~pjl/software/html_tree/
Is there a reason this is not on CPAN? It would have been
nice to come up in a search. (I actually searched for 'template',
so I'm not sure I would have ever found it anyway :)
===
Subject: Re: Templating System
From: Perrin Harkins <perrin@primenet.com>
Date: Thu, 27 Jul 2000 11:55:39 -0700 (PDT)
On Thu, 27 Jul 2000, Erich L. Markert wrote:
> OK, I'm nearing the end of one project so I'm able to take a look at new
> solutions so one question comes to mind. What does the template toolkit
> offer above and beyond HTML::Embperl or some other templating solution?
Well, keep in mind that TT does not try to provide an entire web
programming framework. It is a templating system only. Neat tricks like
automatic form state in Embperl are not built into it.
However, it has a very complete syntax for dealing with templating, and is
easy for HTML coders who don't know perl to use. Programming with it is
usually as simple as dumping some data into a structure (which can be as
complex as you nedd it to be) and passing it to TT. The new version is
very fast, and it has a nice plugin framework for adding your own
extensions to it.
If you favor the idea of totally separating your HTML and perl code, this
is a great tool. If you like mixing perl and HTML, PHP-style, the
additional features in Embperl or Apache::ASP will probably make those a
better choice.
> On a side note, wouldn't the mod_perl community be better served
> focusing on one of these solutions and building upon it and creating a
> mod_perl based application server much like Python has Zope?
There's an interesting project called Iaido (formerly Iaijutsu) which can
be found here: http://sourceforge.net/project/?group_id=8376
Personally, I tend to agree with Nicholas Petreley
(http://www.linuxworld.com/linuxworld/lw-2000-07/f_lw-07-penguin_2.html) that
Zope is no panacea.
===
Subject: Re: Templating System
From: Perrin Harkins <perrin@primenet.com>
Date: Thu, 27 Jul 2000 11:59:39 -0700 (PDT)
On Thu, 27 Jul 2000, Kenneth Lee wrote:
> My ideal system would be those the designer can see the server-side
> objects and data fields in the database, and only associate them with
> the template by drag-n-drop. The designer doesn't sees any special
> tags, and doesn't have to conform to those "variables" with the
> programmer. The associations can be done by the programmer too, and he
> can also be isolated from the HTML codes.
Sounds like you're describing WebObjects. However, I never trust those
GUI HTML designer things, and good HTML coders don't either. If you
really feel you need one, you should be able to add your special tags into
Dreamweaver without too much work, and I think NetObjects Fusion can do
this too.
===
Subject: RE: Templating System (preview Embperl 2.0)
From: "Gerald Richter" <richter@ecos.de>
Date: Thu, 27 Jul 2000 20:51:36 +0200
Jonathan and I spoke briefly at the conference about working together on a
> combined effort of some sort - I could really use Mason's caching
> technology, and he could really use my XML stuff. So maybe something will
> come of that, who knows.
That's exactly what I already started with Embperl 2.0. Embperl 1.3b4
(http://perl.apache.org/embperl/) has already a component handling with the
same power like Mason (also the approach is a little different). Additionaly
it handles some html specific things, that Mason doesn't (like dynamic
tables, formfiled processing, etc.).
Embperl 2.0 add's the possibility to define/modify your own syntax, so you
are able to define custom html/xml tags that call's subroutines (or generate
arbitary perl code, like loops etc.). Also I personaly don't like that
approach, you are able to define very easy things like using the id
attribute of an existing tag, like it was requested earlier in this thread,
to genrate perl code from it. On my talk at the Perl conference I had an
example how at dynamicly rewrite the source url of every image tag, just by
defining a perl subroutine with three lines of code. To keep it fast Embperl
is written in C. It parses the html/xml into a DOM Tree and precompiles the
Perl code into an a Perl sub (That is done by Embperl 1.x already for three
years). Up to this point Embperl 2.0 is already working (also the current
version is called alpha, this is mainly due to the missing features and not
a problem a stability). Next I will add caching of the output or
intermediate steps (the currenty alpha already caches the Source DOM tree
and the compiled Perl code). Unless Mason, Embperl is not only able to cache
plain HTML (or other ascii) files, but also cache DOM trees in any step of
the the processing. To make this memory efficient, I have written a DOM
storage for Embperl which is very memory efficient (e.g. able to store only
differences between serveral modification of a DOM tree) and fast. Like
AxKit Embperl will be able to join any number of processors (stylesheets in
AxKit terminology) to form a processing pipe that modifies the DOM tree.
This will for example make it possible to use EMbperl and SSI in the same
page, while the file must be parsed only once. Since Embperl can replace any
of these steps by custom modules, there will also be the possiblity to use
an XML parser (instead of the Embperl parser, which is optimized for the
current usage) and use things like XSLT to create the HTML (or whatever)
output. For XML processing Embperl 2.0 will offer similar features like
AxKit, but written in C, so it will be faster.
Let me say one word to mixing design and code. Template::Toolkit (and other
modules, which don't directly include perl code), reclains, that they better
separate code and design, but form my point of view they simply create a new
"language". If you want to separate code and design, that could also be done
with modules like Embperl, Mason, ASP which directly inlcude Perl code.
Simply create a Perl module which contains your code and do only calls to
this module and not include the real code in your page. That's only a matter
of discipline. The main adavatage I see for this modules is, that they don't
restrict you to do so. For small projects, it's often very handy to inlcude
the few lines of Perl code you need directly in the page.
Gerald
===
Subject: RE: Templating system
From: "Paul J. Lucas" <pjl@barefooters.org>
Date: Thu, 27 Jul 2000 11:53:14 -0700 (PDT)
On Thu, 27 Jul 2000, Douglas Wilson wrote:
> > > > http://www.best.com/~pjl/software/html_tree/
>
> Is there a reason this is not on CPAN?
The reasons (not necessarily good ones) are:
1. I haven't had the time to figure out their submission
procedures.
2. It's not (in my mind) in the "CPAN style" for the C++ part
of the build, i.e., you can't just say:
perl Makefile.PL
make
(You can say that for the Perl parts, however.) The C++ part
doesn't require Perl at all.
3. Although in practice it will most likely be used with Perl
or mod_perl, it's a stand-alone C++ library/API.
===
Subject: Fwd: Templating System
From: JoshNarins@aol.com
Date: Thu, 27 Jul 2000 15:06:15 EDT
In a message dated 7/27/00 12:56:45 PM Eastern Daylight Time,
pjl@barefooters.org writes:
> ...which is why the CLASS attribute is a better choice: it
> specifically allows multiple classes, e.g.:
>
> CLASS="one two three"
>
> - Paul
>
That sure is something I didn't know. Netscape on Linux doesn't support it,
either.
But thanks for the heads up.
===
Subject: Re: Templating System
From: aaron <ross@mathforum.com>
Date: Thu, 27 Jul 2000 15:31:19 -0400
at a time earlier than now, Perrin Harkins wrote:
> On Thu, 27 Jul 2000, Kenneth Lee wrote:
> > My ideal system would be those the designer can see the server-side
> > objects and data fields in the database, and only associate them with
--- begin sappy gratitude ---
my ideal system is having an environment where there are many tools.
i love seeing all the differences spelled out more! how fuckin' cool!
we use Embperl, Mason, Taco, SSI, and hopefully AxKit soon! Apache::Asp
looks really cool too! i hope that these projects all continue to succeed
as each provides different benefits and tools.
if you code mostly in modules, then you can often deploy many apps using
the same code but different templating tools...
having these choices make mod_perl the best choice i can imagine. thanks
everybody!
-- end sappy gratitude --
===
Subject: Re: Templating system
From: =?iso-8859-1?Q?Yann_Kerherv=E9?= <yk@cyberion.net>
Date: Thu, 27 Jul 2000 23:38:37 +0200
On Thu, Jul 27, 2000 at 11:03:16AM -0700, Douglas Wilson wrote:
>
> > -----Original Message-----
> > From: Paul J. Lucas [mailto:pjl@barefooters.org]
> > Sent: Thursday, July 27, 2000 10:11 AM
> > To: modperl@apache.org
> > Subject: Re: Templating system
> >
> >
> > On Thu, 27 Jul 2000, Jeffrey W. Baker wrote:
> >
> > > On Thu, 27 Jul 2000, Paul J. Lucas wrote:
> > >
> > > > http://www.best.com/~pjl/software/html_tree/
>
> I've been researching templating systems for the past few days,
> I come in this morning, and here's 40 or so posts on the very
> subject. I've been wanting one where the template is as much like
> plain html as possible, and this seems to fit the bill.
>
> Until now I've been leaning toward the Template Toolkit, if only
> because the template elements can be filled in with other templates
> (maybe that's just in the beta version, I forget). We'd like to just
> have a standard Header/Footer, but have the Header & Footer be
> based on what client we're hosting, and the only template kit
> I could see that had variable includes was HTML::DynamicTemplate.
>
> I'm going to have to make some decision soon, so we can start getting
> some work done :)
>
> Can anyone point me to some examples (to accelerate the learning
> curve) with this HTML::Tree?? Or any other pointers, opinions?
As far I know (I'm a today-newcomer on the list - but I've done my best
to read previous messages in archives), no one speaks really about
HTML-Template (from Sam Tregar) . What I like (and what seems to
interest you):
- HTML-TAGs style : <TMPL_TAG> (thus you can preview the design in a
browser)
- Few and simple tags
- loops (to handle tables)
- includes (So, there's at least another one than DynamicTemplate :)
- cache system (who works with mod_perl with IPC system)
- (obviously, no embedded perl in html, so it's highly maintenable)
Hope this helps
===
Subject: Re: Templating System
From: Jacob Davies <jacob@sfinteractive.com>
Date: Thu, 27 Jul 2000 12:59:14 -0700
On Thu, Jul 27, 2000 at 03:31:19PM -0400, aaron wrote:
> --- begin sappy gratitude ---
>
> my ideal system is having an environment where there are many tools.
> i love seeing all the differences spelled out more! how fuckin' cool!
> having these choices make mod_perl the best choice i can imagine. thanks
> everybody!
>
> -- end sappy gratitude --
Are you serious?
I see the plethora of templating tools as being the single
biggest problem with Perl web application development right
now.
Don't get me wrong, they're all insanely great and written
by extremely smart people. But the featuresets overlap
enormously, they have incompatible templating syntaxes, and
incompatible APIs. It's not just that there's more than one
way to do it, there's *twenty* ways to do it, and using any
one of them requires you to nail yourself to it. You have
to learn the system paradigm and API, you have to learn the
templating syntax, you have to train your HTML coders in the
syntax, and you have to accept that your applications are
going to be tied heavily to that module.
My experience differs greatly from yours in the success of
interoperability using multiple templating systems inside
one server. Even just two versions of a very similar
templating module (mine) caused enormous confusion on the
part of the other Perl programmers and amongst the HTML
coders. I can't imagine how confused they'd get with
systems as radically different as Mason and AxKit and
Embperl and TT and Apache::ASP and HTML::Tree and
Text::Template and Text::TagTemplate and CGI::FastTemplate
and HTML::Template deployed in the same installation. My
head explodes at the thought.
I would love to work on standardization of at least the
basic featureset in templating, but I don't know who else
would be interested in the effort. It would really require
all the major templating system developers to work with it,
and maybe that cat's too far out of the bag. I think that's
a real shame if it's true, that just as we are starting to
get settled on a really basic featureset for templating, we
are diverging into all these different development worlds
reimplementing the same ideas in slightly different forms.
===
Subject: Re: Templating system
From: Honza Pazdziora <adelton@informatics.muni.cz>
Date: Thu, 27 Jul 2000 22:02:58 +0200
On Thu, Jul 27, 2000 at 11:53:14AM -0700, Paul J. Lucas wrote:
>
> 1. I haven't had the time to figure out their submission
> procedures.
The $CPAN/modules/04pause.html describes it in good detail. Namely,
write to modules@perl.org with the information listed.
> 3. Although in practice it will most likely be used with Perl
> or mod_perl, it's a stand-alone C++ library/API.
Some modules solve this by including the C/C++ code in the Perl
distribution (GD, XML::Parser), other only include the Perl code in
CPAN tgz's and the Makefile.PL links to preinstalled libraries
(Compress::Zlib). But having the module on CPAN helps people to find
the module. One of the strengths of Perl is that all you need and all
that is available you should be able to find on one place -- in ideal
world.
===
Subject: Re: Templating System
From: merlyn@stonehenge.com (Randal L. Schwartz)
Date: 27 Jul 2000 13:14:54 -0700
Jacob" == Jacob Davies <jacob@sfinteractive.com> writes:
Jacob> <A HREF="/somehandler?email=<#EMAIL URLESC>">
That should actually be both URL escaped *and* HTML escaped if it
also contains &'s, like the form fields.
You probably knew that, but in case anyone else is watching.... :)
===
Subject: RE: Templating System (preview Embperl 2.0)
From: "Paul J. Lucas" <pjl@barefooters.org>
Date: Thu, 27 Jul 2000 13:21:42 -0700 (PDT)
On Thu, 27 Jul 2000, Gerald Richter wrote:
> To keep it fast Embperl is written in C.
Unless you use mmap(2), you can't compete with the speed of
HTML Tree. The only downside of mmap(2) is that HTML Tree must
be first in an Apache::Filter filter chain.
- Paul
===
Subject: Re: Templating System
From: Jacob Davies <jacob@sfinteractive.com>
Date: Thu, 27 Jul 2000 13:27:57 -0700
On Thu, Jul 27, 2000 at 01:14:54PM -0700, Randal L. Schwartz wrote:
> >>>>> "Jacob" == Jacob Davies <jacob@sfinteractive.com> writes:
>
> Jacob> <A HREF="/somehandler?email=<#EMAIL URLESC>">
>
> That should actually be both URL escaped *and* HTML escaped if it
> also contains &'s, like the form fields.
When I say URL-escape, I mean do this:
$str =~ s/([^a-zA-Z0-9_\-.])/ uc sprintf '%%%02x', ord $1 /eg;
Ampersands and quote marks and such can't make it through that. I think the
Apache::Util::escape_uri does something less than that, and I'm not sure which
is more correct (or even what source would tell me which is more correct).
Now as to ampersands used to separate form fields, like:
<A HREF="/somehandler?email=jacob%40sfinteractive.com&name=Jacob">
do you mean that it should be:
<A HREF="/somehandler?email=jacob%40sfinteractive.com&name=Jacob">
instead? That second one looks better now that I look at it, but I confess
that I invariably use the first one. I should know better. I guess that's
not a templating issue though, that's an HTML-coding issue. I tend not to
generate full URLs in my Perl code, since I can easily interpolate variables
into the value parts of the query string, so I can technically blame the HTML
coders for this one :)
===
Subject: Re: Templating System
From: merlyn@stonehenge.com (Randal L. Schwartz)
Date: 27 Jul 2000 13:34:14 -0700
Jacob" == Jacob Davies <jacob@sfinteractive.com> writes:
Jacob> Now as to ampersands used to separate form fields, like:
Jacob> <A HREF="/somehandler?email=jacob%40sfinteractive.com&name=Jacob">
Jacob> do you mean that it should be:
Jacob> <A HREF="/somehandler?email=jacob%40sfinteractive.com&name=Jacob">
Jacob> instead? That second one looks better now that I look at it,
Jacob> but I confess that I invariably use the first one.
Then you are wrong. :) You need to have & in there, so that the
browser can turn it back from & to & before sending the URL back
up to your server (or whichever server comes along).
===
Subject: Re: Templating System
From: Robin Berjon <robin@knowscape.com>
Date: Thu, 27 Jul 2000 15:36:46 +0200
At 13:02 27/07/2000 +0100, Matt Sergeant wrote:
>On Thu, 27 Jul 2000 JoshNarins@aol.com wrote:
>> I hear you, yet I also know that the ID= tags are valid
>> CSS. You are going o screw yourself up one way or the
>> other with that.
>> For instance...
>> <STYLE>
>> TD {color: red;}
>> .oneTD { color: yellow }
>> </STYLE>
>>
>> Now, your TD cells are going to get the red (assuming you aren't using
>> Netscape's
>> broken CSS). But how could you force one cell to get the yellow?
>> The normal way to do it would be
>> <TD ID="oneTD"> but you have already used up your ID tag.
>>
>> Tell me if I am missing something.
>The CLASS attribute.
That's only a workaround (though the code above is bugged, it should be
#oneTD in the CSS), supposedly one should have the abilty to apply style to
one single element using an ID, which offers the guarantee that no other
element will get that same style. It may seem like a small functionality,
but it still conflicts with HTML+CSS, which I don't like the sound of.
===
Subject: Re: Templating System
From: Christian Jaeger <christian.jaeger@sl.ethz.ch>
Date: Thu, 27 Jul 2000 23:33:53 +0200
At 19:57 Uhr +0200 27.7.2000, Jacob Davies wrote:
><SELECT NAME="country">
><OPTION VALUE="uk" <#COUNTRY SELECTEDIF="uk"> > The Mother Country
><OPTION VALUE="us" <#COUNTRY SELECTEDIF="us"> > Some Other Country
></SELECT>
In my system I would do
$htmltemplate