Re: [OT] About XML and Petal (was Re: templating system opinions (axkit?))

[Eric Cholet]

Le lundi, 28 juil 2003, à 21:27 Europe/Paris, Jean-Michel Hiver a écrit 
:

Also, with TT you have to use the filter 'html' to XML encode your
variables. Petal does it by default, and you need to use the TALES
'structure' keyword to NOT encode.
You don't *have* to use the 'html' filter in TT. I wrote a subclass of
Template which does this automatically for me, and as with Petal I can
also not encode by using a specific method.
--
Eric Cholet

[OT] About XML and Petal (was Re: templating system opinions (axkit?))

[Jean-Michel Hiver]

 XML syntax is crufty at best.  It requires you to be strict and tediously
 correct with every character.

So what. It's not like you can afford to forget that many curly braces
or semicolons (well, except those at the end of a block) with Perl. That
doesn't make it useless does it?


 You have to shoe-horn the semantics of your complex directives into
 the limited syntax of element-name-and-attributes.

If you're crazy enough to use XML as a programming language, I have to
agree with you. XML really sucks at that. However as a data exchange
format I think it's fine.

I think the same idea is behind AxKit's XPathScript. Let's use
programming languages to program, and XML as a vector to structure and
transport data.


 The language becomes contrived and clumsy as a result of trying to satisfy 
 a purity of design and you find yourself tied down to only generating valid
 XML (which few real world web pages are, even if they should be).

Well, I see Petal's ability to help you generating valid XML webpages as
a good thing. I do not recommend Petal to people who are interested in
generating HTML 3.2 pages full of tables, font face tags, fixed width
fonts and other javascripteries. They would be very disapointed.


 The templates becomes harder to read and write because they're
 designed to satisfy an XML parser rather than a human.  By using XML
 directives in XML markup, you ensure that the directives are
 camouflaged nicely and blend into the background.  This is precisely
 what you (well, I) don't want to happen.  These directives are
 supposed to be important - they are a separate concern from the purely
 declarative markup surrounding and deserve to stand out from the
 crowd.

I suppose that's one way of seing it. The problem is that your template
then looks like a programming language, which kind of defeats the
purpose of having a template in the first place.

I suppose that Petal is philosophically closer to HTML_Tree, except it
has a much gentler learning curve IMHO.


 This is all personal opinion, of course.

Same here :)


 I drank the XML kool aid for a long time, until I realised it was
 nothing but water, sugar and artifical colours.  XML still serves a
 useful purpose for many things, but it's not the uber-solution to all
 our problems that vendors of commercial XML software would have us
 believe. Just because you can write programs, or SQL queries, or
 templates using XML, doesn't mean that you should.

I agree on that.


 For the record, Petal looks like a well implemented template module,
 and I'm glad to see another high-calibre one joining the collective.
 I've looked at TAL before and while I understand the design philosophy
 that they're trying to promote, I still not that impressed because I
 can see what look like gaping holes in the reasoning behind it.


Maybe... It's a little bit strange when you get started with it, but
it becomes clear and very elegant quite quickly. For example with a
traditional mini-language kind of templating system, you might have
something like:

  div dir=!--VAR language_dir --
!--VAR some_content--
  /div

Which is completely impossible to validate and IMHO very hard to read.


With Petal you just start with a mockup:

  div dir=ltr
Hello, World
  /div


And then you add TAL instructions:

  div
dir=ltr
petal:attributes=ltr language_dir
petal:content=some_content
  
Hello, World
  /div


If you like a more straightforward approach, Petal also lets you write:

  div dir=$language_dir
$some_content
  /div

But at the risk of breaking compatibility with some validators / XML
tools / etc.


 Vive la difference!

Entierement d'accord :)
Cheers,
-- 
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED]  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/

Re: templating system opinions (axkit?)

[Matt Sergeant]

On Mon, 28 Jul 2003, Andy Wardley wrote:

 Jean-Michel Hiver wrote:
  Because Petal templates have to be well-formed XML,

 XML syntax is crufty at best.

There's a lot in XML that is needless, but like perl still has a dump()
function, we just say don't use that then. At it's core, XML is a very
elegant syntax for defining a rich dataset of nodes, and solves many of
the problems that text markup systems still struggle with reinventing
(such as different encodings - YAML for example forces everyone's
document to be in one of the UTF encodings).

 It requires you to be strict and tediously
 correct with every character.

Many believe this is a good thing with a templating language. Let the
browser be flexible in what it can receive, but let us, as professionals,
be strict in what we generate.

 You have to shoe-horn the semantics of your
 complex directives into the limited syntax of element-name-and-attributes.
 The language becomes contrived and clumsy as a result of trying to satisfy
 a purity of design.

This I can agree with, having written my own templating system because I
didn't like XSLT's idea of being written in XML :-) But I now use XSLT,
because it has other benefits (portable, fast, etc).

 and you find yourself tied down to only generating valid
 XML (which few real world web pages are, even if they should be).

My web pages come out as HTML 4.0 transitional, not XHTML, and they are
generated with XSLT. They often omit closing tags where appropriate for
HTML. I don't do any fancy post-processing. Sorry Andy, but the above is
not true at all.

 Vive la difference!

As you can see in evidence (Apache::AxKit::Language::*), I agree.

-- 
!-- Matt --
:-get a SMart net/:-
Spam trap - do not mail: [EMAIL PROTECTED]

Re: templating system opinions (axkit?)

[Andy Wardley]

Matt Sergeant wrote:
 At it's core, XML is a very elegant syntax for defining a rich dataset 
 of nodes

It's a syntax for defining a dataset of nodes that all conform to XML's
ideas about what a dataset of nodes looks like.  I'm not convinced about 
rich or elegant.  

:-)

  and you find yourself tied down to only generating valid
  XML (which few real world web pages are, even if they should be).
 
 My web pages come out as HTML 4.0 transitional, not XHTML, and they are
 generated with XSLT. They often omit closing tags where appropriate for
 HTML. I don't do any fancy post-processing. Sorry Andy, but the above is
 not true at all.

OK, fair enough, you can generate output that contains invalid XML markup.
But you can't write a source template that includes invalid XML as literal 
text.  At least not without escaping all the  and  characters and other
such madness.

However, I accept that this is construed as a feature in these kind of 
systems.  I just happen to prefer a slightly different kind of system.

A

Re: [OT] About XML and Petal (was Re: templating system opinions (axkit?))

[Andy Wardley]

Jean-Michel Hiver wrote:
 something like:
 
   div dir=!--VAR language_dir --
 !--VAR some_content--
   /div

 Which is completely impossible to validate and IMHO very hard to read.

Agreed.  The following is easier to read, IMHO, and is also valid XML markup.

div dir=[% language_dir %]
   [% some_content %]
/div

   div
 dir=ltr
 petal:attributes=ltr language_dir
 petal:content=some_content
   
 Hello, World
   /div

I accept that it's a clever approach, but I think it's the hardest to 
read of all three.  Both the original values and also the Petal replacement 
instructions are present in the element.  The reader has to mentally match 
them up to figure out what's going on.  It's hard to see at a glance that
'Hello World' is replaced by 'some_content', for example, without checking 
the element attributes. 

I'm sure that once you're in the Petal mindset it all make sense much more
quickly.  But you're right in saying that it's strange at first!

 If you like a more straightforward approach, Petal also lets you write:
 
   div dir=$language_dir
 $some_content
   /div

If you like a more straightforward approach, TT also lets you write:
 
   div dir=$language_dir
 $some_content
   /div

See, I knew there would be something that we would agree on!  :-)

 But at the risk of breaking compatibility with some validators / XML
 tools / etc.

It still looks like valid XML to me.  Where is the incompatability?  Am
I missing something obvious?


A

Re: [OT] About XML and Petal (was Re: templating system opinions(axkit?))

[Jean-Michel Hiver]

 If you like a more straightforward approach, TT also lets you write:
  
div dir=$language_dir
  $some_content
/div
 
 See, I knew there would be something that we would agree on!  :-)

:)


  But at the risk of breaking compatibility with some validators / XML
  tools / etc.
 
 It still looks like valid XML to me.  Where is the incompatability?  Am
 I missing something obvious?

And it is. However if you have, say, div id=[% VAR object.id %] then
it's not XHTML anymore (spaces / weird chars not allowed as
identifier...). I'm sure there's many more cases of nasty surprises.

There's also cases in which with TT or H::T you have:

  [% IF expression %]
foo
  [% FOR other_expression AS stuff %]
  ... some stuff
  /foo
[% END %]
  [% END %]

Here the problem is obvious because the code is well indented. However
with TAL syntax this simply cannot happen.

Also, with TT you have to use the filter 'html' to XML encode your
variables. Petal does it by default, and you need to use the TALES
'structure' keyword to NOT encode.

This is because double encoded values are much easier to spot and debug
than badly encoded ones.

To summarize, I think Petal is more specialized in XML templating and
has the strength of a very smart, open specification written by the Zope
people. Petal fills a niche across the XML and the templating world and
is certainly not a replacement for TT.

Actually, as Steve Purkis suggested on the Petal mailing list it would
be possible to implement Petal on top of TT. Maybe for Petal 2.00!

To conclude, and in order to satisfy my little ego I think both
libraries are deadly cool. Plus I would never have dreamed of the author
of TT arguing about the pros and cons of TT vs Petal with me when I
started writing the library a little more than a year ago.

That in itself is a great reward :-) 

Cheers,
Jean-Michel.

Re: [OT] About XML and Petal (was Re: templating system opinions (axkit?))

[Kyle Dawkins]

I suggest y'all check out Tapestry

http://jakarta.apache.org/tapestry

to see a really nice happy medium.  It uses a templating language 
similar to TAL but much more flexible (and useful, in my mind) than 
rigid XML.  All its templates can be used in things like Dreamweaver 
and GoLive with getting munged.  I also think that forcing templates to 
be valid XML is a huge pain in the nuts and would drive most poor HTML 
monkeys crazy.  We're the developers, leave the XML to us... don't 
force it on people who use photoshop for a living and have learned HTML 
so they could be a web designer because it's just gonna confuse them.

And besides, we're perl developers... we should take one look at XML 
and vomit at its disgusting syntax and unwieldy markup-heavy, 
text-heavy guts.  You can't beat pure perl for representing data 
structures, or NeXT plists, for that matter.  What's easier, this:

{
XML = Sucks,
Perl = [
Rules,
Is Great,
Is fun,
],
}
or this piece of nastiness

?xml some crazy required tagged bs?
SomeUselessWrapper
XMLSucks/XML
Perl
UselessItemTagRules/UselessItemTag
UselessItemTagIs Great/UselessItemTag
UselessItemTagIs fun/UselessItemTag
/Perl
/SomeUselessWrapper
Ok, so I'm not being totally fair, but you get the idea.
XML is a nice idea for certain things but I gotta agree with Andy... 
keep it out of my web templates.

Cheers

Kyle Dawkins
Central Park Software
On Monday, Jul 28, 2003, at 12:27 US/Pacific, Jean-Michel Hiver wrote:

If you like a more straightforward approach, TT also lets you write:

   div dir=$language_dir
 $some_content
   /div
See, I knew there would be something that we would agree on!  :-)
:)


But at the risk of breaking compatibility with some validators / XML
tools / etc.
It still looks like valid XML to me.  Where is the incompatability?  
Am
I missing something obvious?
And it is. However if you have, say, div id=[% VAR object.id %] 
then
it's not XHTML anymore (spaces / weird chars not allowed as
identifier...). I'm sure there's many more cases of nasty surprises.

There's also cases in which with TT or H::T you have:

  [% IF expression %]
foo
  [% FOR other_expression AS stuff %]
  ... some stuff
  /foo
[% END %]
  [% END %]
Here the problem is obvious because the code is well indented. However
with TAL syntax this simply cannot happen.
Also, with TT you have to use the filter 'html' to XML encode your
variables. Petal does it by default, and you need to use the TALES
'structure' keyword to NOT encode.
This is because double encoded values are much easier to spot and debug
than badly encoded ones.
To summarize, I think Petal is more specialized in XML templating and
has the strength of a very smart, open specification written by the 
Zope
people. Petal fills a niche across the XML and the templating world and
is certainly not a replacement for TT.

Actually, as Steve Purkis suggested on the Petal mailing list it would
be possible to implement Petal on top of TT. Maybe for Petal 2.00!
To conclude, and in order to satisfy my little ego I think both
libraries are deadly cool. Plus I would never have dreamed of the 
author
of TT arguing about the pros and cons of TT vs Petal with me when I
started writing the library a little more than a year ago.

That in itself is a great reward :-)

Cheers,
Jean-Michel.

Re: [OT] About XML and Petal (was Re: templating system opinions(axkit?))

[Aleksandr Guidrevitch]

Hi, All

May be I'm a bit late here... But is there any sence in artifical XML 
templating languages since there is XSLT ? Just wonder whether there are 
cons other than long learning curve and performance issues ?

Alex Gidrevich

Re: [OT] About XML and Petal (was Re: templating system opinions(axkit?))

[Chris Devers]

On Mon, 28 Jul 2003, Aleksandr Guidrevitch wrote:

 May be I'm a bit late here... But is there any sence in artifical XML
 templating languages since there is XSLT ? Just wonder whether there are
 cons other than long learning curve and performance issues ?

Well, in the case of just TAL/Petal, the point as far as I know isn't so
much that it happens to be valid XML -- though of course that's a welcome
design aspect -- but that it's easy to use in W3C compliant HTML without
masking the interesting bits inside HTML comment blocks.

I can't think of an example now (and apologize for only having had time to
skim much of this long, spiralling thread so far), but I seem to remember
that TAL's syntax allowed for these clever little inside out loop
structures that, among other things, ensures that the unrolled version of
the loop still has proper indentation etc. Unessential maybe, but a nice
touch.


I don't know nearly enough about XSLT to comment on it in depth, but my
impression is that TAL generally derives from the same heritage as all the
assorted Perl template languages, etc, rather than ...well I guess I don't
really know where XSLT derives from (Docbook?), but it seems more like
CSS: a separate document describing how to display one or more other
structured documents.

The difference in the case of TAL / TT / H::T / Mason / etc is that the
template is used to provide that structure itself, assembling it out of
code that is maybe extracting content from a database or calculating it on
the fly something.

My hunch is that the way to work XSLT into the mix -- if it has a place at
all -- is to have your logic (scripts with H::T, code sprinkled in Mason
templates, TT applied where clever TT people apply it)  fleshing out the
framework defined in a template (the H::T template, the non-code part of a
Mason template, the plaintext part of a TT template) as well formed XML,
and then using XSLT to format that intermediate form for display. This
probably makes sense in cases where that intermediate form can be cached
(pages for web or print that change once a day, say), but for truly
dynamic documents the XSLT stage is probably way too much overhead.


Is XSLT appropriate for applying both structure  styling to the free-
form output of a [Perl] program? Does it take a lot of overhead? Would
this overhead happen on the server end (glue XML + XSLT into an HTML
document that goes out over the wire), or on the client end (download XML,
then grab XSLT by reference (like HTML grabs CSS), and then the client
merges them)? If the client does the work, how widespread is support? If
the server does the work, what should the throughput be like?

My hunch -- which I'd be happy to be corrected about -- is that this can't
be any easier than just working directly from traditional template kits,
as has been discussed at remarkable length in this thread :)



-- 
Chris Devers[EMAIL PROTECTED]http://devers.homeip.net:8080/resume/
sorry for helping along in this thread 10 days  dozens of messages ago :)

Re: templating system opinions (axkit?)

[Jean-Michel Hiver]

 I've been considering using a template system for an app that I'm
 working, but decided against it as the designers who would be putting
 the actual pages together (look n feel) use Adobe GoLive which does
 'bad things' to non-html stuff (at least in my experience).

I know everybody's defending their fave templating system... I guess I
can't resist: I have to jump in and defend my baby :)

So why is Petal better than anything else?

First of all, it is an implementation of TAL. TAL is a very clever open
specification for WYSIWYG-friendly templates written by the Zope people.
TAL has three python implementations, one PHP implementation and two
Perl implementations (see Petal::CodePerl). I believe it will become the
standard with which template designers will want to work with.

You can open Petal XHTML templates into GoLive, Dreamweaver, Mozilla,
and they will look fine. Petal is basically an implementation of TAL, an
open specification designed by the ZOPE people to be WYSIWYG-compatible
and which has been extensively tested with all kinds of WYSIWYG-ish
software.

Because Petal templates have to be well-formed XML, it is safe (and in
fact recommended!) to send them through HTML tidy and check for
well-formness with xmllint.

Petal is not limited to XHTML. You can template any kind of XML. RSS,
RDF, SVG, WML... you name it!

It has good support for Unicode / multi-lingual applications and
character set encoding (well, provided you use Perl 5.8).

It is quite fast (templates are turned into subroutines which are cached
on disk and in memory). It has been designed to be very mod_perl
friendly.

Petal has an active community and a mailing list, it is stable and has
already been successfully used in different projects by different
people.

This TAL spec that I've shamelessly stolen / implemented is a really
cool idea.  You should really give it a try in between two Template
Toolkit driven projects :)

Cheers,
-- 
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED]  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/

Re: templating system opinions (axkit?)

[Jean-Michel Hiver]

 I know everybody's defending their fave templating system... I guess I
 can't resist: I have to jump in and defend my baby :)
 
 So why is Petal better than anything else?

Oops, I got a bit carried away...

As a side note, Petal is probably not better than anything else, but
different. If you're templating XML / XHTML, it'll do a really good
job. If you're templating text, use something else :)

Cheers,
-- 
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED]  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/

Re: templating system opinions (axkit?)

[Jeff AA]

 - Original Message - 
 From: Jean-Michel Hiver [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Sent: Thursday, July 24, 2003 1:46 PM


 First of all, it is an implementation of TAL. TAL is a very clever open
 specification for WYSIWYG-friendly templates written by the Zope people.

Do you have a URL for further reading on TAL?


 Petal has an active community and a mailing list, 

Ditto - a URL would be interesting!


Regards
Jeff

RE: templating system opinions (axkit?)

[Kitch, David]

Do you have a URL for further reading on TAL?

I found one:
http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL

Regards,
Kitch

RE: Templating system opinions (CGI::Application in connection with either HTML::Template or Template::Toolkit)

[Jesse Erlbaum]

Hey Randal --

 Maybe because it competes with OpenInteract, which is far 
 more established.

I don't really think OI and CGI-App are in competition at all.  OI
attempts to be a uber-framework, a la Mason -- or maybe more like
ColdFusion or WebObjects.CGI::Application just focuses on web
application state management.

CGI::Application doesn't try to bolt on anything else.  The developer
can choose their favorite modules for templating system, database
interface, object persistence, session management, etc.  CGI-App is
specifically made to allow developers to choose from the best available
CPAN libraries, rather than to pre-select for them.

You could probably use CGI::Application to implement part of
OpenInteract, but you wouldn't use one in lieu of the other.  They're
not really comparable at all.

TTYL,

-Jesse-


--

  Jesse Erlbaum
  The Erlbaum Group
  [EMAIL PROTECTED]
  Phone: 212-684-6161
  Fax: 212-684-6226

Re: templating system opinions (axkit?)

[Jean-Michel Hiver]

  First of all, it is an implementation of TAL. TAL is a very clever open
  specification for WYSIWYG-friendly templates written by the Zope people.
 
 Do you have a URL for further reading on TAL?

Yep.

http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL


  Petal has an active community and a mailing list, 
 
 Ditto - a URL would be interesting!

Sure :)

http://lists.webarch.co.uk/mailman/listinfo/petal


Cheers,
-- 
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED]  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/

Re: templating system opinions (axkit?)

[Matt Sergeant]

On Mon, 21 Jul 2003, Patrick Galbraith wrote:

 Anyone on this list use AxKit? I'm curious how it pans out.

 I like the idea of XSLT/XML, though I find myself trying to read between
 the lines of hype vs. something that's actually very useful. I don't know,
 so I don't have any opinions. I do know I'd like to use XSLT/XML so as to
 have a project to use it for, hence learn it.

I'm just about to roll out a site using AxKit that has to do about 3
million hits/day out of the box.

The main reason I like AxKit is it prevents me from screwing up and
creating XSS bugs, because everything has to be well formed. I almost
never have to use html or URL encode/decode functions - I just write
straight perl code.

I barely notice that I'm using XML.

It's also worth noting that XSLT is a portable skill, with lots of great
offline tools.

It's also worth saying: never listen to hype. Evaluate solutions based on
your criteria. AxKit matches mine but it doesn't mean it will match yours.

Matt.

Re: templating system opinions (axkit?) [OT]

[Ged Haywood]

Hi Matt,

On Wed, 23 Jul 2003, Matt Sergeant wrote:

 The main reason I like AxKit is it prevents me from screwing up [snip]
 I just write straight perl code.  I barely notice that I'm using XML.

Can you give us in a couple of sentences your take on the state of XML
in general and AxKit in particular?  To me somehow things don't seem
to be going in quite the same direction any more...

73,
Ged.

RE: templating system opinions (axkit?)

[Hauck, William B.]

Hi,

I've been considering using a template system for an app that I'm working, but decided 
against it as the designers who would be putting the actual pages together (look n 
feel) use Adobe GoLive which does 'bad things' to non-html stuff (at least in my 
experience).

What i've done is just use completely external html files with html-compliant comments 
indicating the data field. (example !-- APPNAME_USER_FIRST_NAME --).  My application 
just reads in the html on startup and does a series of substition statements over the 
file as necessary to replace the comments with the actual data.  Thus, each type of 
page has one base html (or html file pieces) that are merged with each other and data 
as necessary allowing all logic to be kept in the program.

It's certainly not the most robust system in the world, but it's simple and compatible 
with existing skill sets and design tools.  Also, it only reads those html files once 
at startup so if you change designs on the fly the application needs to be restarted.  
I'll be adding a function to either stat the files before using the cached version or 
just automatically reload the files every 15 minutes regardless of changes to 
eliminate the SIGHUP issue.

Please do note that I'm only expecting, on the VERY high side, a few thousand users to 
be hitting it each day.

good luck,

bill


-Original Message-
From:   Matt Sergeant [mailto:[EMAIL PROTECTED]
Sent:   Wed 2003-07-23 4:00 AM
To: Patrick Galbraith
Cc: [EMAIL PROTECTED]
Subject:Re: templating system opinions (axkit?)
On Mon, 21 Jul 2003, Patrick Galbraith wrote:

 Anyone on this list use AxKit? I'm curious how it pans out.

 I like the idea of XSLT/XML, though I find myself trying to read between
 the lines of hype vs. something that's actually very useful. I don't know,
 so I don't have any opinions. I do know I'd like to use XSLT/XML so as to
 have a project to use it for, hence learn it.

I'm just about to roll out a site using AxKit that has to do about 3
million hits/day out of the box.

The main reason I like AxKit is it prevents me from screwing up and
creating XSS bugs, because everything has to be well formed. I almost
never have to use html or URL encode/decode functions - I just write
straight perl code.

I barely notice that I'm using XML.

It's also worth noting that XSLT is a portable skill, with lots of great
offline tools.

It's also worth saying: never listen to hype. Evaluate solutions based on
your criteria. AxKit matches mine but it doesn't mean it will match yours.

Matt.







CONFIDENTIALITY NOTICE: This E-Mail is intended only 
for the use of the individual or entity to which it is addressed and may contain 
information that is privileged, confidential and exempt from disclosure under 
applicable law. If you have received this communication in error, please do not 
distribute and delete the original message.  Please notify the sender by E-Mail at the 
address shown. Thank you for your compliance.

RE: templating system opinions (axkit?)

[Sam Tregar]

On Wed, 23 Jul 2003, Hauck, William B. wrote:

 What i've done is just use completely external html files with
 html-compliant comments indicating the data field. (example !--
 APPNAME_USER_FIRST_NAME --).  My application just reads in the html
 on startup and does a series of substition statements over the file
 as necessary to replace the comments with the actual data.  Thus,
 each type of page has one base html (or html file pieces) that are
 merged with each other and data as necessary allowing all logic to
 be kept in the program.

Change that to:

  !-- TMPL_VAR APPNAME_USER_FIRST_NAME --

and you can use HTML::Template!  You'll also get loops, includes,
and simple conditionals should you ever need them.

-sam

RE: templating system opinions (axkit?)

[FFabrizio]

 Change that to:
 
   !-- TMPL_VAR APPNAME_USER_FIRST_NAME --

You mean TMPL_VAR APPNAME_USER_FIRST_NAME don't you?  Or did I miss the
secret stealth hide-your-tags-in-html-comments feature? :-) 

-Fran 

RE: templating system opinions (axkit?)

[Marc Slagle]

What you have created for your own use is almost exactly what HTML::Template does. We have used it for a year without any major problems between us and the HTML designer. Its fast and supports loops and if statements. Its probably worth your while to check it out.

As far as XSLT goes, we're moving to it now (XML::LibXSLT) and its making our life much easier. Our designer doesnt mind learning it, esp. after showing him what it can do.

Marc Slagle
Whapps, LLC.

On Wed, 2003-07-23 at 10:27, Hauck, William B. wrote:

Hi,

I've been considering using a template system for an app that I'm working, but decided against it as the designers who would be putting the actual pages together (look n feel) use Adobe GoLive which does 'bad things' to non-html stuff (at least in my experience).

What i've done is just use completely external html files with html-compliant comments indicating the data field. (example !-- APPNAME_USER_FIRST_NAME --).  My application just reads in the html on startup and does a series of substition statements over the file as necessary to replace the comments with the actual data.  Thus, each type of page has one base html (or html file pieces) that are merged with each other and data as necessary allowing all logic to be kept in the program.

Re: templating system opinions (axkit?)

[Douglas Hunter]

Hauck, William B. wrote:
Hi,

snip /

I'll be adding a function to 


And then you'll be adding a function to..., and then possibly a function 
to..., and then you'll need it to...

Pretty soon, you will have spent hundreds of hours developing a 
templating system that you throw away in favor of one of the tried and 
true templating systems that are available.

Of course I may be wrong.  Your needs may be very simple, and may not 
change over time.

But you may want to ask around on this list to see how many folks have 
rolled their own templating system and thrown it away.  Of course there 
are folks on this list who haven't thrown theirs away, and have worked 
hard to make them robust, stable and performant.  Thats why we take 
advantage of their work ;-)


bill
-- Douglas




-Original Message-
From:   Matt Sergeant [mailto:[EMAIL PROTECTED]
Sent:   Wed 2003-07-23 4:00 AM
To: Patrick Galbraith
Cc: [EMAIL PROTECTED]
Subject:Re: templating system opinions (axkit?)
On Mon, 21 Jul 2003, Patrick Galbraith wrote:

Anyone on this list use AxKit? I'm curious how it pans out.

I like the idea of XSLT/XML, though I find myself trying to read between
the lines of hype vs. something that's actually very useful. I don't know,
so I don't have any opinions. I do know I'd like to use XSLT/XML so as to
have a project to use it for, hence learn it.


I'm just about to roll out a site using AxKit that has to do about 3
million hits/day out of the box.
The main reason I like AxKit is it prevents me from screwing up and
creating XSS bugs, because everything has to be well formed. I almost
never have to use html or URL encode/decode functions - I just write
straight perl code.
I barely notice that I'm using XML.

It's also worth noting that XSLT is a portable skill, with lots of great
offline tools.
It's also worth saying: never listen to hype. Evaluate solutions based on
your criteria. AxKit matches mine but it doesn't mean it will match yours.
Matt.







CONFIDENTIALITY NOTICE: This E-Mail is intended only 
for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute and delete the original message.  Please notify the sender by E-Mail at the address shown. Thank you for your compliance.

Re: templating system opinions (axkit?)

[Perrin Harkins]

[EMAIL PROTECTED] wrote:
Change that to:

 !-- TMPL_VAR APPNAME_USER_FIRST_NAME --


You mean TMPL_VAR APPNAME_USER_FIRST_NAME don't you?  Or did I miss the
secret stealth hide-your-tags-in-html-comments feature? :-)
You missed it:
http://search.cpan.org/author/SAMTREGAR/HTML-Template-2.6/Template.pm#NOTES
- Perrin

RE: templating system opinions (axkit?)

[FFabrizio]

 You missed it:
 http://search.cpan.org/author/SAMTREGAR/HTML-Template-2.6/Temp
late.pm#NOTES

Ah.  When the section begins If you're a fanatic about valid HTML it
becomes more clear why I missed that. :-)

Thanks,
Fran

Re: Templating system opinions (CGI::Application in connection with either HTML::Template or Template::Toolkit)

[Randal L. Schwartz]

 Dave == Dave Baker [EMAIL PROTECTED] writes:

Dave I'm curious as to why the combination of CGI::Application and
Dave HTML::Template hasn't taken off ... CGI::Application seems to allow a
Dave software developer to create an entire CGI app that can be stored and
Dave distributed as a module on CPAN, but only a couple such app/modules
Dave have been so added.

Maybe because it competes with OpenInteract, which is far more established.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Templating system opinions (CGI::Application in connection with either HTML::Template or Template::Toolkit)

[Eric]

Hi,

That was really interesting to look at. OpenInteract is really impressive. 
I guess there is always a cost to having a big
do it all type of system. That is what made me avoid Mason, it just blew my 
head off for complexity. Now it is true, I am looking for a bit more than 
what CGI::Application offers out of the box, but it may well end up being 
worthwhile to just extend rather than convert. I really appreciate the 
simple philosophy that HTML::Template and CGI::Application follow.

One question, how do you judge that OpenInteract is more established? Is 
does look like it is actively developed, but I never heard of it before, 
and I couldn't find much indication of how popular it is.



Thanks,

Eric

At 09:23 AM 2003-07-23, Randal L. Schwartz wrote:
 Dave == Dave Baker [EMAIL PROTECTED] writes:

Dave I'm curious as to why the combination of CGI::Application and
Dave HTML::Template hasn't taken off ... CGI::Application seems to allow a
Dave software developer to create an entire CGI app that can be stored and
Dave distributed as a module on CPAN, but only a couple such app/modules
Dave have been so added.
Maybe because it competes with OpenInteract, which is far more established.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Lead Programmer
D.M. Contact Management
250.383.0836

Re: Templating system opinions (CGI::Application in connection witheither HTML::Template or Template::Toolkit)

[Dave Rolsky]

On Wed, 23 Jul 2003, Eric wrote:

 do it all type of system. That is what made me avoid Mason, it just blew my
 head off for complexity. Now it is true, I am looking for a bit more than

There's a fine book about it.

www.masonbook.com

Just an unbiased opinion ;)


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

Re: Templating system opinions (CGI::Application in connection witheither HTML::Template or Template::Toolkit)

[Chris Winters]

Eric wrote:
That was really interesting to look at. OpenInteract is really 
impressive. I guess there is always a cost to having a big
do it all type of system. That is what made me avoid Mason, it just blew 
my head off for complexity. Now it is true, I am looking for a bit more 
than what CGI::Application offers out of the box, but it may well end up 
being worthwhile to just extend rather than convert. I really appreciate 
the simple philosophy that HTML::Template and CGI::Application follow.
OpenInteract definitely does more for you. But it also has (IMO) a 
fairly sophisticated way to distribute standalone applications -- 
including data structures, initial data, security settings, 
templates and (oh yeah) the actual perl code -- and plug them into 
another OI server.

OI 1.x ties you to the Template Toolkit, but 2.x (a big improvement 
now in beta) allows you to use whatever templating engine you like. 
You lose a ton of functionality, but HTML::Template folks seem to 
like it that way :-)

One question, how do you judge that OpenInteract is more established? Is 
does look like it is actively developed, but I never heard of it before, 
and I couldn't find much indication of how popular it is.
Randal's 'far more established' may be premature :-) Taking a strict 
time perspective: from Backpan it looks like CGI::Application was 
first released to CPAN in July 2000, while OI was first released in 
February 2001. (I'd thought it was October 2000, but it's funny the 
tricks your memory will play.)

As to other definitions of 'established' I haven't followed 
CGI::Application development to say either way. There have been more 
articles published on CGI::Application and it seems to have a larger 
userbase, partly because it's easier to get started with and wrap 
your head around everything it does. Classic trade-off :-)

Good luck!

Chris

--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.

Re: Templating system opinions (CGI::Application in connection witheither HTML::Template or Template::Toolkit)

[Chris Winters]

Dave Rolsky wrote:
There's a fine book about it.

www.masonbook.com

Just an unbiased opinion ;)
Hey, I'd be happy to write a book about OpenInteract ;-)

Chris

--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.

RE: templating system opinions (axkit?)

[csebe]

Hi Jesse,

 -Original Message-
 From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]
 Sent: Monday, July 21, 2003 8:50 PM
 To: 'Patrick Galbraith'
 Cc: [EMAIL PROTECTED]
 Subject: RE: templating system opinions (axkit?)


 Hi Patrick --

  I like the idea of XSLT/XML, though I find myself trying to
  read between
  the lines of hype vs. something that's actually very useful.
  I don't know,
  so I don't have any opinions. I do know I'd like to use
  XSLT/XML so as to
  have a project to use it for, hence learn it.

 It's mostly hype in my experience.  And not even very useful hype, like
 Java or PHP, which are actually real things which people might want to
 use.

 XSLT seems to be XML geeks' answer to CSS+templating.  As if CSS wasn't
 very successful, as if the world needed another templating system, XSLT
 seems to have been invented to take the creative work of designing web
 sites out of the hands of HTML designers, and put it in the hands of
 XPath programmers.  You know.  Programmers who are really good at both
 creative design and communicating with human beings.  Not.

 Alright, pretty smarmy.  But unless you just happen to have thousands of
 XML documents sitting around on your hard drive, XSLT is a solution in
 search of a problem.  Most of my data is in a RDBMS -- not XML.  To
 enhance the *need* for XSLT, some databases will now return XML.  That's
 an interesting idea.  Instead of using a mature language like
 Perl|Java|PHP, let's use something like XSLT to turn my data into a web
 page!  It's new, shiny, and will solve the problem of TOO MANY people
 knowing the other aforementioned languages.  D'oh!

 Too cynical?  Maybe.  The fact that XSLT is still discussed in serious
 company just bugs me.  ;-)


  Not just that, but what about SOAP... Net RPC... I'd like to
  know where
  those fit in as well.

 Fantastic, useful stuff.


  I get so tired of Java types talking about how perl is just
  a scripting
  language.. it's not an application platform/server like
  Dynamo/WebSpere/insert $$$ java non-OS app here. I even
  tried to crack
  a particular Orielly java book and was turned off on a statement like
  Perl is good for proto-typing but not a full application
  server. Yes,
  there are a lot of prototypes getting millions of pageviews a day and
  generating signicifican revenue.

 You hit the nail on the head there:  Prototype in Perl, and then just
 keep using it!  A strategy for the NEW New Economy.


 TTYL,

 -Jesse-


 --

   Jesse Erlbaum
   The Erlbaum Group
   [EMAIL PROTECTED]
   Phone: 212-684-6161
   Fax: 212-684-6226

It's nice to see that I'm not alone ;-)
Without trying to start a religious war, I think all the debate can easily
slip to: Is XML really useful? I mean besides creating new job positions,
new software, new frameworks, new problems to be solved, some overhead over
processing simple text files, etc.
But I shouldn't go in there...

As for Java, unfortunately the Perl community is in my opinion in a no-win
situation. I've seen lots of people in managerial positions hardly knowing
how to read/write their emails using Outlook, not knowing that Perl even
exists, but giving lessons about the Java usefulness; to quote a recent one:
You can't survive on the Internet today without Java.
There is a technical snobbery that is hard to defeat since snobbery itself
is human nature.

But what would I know? Quit cheap philosophy and back to work...

Lian Sebe, M.Sc.
Freelance Analyst-Programmer
www.programEz.net

I'm not mad. I've been in bad mood for the last 30 years...

Re: templating system opinions

[John Saylor]

hi

( 03.07.21 17:04 -0500 ) Nigel Hamilton:
 At Turbo10 we went for a strict 'no functional elements' in the
 template approach.

this seems like you're placing a technical limit on your solution. why
wouldn't you use the technologies that will solve your problem the best
instead of constraining the 'solution space' before considering the
problem fully?

 But how do you do things like loops /loops for displaying rows in a
 report?

exactly. the most intuitive way, to me, is to loop on the page.

-- 
\js

RE: templating system opinions

[Cameron B. Prince]

 Just wondering what the best templating system is to use
 and/or learn.

Hi,

I'm just wondering why no one recommended Embperl. Like Mason, it's more
than a templating system, but I find it's inheritance features great.

I'm using it for a personal project and haven't really checked it's
performance, but there's no doubt it integrates well with mod_perl and
allows you to use existing perl code, packages/objects on your site with
ease.

What do you guys think about it?

Cameron

Re: templating system opinions

[Matt Sergeant]

On Monday, Jul 21, 2003, at 02:23 Europe/London, Dave Rolsky wrote:

All of this said, what is the most commonly used system out there?
The biggest players are Mason and Template Toolkit, judging from big
companies that have used them, as well as job posting.  
HTML::Template,
Embperl, and Apache::ASP all seem to have reasonably active user bases 
as
well.
And lets not forget XML templating solutions too, like XSLT, which 
probably out scores them all in job postings terms (although not all 
that work is perl related).

Matt.

(you can of course use XSLT in AxKit :-)

RE: templating system opinions

[Jesse Erlbaum]

Hi Dave --


Dave Rolsky writes:
  Mason isn't fast. It is, however, fast enough for high 
 volume sites -
  that I will assert.
 
 Sure, amazon.com among them.


Amazon.com uses Mason?  Why have I not heard of this before?


-Jesse-

Re: templating system opinions

[Drew Taylor]

Jesse Erlbaum wrote:
Dave Rolsky writes:
Sure, amazon.com among them.
Amazon.com uses Mason?  Why have I not heard of this before?
I personally have not seen an official announcement, but if you look 
at all their postings on jobs.perl.org you'll notice that nearly every 
one of them mentions Mason. I'm sure Dave will have more to say on the 
subject... :-)

--
-
Drew Taylor  *  Web app development  consulting
[EMAIL PROTECTED]  *  Site implementation  hosting
www.drewtaylor.com   *  perl/mod_perl/DBI/mysql/postgres
-

RE: templating system opinions

[FFabrizio]

  In a good OO system with objects 
 representing the 
 data model, I found it exhausting to use H::T when I could 
 just to this 
 in TT:
 
 [% user.name %]
 
 
 Am I just being stupid, or are there better ways of doing 
 these things 
 in H::T?

I'm a little late to the dance but I generally unplug over the weekend.  We
use H::T here and I too got annoyed with the need to flatten all of my
objects.  However, with so much invested in H::T by that time, we just wrote
a toHash() method which is inherited by all of our objects.  It predictably
takes the object attributes and churns out a hash (and is smart enough to do
a recursive descent if need be).  It also take an optional prefix so that
you could pass in a prefix of user. and then be able to tmpl_var
user.name if you wanted.  It was an easy way to reduce the pain of H::T and
yet not reinvent the wheel.  A simple $tmpl-param($myObj-toHash(prefix =
'user.')) works fairly well in most cases.  I'm sure there's a better/more
robust way to do it (yeah, switch to TT ;-) but we found that this was
sufficient to reduce the annoyance factor enough to allow us to get on with
it.

Also, we use HTML::Template::Expr to cheat liberally where appropriate. :-)
Separation of HTML and logic is a good thing, but like most good things,
there are exceptions.  Since our controllers were starting to get really
cluttered with a lot of if this simple thing is true then pass this boolean
to the template since the template itself can't ask whether this simple
thing is true code, which HTML::Template::Expr helps ease.

Hope that helps.  I really like H::T for it's simplicity and ease of
understanding and picking up for new folks, and didn't want to toss that
away unless I had to.

-Fran

Re: templating system opinions

[Barry Hoggard]

I wanted to add that you *can* use Mason for MVC type programming.  I do 
that on my current big project, www.better-investing.org, in the admin 
areas.  I have a controller index.html page which chooses what component 
to run based on a run mode, just like CGI::Application, but then gives 
me all of the other stuff like autohandlers for the display.

I'm using Template Toolkit and Apache Handlers (which work like 
CGI::Application) for another project.  I'm not sure which I like better 
at the moment.  I'm much faster in Mason still.

--
Barry Hoggard
Tristan Media LLC
e: [EMAIL PROTECTED]
w: www.tristanmedia.com
aim: hoggardb

Re: templating system opinions

[Kip Hampton]

Matt Sergeant wrote:

(you can of course use XSLT in AxKit :-)
And don't forget that, with AxKit, you can use Apache::ASP, Mason, or 
any Apache::Filter-aware handler to provide content for AxKit to 
transform and TT2 as a transformational language. Oh, and there's 
XPathScript, too, which, although its only one part of AxKit, is really 
a novel templating/trasformation language all on its own...

Why choose one when you can have 'em all? :-)

-kip

Re: templating system opinions

[Dave Rolsky]

On Mon, 21 Jul 2003, Drew Taylor wrote:

 I personally have not seen an official announcement, but if you look
 at all their postings on jobs.perl.org you'll notice that nearly every
 one of them mentions Mason. I'm sure Dave will have more to say on the
 subject... :-)

Not too much more.  But hopefully more will be forthcoming from people
closer to Amazon than I.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

Re: templating system opinions

[Patrick Galbraith]

I'm guessing they use it for IMDB, although they may have other 
projects as well that use it. I do know that their core app is 
C++/apache, with some sort of perl glue to talk to the app.

Nice that they are such an apache/perl/OS house considering they're here 
in Seattle, mere miles from Redmond ;) They're also not one of several 
places who think jumping on the java bandwagon is the path to 
enlightenment. Ehem.


 On Mon, 21 Jul 
2003, Dave Rolsky wrote:

 On Mon, 21 Jul 2003, Drew Taylor wrote:
 
  I personally have not seen an official announcement, but if you look
  at all their postings on jobs.perl.org you'll notice that nearly every
  one of them mentions Mason. I'm sure Dave will have more to say on the
  subject... :-)
 
 Not too much more.  But hopefully more will be forthcoming from people
 closer to Amazon than I.
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/
 

-- 
Patrick Galbraith
Senior Software Developer
[EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]

Re: templating system opinions (axkit?)

[Patrick Galbraith]

Anyone on this list use AxKit? I'm curious how it pans out.

I like the idea of XSLT/XML, though I find myself trying to read between 
the lines of hype vs. something that's actually very useful. I don't know, 
so I don't have any opinions. I do know I'd like to use XSLT/XML so as to 
have a project to use it for, hence learn it.

Not just that, but what about SOAP... Net RPC... I'd like to know where 
those fit in as well.

I get so tired of Java types talking about how perl is just a scripting 
language.. it's not an application platform/server like 
Dynamo/WebSpere/insert $$$ java non-OS app here. I even tried to crack 
a particular Orielly java book and was turned off on a statement like 
Perl is good for proto-typing but not a full application server. Yes, 
there are a lot of prototypes getting millions of pageviews a day and 
generating signicifican revenue.

I'd like to see perl/mod_perl reclaim some of the lost ground. 


 On Sun, 20 Jul 2003, Dave 
Rolsky wrote:

 On Sun, 20 Jul 2003, Patrick Galbraith wrote:
 
  I've been working at Classmates.com for a couple months contracting, and
  they use Text::Forge.
 
  I've been impressed by the performance, and wish it was a big player.
  Part of the reason it isn't is guys like me should contribute to it and
  make it a bigger player.
 
 I'd say the big reason it's not a big player is that it doesn't offer
 anything new.  It also doesn't seem to be very actively developed and has
 very little documentation.
 
  I really like the syntax - it looks a lot like JSP.
 
 Yeah, just like Apache::ASP ;)
 
  All of this said, what is the most commonly used system out there?
 
 The biggest players are Mason and Template Toolkit, judging from big
 companies that have used them, as well as job posting.  HTML::Template,
 Embperl, and Apache::ASP all seem to have reasonably active user bases as
 well.
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/
 

-- 
Patrick Galbraith
Senior Software Developer
[EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]

RE: templating system opinions (axkit?)

[Jesse Erlbaum]

Hi Patrick --

 I like the idea of XSLT/XML, though I find myself trying to 
 read between 
 the lines of hype vs. something that's actually very useful. 
 I don't know, 
 so I don't have any opinions. I do know I'd like to use 
 XSLT/XML so as to 
 have a project to use it for, hence learn it.

It's mostly hype in my experience.  And not even very useful hype, like
Java or PHP, which are actually real things which people might want to
use.

XSLT seems to be XML geeks' answer to CSS+templating.  As if CSS wasn't
very successful, as if the world needed another templating system, XSLT
seems to have been invented to take the creative work of designing web
sites out of the hands of HTML designers, and put it in the hands of
XPath programmers.  You know.  Programmers who are really good at both
creative design and communicating with human beings.  Not.

Alright, pretty smarmy.  But unless you just happen to have thousands of
XML documents sitting around on your hard drive, XSLT is a solution in
search of a problem.  Most of my data is in a RDBMS -- not XML.  To
enhance the *need* for XSLT, some databases will now return XML.  That's
an interesting idea.  Instead of using a mature language like
Perl|Java|PHP, let's use something like XSLT to turn my data into a web
page!  It's new, shiny, and will solve the problem of TOO MANY people
knowing the other aforementioned languages.  D'oh!

Too cynical?  Maybe.  The fact that XSLT is still discussed in serious
company just bugs me.  ;-)


 Not just that, but what about SOAP... Net RPC... I'd like to 
 know where 
 those fit in as well.

Fantastic, useful stuff.


 I get so tired of Java types talking about how perl is just 
 a scripting 
 language.. it's not an application platform/server like 
 Dynamo/WebSpere/insert $$$ java non-OS app here. I even 
 tried to crack 
 a particular Orielly java book and was turned off on a statement like 
 Perl is good for proto-typing but not a full application 
 server. Yes, 
 there are a lot of prototypes getting millions of pageviews a day and 
 generating signicifican revenue.

You hit the nail on the head there:  Prototype in Perl, and then just
keep using it!  A strategy for the NEW New Economy.


TTYL,

-Jesse-


--

  Jesse Erlbaum
  The Erlbaum Group
  [EMAIL PROTECTED]
  Phone: 212-684-6161
  Fax: 212-684-6226

Re: templating system opinions

[Dave Rolsky]

On Mon, 21 Jul 2003, Patrick Galbraith wrote:

 I'm guessing they use it for IMDB, although they may have other
 projects as well that use it. I do know that their core app is
 C++/apache, with some sort of perl glue to talk to the app.

I believe IMDB uses mod_perl, but I don't know about Mason.  I know Amazon
is using Mason for _Amazon_, not things they've bought.  They're using it
for the their apparel shop, among other things.

I don't want to say too much more because I'm hoping for a bigger
announcement from more reputable sources, but I can't promise anything ;)


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

Re: templating system opinions (axkit?)

[Douglas Hunter]

Jesse Erlbaum wrote:
Hi Patrick --


I like the idea of XSLT/XML, though I find myself trying to 
read between 
the lines of hype vs. something that's actually very useful. 
I don't know, 
so I don't have any opinions. I do know I'd like to use 
XSLT/XML so as to 
have a project to use it for, hence learn it.


It's mostly hype in my experience.  And not even very useful hype, like
Java or PHP, which are actually real things which people might want to
use.


I don't quite understand what isn't real about XML or XSLT.  XML 
really is a way to structure your data, XSLT really is a way to 
transform that structured data.

But unless you just happen to have thousands of
XML documents sitting around on your hard drive, XSLT is a solution in
search of a problem.  Most of my data is in a RDBMS -- not XML.  


Or, if you have thousands of XML documents sitting around on your hard 
drive, XSLT is an efficient way to translate them into XHTML and deliver 
them to a browser.

You do make a good point that XSLT probably isn't for folks who store 
the all data they are delivering in a RDBMS.  Adding layers onto your 
RDBMS to make it return XML, and then transforming that newly generated 
XML using XSLT may not be the best solution.

But if folks are storing indexed XML documents on their filesystem (a la 
XML::Comma or a similar framework) XSLT can be quite handy.


Too cynical?  Maybe.  The fact that XSLT is still discussed in serious
company just bugs me.  ;-)


Well, I've always considered myself to be pretty light-hearted. 
Sometimes bordering on straight goofy ;-)

TTYL,

-Jesse-
-- Douglas

Re: templating system opinions

[Sam Tregar]

On Sun, 20 Jul 2003, Dave Rolsky wrote:

 OTOH, if you were to try to replicate some of Mason's more powerful
 features with H::T, like autohandlers, inheritance, etc., then I'm
 sure that'd bring H::T's speed down to Mason's level ;)

I wouldn't be too sure.  I implemented a lot of that stuff to add
HTML::Template support to Bricolage and it's still much faster than
Mason.

 In other words, you generally get what you pay for.  The most powerful and
 flexible systems are generally slower and more RAM-hungry.  One exception
 to this might be Embperl, which has large chunks written in C.  In that
 case, the cost is paid for in development time.

HTML::Template::JIT also trades development time (mine) for run-time
speed.  Right now it doesn't support all of HTML::Template's
functionality, but it comes pretty close.  The upside is that it's
between four and eight times faster than HTML::Template, which makes
it the fastest templating system by a large margin.

-sam

Re: templating system opinions

[Dave Rolsky]

On Mon, 21 Jul 2003, Sam Tregar wrote:

 On Sun, 20 Jul 2003, Dave Rolsky wrote:

  OTOH, if you were to try to replicate some of Mason's more powerful
  features with H::T, like autohandlers, inheritance, etc., then I'm
  sure that'd bring H::T's speed down to Mason's level ;)

 I wouldn't be too sure.  I implemented a lot of that stuff to add
 HTML::Template support to Bricolage and it's still much faster than
 Mason.

A lot as in _all_ of it, or a lot as in autohandlers and dhandlers?
I'll believe it when I see it.  There's nothing about Mason that's
particularly slow except the code that implements the features.  In other
words, I don't think one could do all of the same stuff, or even most, and
achieve a huge speed increase.  There would have to be something
sacrificed.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

Re: templating system opinions (axkit?)

[Daisuke Maki]

Anyone on this list use AxKit? I'm curious how it pans out.
I used it for http://www.nikki-site.com (sorry, Japanese-only site). 
This site uses exactly 4 pure-mod_perl handlers, and everything else 
eventually goes through AxKit  (excuse the site design, as far as 
development goes that is a one-man show, and I'm a programmer, not a 
designer ;)

I was keen on leveraging XSLT precisely because I knew that I'd be 
transforming a data source through mod_perl + in a cron job, AND I 
wanted to avoid using Perl on the cronjobs because of the resource 
constraints (puny server).

When a user requests data, AxKit uses a stylesheet to transform it to 
HTML. Meanwhile the same data source is preprocessed a couple of times 
behind the scenes to create derivative data, which is later available 
for users to fetch from Apache. The preprocessing is done using the 
same stylesheet as the one that AxKit, but it is run via multiple calls 
to xsltproc instead of going though Perl. So I get the speed of a 
C-based app using the same stylesheet as mod_perl. I like that ;)

(note for nit-pickers: I admit I didn't do an extensive comparison of 
how it would have faired to use optimized Perl, but the previous 
incarnation of www.nikki-site.com used to take about 3 minutes 
processing the same data -- xsltproc does it in about 13 seconds)

I also like the way AxKit applies transformation. I conceptually think 
of it as a set of filters, and that just fits my mental model. YMMV.

XSP is also very convenient, but I must admit I haven't harnessed its 
entire functionality.

On the other hand I must say that debugging problems on AxKit is pretty 
harsh on beginners. I went in with the mindset that if it was broken I 
was going to make it work, so I didn't have much problem, but that may 
or may not work for you.

Overall I find AxKit to be god-sent for my particular application. 
Things became much easier for me to add to the site, but if you're not 
already familiar with the workings of XML/XSLT, you may need a little 
patience.

--d

Re: templating system opinions (axkit?)

[James G Smith]

Jesse Erlbaum [EMAIL PROTECTED] wrote:
It's mostly hype in my experience.  And not even very useful hype, like
Java or PHP, which are actually real things which people might want to
use.

XSLT seems to be XML geeks' answer to CSS+templating.  As if CSS wasn't
very successful, as if the world needed another templating system, XSLT
seems to have been invented to take the creative work of designing web
sites out of the hands of HTML designers, and put it in the hands of
XPath programmers.  You know.  Programmers who are really good at both
creative design and communicating with human beings.  Not.

Alright, pretty smarmy.  But unless you just happen to have thousands of
XML documents sitting around on your hard drive, XSLT is a solution in
search of a problem.  Most of my data is in a RDBMS -- not XML.  To
enhance the *need* for XSLT, some databases will now return XML.  That's
an interesting idea.  Instead of using a mature language like
Perl|Java|PHP, let's use something like XSLT to turn my data into a web
page!  It's new, shiny, and will solve the problem of TOO MANY people
knowing the other aforementioned languages.  D'oh!

Too cynical?  Maybe.  The fact that XSLT is still discussed in serious
company just bugs me.  ;-)

This is a bit disorganized, but I'm trying to explain why different
things have their place, at least in the work I'm doing.

I am working on a project with the following simplified pipeline in
an MVC environment:

  TT2 - HTML::Mason - AxKit - Client

I use each of these for their strengths.  I don't expect each one to
do everything I need.

We want the people that know our customers the best to be the ones
that provide the content for the site.  These same people are not
programmers.  They do not like programming.  They don't like being
near code for fear they will mess something up.  I will let them edit
TT2 templates.  Since they don't like the Unix editors or CVS, I will
provide (initially) a web interface for editing and a
revision-controlled repository (Gestinanna::POF::Repository).  The
templates will produce XML so the author can concentrate on content and not
worry about presentation.

We want others who understand the processes a customer can understand
to be the ones writing the controllers.  These are XML documents that
define a state machine (StateMachine::Gestinanna) that walk a
customer through a process to get something done (and applying the
right XSLT can create the documentation for the state machine).  But
these same documents do not expose the full Perl language or the
server in the hope of having one less security hole to worry about.
In fact, the applications can usually be prototyped without invoking
the model or having any code run on a state/edge transition.  Once
the process flow is finalized, the model can be tied in.  These are
run in HTML::Mason and determine which template will be used to
produce the XML.

The model is written as a set of Perl modules (e.g.,
Gestinanna::POF).  The authors of these modules are trusted, usually
the same people that are responsible for system security and
operation.  They can have full access to the server.  The modules
provide an OO interface to most business operations controlled by the
controller.

The XML produced by the template is processed by AxKit to produce
HTML, WML, or some other format usable by the customer's client.  The
other benefit of XSLT is that like content is treated in a consistent
manner in the end document.  Customers can always expect a particular
content type to be in a particular format for a given document type
without the person writing the content having to constantly check
their work against a style sheet.  If the person responsible for the
layout and look of the site changes something, only the XSLT and CSS
have to be changed.  Usually, only the CSS has to be changed unless
there are major structural changes to the site.

The look and layout of the site is done in Photoshop, not in IE.
This allows someone that does know XSLT to go in and make sure the
resulting HTML matches for a wide range of browsers what was done in
Photoshop.  We also tend to stick with the W3C recommendations
instead of relying on proprietary features/bugs.  Of course, we're
also a state institution under certain legal restrictions regarding
what we can do on the web.

So

I'm using TT2, HTML::Mason and AxKit to work on a site using XML and
XSLT.  Each has its role based on personnel constraints that are
outside the technical requirements of the project.  Even so, it
results in a highly customizable application that requires little
effort at any particular point.  I'm working on throwing SOAP and
Jabber into the mix as well.

I haven't done any performance tuning yet.  The primary focus of the
application is security, then maintainability, then usability.
-- 
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix

Re: templating system opinions

[Perrin Harkins]

On Mon, 2003-07-21 at 12:22, Kip Hampton wrote:
 And don't forget that, with AxKit, you can use Apache::ASP, Mason, or 
 any Apache::Filter-aware handler to provide content for AxKit to 
 transform and TT2 as a transformational language. Oh, and there's 
 XPathScript, too, which, although its only one part of AxKit, is really 
 a novel templating/trasformation language all on its own...
 
 Why choose one when you can have 'em all? :-)

Well, no offense to AxKit, but having multiple templating systems in a
single project is something that I specifically work to avoid.  It
complicates things and typically hurts performance.  If I had an
Apache::ASP app and wanted to use XSLT, I would just use the built-in
support for it.  If I had a Mason app, I would use XML::libXSLT
directly.

- Perrin

Re: templating system opinions (axkit?)

[Perrin Harkins]

On Mon, 2003-07-21 at 12:14, Patrick Galbraith wrote:
 I get so tired of Java types talking about how perl is just a scripting 
 language.. it's not an application platform/server like 
 Dynamo/WebSpere/insert $$$ java non-OS app here. I even tried to crack 
 a particular Orielly java book and was turned off on a statement like 
 Perl is good for proto-typing but not a full application server. Yes, 
 there are a lot of prototypes getting millions of pageviews a day and 
 generating signicifican revenue.
 
 I'd like to see perl/mod_perl reclaim some of the lost ground. 

Yahoo and Amazon both use perl much more than they use Java.  eBay is
going Java (from C++), but it's costing them millions and taking years.
Ticket Master and CitySearch are both Perl.  It looks to me like there
is very little evidence to support the claim that Java is in any way
better for building high-volume sites.

- Perrin

Re: templating system opinions

[Sam Tregar]

On Mon, 21 Jul 2003, Dave Rolsky wrote:

 On Mon, 21 Jul 2003, Sam Tregar wrote:
 
  I wouldn't be too sure.  I implemented a lot of that stuff to add
  HTML::Template support to Bricolage and it's still much faster than
  Mason.
 
 A lot as in _all_ of it, or a lot as in autohandlers and dhandlers?

A lot as in everything that was needed to get HTML::Template to fill
the role of Mason in Bricolage's publish process.  I'd certainly be a
fool to claim I'd implemented all of Mason!  I doubt I could even list
all the stuff that Mason does.

 In other words, I don't think one could do all of the same stuff, or
 even most, and achieve a huge speed increase.  There would have to
 be something sacrificed.

My impression is that Mason doesn't get much advantage from clients
that only use part of the Mason system.  I imagine that one of the
reasons that the Mason workalike I built for Bricolage is faster than
Mason is that it only implements the functionality actually needed by
Bricolage.  Following this line of thinking it might be possible to
modify Mason to only use/load the slower/bigger pieces when they are
actually needed.  Of course, I'm no authority on why Mason is slow or
how it could be fixed.

I have plans to go a similar route with HTML::Template in the future.
I'd like to build a system that dynamically assembles itself based on
the usage pattern of the program.  That way if the programmer sticks
to the basics they get a smaller, faster system.  If they need the big
guns then the more complete systems can be loaded at some moderate
penalty.

-sam

Re: templating system opinions

[Kip Hampton]

Perrin Harkins wrote:

On Mon, 2003-07-21 at 12:22, Kip Hampton wrote:

Why choose one when you can have 'em all? :-)


Well, no offense to AxKit, but having multiple templating systems in a
single project is something that I specifically work to avoid.  It
complicates things and typically hurts performance.  
Developer time is always more costly than bigger iron so I prefer 
environments that let people use the tools that they know and can be 
nore rapidly productive with. AxKit lets me choose, and If I don't need 
it, I don't use it (or load it) but if I do, then its available.

If I had an
Apache::ASP app and wanted to use XSLT, I would just use the built-in
support for it.  If I had a Mason app, I would use XML::libXSLT
directly.
Certainly, and you wouldn't be wrong to do so. However, the instant you 
want to start applying different styles to content based on 
environemental conditions, or setting up chains of transformations, then 
you begin duplicating logic in your app code that AxKit already does 
well behind the scenes by adding a directive or two to your httpd.conf.

Horses for courses as the saying goes; personally, I prefer having 
more choices.

-kip

Re: templating system opinions

[Chris Winters]

Perrin Harkins wrote:
The one thing about TT was that I don't know if I really liked how it 
had a different syntax than perl. Plus, as far as performance, we did 
some specific coding to make it faster for Slash so our templates would 
be in the DB.
That's an anti-optimization.  Filesystems are faster than databases when
all you want is to fetch a single item with a specific name.  It's also
a pain in the ass to edit things that are in a database, as opposed to
just files.
I agree -- filesystems have all these great new remote access 
protocols like ftp and scp. That's why I took this option (storing 
templates in the database) out of OpenInteract. Well, actually you 
can still do it, I just make it really tough :-)

Chris

--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.

RE: templating system opinions

[Nigel Hamilton]

  Just wondering what the best templating system is to use
  and/or learn.
 
 I'm just wondering why no one recommended Embperl. Like Mason, it's more
 than a templating system, but I find it's inheritance features great.

I too have found template inheritance to be pretty important - especially
the ability to override enclosing templates.

At Turbo10 we went for a strict 'no functional elements' in the template
approach.

But how do you do things like loops /loops for displaying rows in a
report?

The content management system models a HTML page (e.g., Object - Master
Template - Page - Form - Subform).

A presentation script is responsible for inserting the rows into the page
and master template. Attributes (e.g., bgcolor) of an enclosing object
(e.g., page) are inherited (or overridden) by an enclosed object (e.g.,
form). 

Each object is stored in an XMLish file, slurped into a hash, and the keys
are merged.

Typically a DBI row hash is also merged as there is a 1-1 correspondence 
between database column names and form attributes.

I think the question of templating solution depends on the plan for the
content management system ...



NIge


-- 
Nigel Hamilton
Turbo10 Metasearch Engine

email:  [EMAIL PROTECTED]
tel:+44 (0) 207 987 5460
fax:+44 (0) 207 987 5468

http://turbo10.com  Search Deeper. Browse Faster.

RE: templating system opinions

[Cameron B. Prince]

 Just wondering what the best templating system is to use
 and/or learn.

Hi,

I'm just wondering why no one recommended Embperl. Like Mason, it's more
than a templating system, but I find it's inheritance features great.

I'm using it for a personal project and haven't really checked it's
performance, but there's no doubt it integrates well with mod_perl and
allows you to use existing perl code, packages/objects on your site with
ease.

What do you guys think about it?

Cameron

Re: templating system opinions

[Jamie Lawrence]

On Fri, 18 Jul 2003, Dave Rolsky wrote:

 On Fri, 18 Jul 2003, Patrick Galbraith wrote:
 
  TT was ok, but it did use a bunch of ram ;)
 
 So does Mason.  HTML::Template is no doubt much leaner, but it's also lean
 on features.  Nothing wrong with that if it suits your needs, though.
 
 Most Perl templating systems are probably slower and/or bulkier than PHP.
 
 The best counter for PHP folks is one word, CPAN ;)
 
 Also, Mason at least provides lots of features beyond templating, and is
 as much of an app framework as anything.  This may be true of TT and the
 others, I'm not really sure.


Just to chime in here, Mason is very much a framework. It expresses a
particular view of web site development. I'm a huge fan of it,
personally, but putting that aside, Mason is mainly about finding the
proper balance between code monkey and html monkey. The slightly amusng
thing, and what I take as a vote for Mason having found the balance, is
that radically different styles of coding have evolved - I recently
downloaded the code behind www.masonhq.com, and compared it to how we do
things, and was shocked and appalled. And picked up some really good
ideas... In general, Mason allows an HTMLer to become more of a
programmer, and also requires programmers to be HTML savvy, or at least
HTML sensitive. I find this a good thing.

H::T is much more programmer-centric. In a lot of contexts, that makes
sense. Informally (as in, I haven't done a systematic comparison), it is
also faster than Mason. Mason isn't slow, but if you need every last
gram of performance, well, you probably shouldn't be using a general
framework anyway.

And yes, they're all RAM-intensive. I don't actually care that much -
RAM is cheap for general purpose servers.

Just buzzing in with opinion - which is what I think the original poster
was soliciting. HTH, my $.02, not a holy warrior, etc.

-j

-- 
Jamie Lawrence[EMAIL PROTECTED]
The significant problems we face cannot be solved by the same level of 
thinking that created them.
   - Albert Einstein

Re: templating system opinions

[Dave Rolsky]

On Sun, 20 Jul 2003, Jamie Lawrence wrote:

 H::T is much more programmer-centric. In a lot of contexts, that makes
 sense. Informally (as in, I haven't done a systematic comparison), it is
 also faster than Mason. Mason isn't slow, but if you need every last
 gram of performance, well, you probably shouldn't be using a general
 framework anyway.

 And yes, they're all RAM-intensive. I don't actually care that much -
 RAM is cheap for general purpose servers.

Actually, H::T is almost certainly _much_ faster and less RAM-intensive
than Mason, at least when you measure the time it takes to serve a single
page/component.  OTOH, if you were to try to replicate some of Mason's
more powerful features with H::T, like autohandlers, inheritance, etc.,
then I'm sure that'd bring H::T's speed down to Mason's level ;)

In other words, you generally get what you pay for.  The most powerful and
flexible systems are generally slower and more RAM-hungry.  One exception
to this might be Embperl, which has large chunks written in C.  In that
case, the cost is paid for in development time.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

Re: templating system opinions

[Ruslan U. Zakirov]

 Barry Hoggard wrote:
 I used to use HTML::Template for projects, but I moved to
 Template::Toolkit because I felt the former's syntax was just too 
 limited.  I know we want to separate code and logic, but H::T 
 keeps me 

[skip]
JE Jesse Erlbaum
JE   Programmer: Get object, Get object attribute
JE   HTML Designer: Display attribute
JE This is no more than a philosophical difference.  HTML::Template assumes
JE HTML designers should never do programming tasks, and implements this
JE philosophy by not opening the code floodgate at all.  TT believes that
JE there is some amount of code you want your designer to do.

[skip]

  Hello.
Absolutely agree with Jesse.
I've started with my own simple templating module, but step by step I've
come to HT.
Why HT?
1) It isn't framework, just templates. I'm trying to write my own
framework.
2) Relatively fast.
3) Separate code and design.
4) Enough simple syntax to designers.
When I was doing selection I just read comparison from
perl.apache.org. Satisfied with the choice still.

   Best regards, Ruslan.

Re: templating system opinions

[Jamie Lawrence]

On Sun, 20 Jul 2003, Dave Rolsky wrote:

 Actually, H::T is almost certainly _much_ faster and less RAM-intensive
 than Mason, at least when you measure the time it takes to serve a single
 page/component.  OTOH, if you were to try to replicate some of Mason's
 more powerful features with H::T, like autohandlers, inheritance, etc.,
 then I'm sure that'd bring H::T's speed down to Mason's level ;)

Fair enough. I haven't actually deployed anything under H::T. I've
played with it, and some of it I like. I have stolen part of it for
deployment, but it ended up really mangled and site specific, so that
doesn't count.

Mason isn't fast. It is, however, fast enough for high volume sites -
that I will assert.

From my view, the utility of autohandlers and dhandlers, in terms of
code written vs. cost and time, is an enormous win. Add to that the
flexibility between library developmers and HTML coders, in that there's
a constant feedback loop that enforces reasonable development and
interaction to ensure that all roles are working for the same goal.

And in general, I don't care about RAM. A 1G server is cheap. Tune
apache properly and you have no problems for sites approaching .25M
visits/day. If you need to exceed that, you need multiple front-end
boxes. But if you're doing that amount of traffic, you probably need
redundancy anyway, so the issue is moot.

 In other words, you generally get what you pay for.  The most powerful and
 flexible systems are generally slower and more RAM-hungry.  One exception
 to this might be Embperl, which has large chunks written in C.  In that
 case, the cost is paid for in development time.

Agreed. 

In general, I love Mason, but still do write mod_perl interfaces for
some things, when performance is important. For that matter, I push a
lot of work onto the database, and then write C extensions to it to
handle specific performance problems. Apache, perl, mason, postgres is a
kickass combination, where you can fix almost any problem, quickly and
cheaply. As usual, this pushes back at the developer, who is obligated
to make the right choice. It is certainly not the only choice, but it is
the right one(tm) for me.

Again, I'm offering opinion, based on my particular experiences. Nothing
more, nothing less.

-j, who used to run custom NSAPI modules talking to Oracle under NES under 
high loads, and is an unabashed fan of mod_perl. shudder



-- 
Jamie Lawrence[EMAIL PROTECTED]
People should be allowed to keep midgets as pets.
- Gov. Jesse Ventura

Re: templating system opinions

[Patrick Galbraith]

I've been working at Classmates.com for a couple months contracting, and 
they use Text::Forge.

I've been impressed by the performance, and wish it was a big player. 
Part of the reason it isn't is guys like me should contribute to it and 
make it a bigger player.

I really like the syntax - it looks a lot like JSP.

They serve out around 12-13M pageviews a day using it. It just doesn't 
have a lot of active contributors to it now.

Eventually, they will switch to java/atg dynamo. ...

All of this said, what is the most commonly used system out there?

Jesse Erlbaum wrote:
Hi Chris, Patrick --

I post on this topic with some reluctance.  Asking which templating
system is best is like asking which operating system is best -- or which
political party is best (or political system, I suppose).  It's Jihad,
baby!
OTOH, I've never met a flamethrower I didn't like.



What's best depends on what your requirements are. As far 
as I can tell,
the big ones are Template::Toolkit, Mason, and 
HTML::Template


One picky point:  Mason is NOT a templating system.  It is a programming
system.
If you're going to call Mason a templating system, you might as well
refer to Perl as a templating system:
  my $name = Jesse;
  print Hello, my name is $name\n;
Presto, blammo -- a new templating system!

The big players are Template::Toolkit and HTML::Template.  It's no
secret that I'm a fan of HTML::Template -- Sam and I worked together
when he wrote it, and my module, CGI::Application, uses it out of the
box (although it does support TT).  

I use HTML::Template because designers can't be trusted to set
variables.  Boolean logic is about all their simple minds can handle.
Anything which doesn't look like HTML is likely to cause them to have a
stroke.  Yes, I'm a programmer-snob and a fascist, and I like to take
sharp objects away from the gentle creative types.
Aside from the fact that HTML::Template uses less RAM and is faster than
TT, this is the foremost reason I continue to use it.
TTYL,

-Jesse-

--

  Jesse Erlbaum
  The Erlbaum Group
  [EMAIL PROTECTED]
  Phone: 212-684-6161
  Fax: 212-684-6226



--
--
Patrick Galbraith
Senior Software Developer
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]
206.719.2461

Re: templating system opinions

[Dave Rolsky]

On Sun, 20 Jul 2003, Patrick Galbraith wrote:

 I've been working at Classmates.com for a couple months contracting, and
 they use Text::Forge.

 I've been impressed by the performance, and wish it was a big player.
 Part of the reason it isn't is guys like me should contribute to it and
 make it a bigger player.

I'd say the big reason it's not a big player is that it doesn't offer
anything new.  It also doesn't seem to be very actively developed and has
very little documentation.

 I really like the syntax - it looks a lot like JSP.

Yeah, just like Apache::ASP ;)

 All of this said, what is the most commonly used system out there?

The biggest players are Mason and Template Toolkit, judging from big
companies that have used them, as well as job posting.  HTML::Template,
Embperl, and Apache::ASP all seem to have reasonably active user bases as
well.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

Re: templating system opinions

[Dave Rolsky]

On Sun, 20 Jul 2003, Jamie Lawrence wrote:

 Mason isn't fast. It is, however, fast enough for high volume sites -
 that I will assert.

Sure, amazon.com among them.

 From my view, the utility of autohandlers and dhandlers, in terms of
 code written vs. cost and time, is an enormous win. Add to that the
 flexibility between library developmers and HTML coders, in that there's
 a constant feedback loop that enforces reasonable development and
 interaction to ensure that all roles are working for the same goal.

I'm not gonna disagree with you.  I consider Mason's features well worth
the speed/memory costs.  That's why I use it and develop it ;)


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

RE: templating system opinions

[Jesse Erlbaum]

Hey Ken --

 Search the guide:
 
http://perl.apache.org/search/swish.cgi?query=templatesbm=submit=sear
ch


I'm deeply amused that there are nearly as many articles about
templating systems on perl.apache.org (30) as there are templating
modules on CPAN!


TTYL,

-Jesse-


--

  Jesse Erlbaum
  The Erlbaum Group
  [EMAIL PROTECTED]
  Phone: 212-684-6161
  Fax: 212-684-6226

RE: templating system opinions

[Jesse Erlbaum]

Hi Patrick --

 I gotta have something to counter PHP people with too ;)

Dave is right:  CPAN is a very compelling argument.

OTOH, it you've already cast your lot with using a server page system
(a la Mason, ASP, JSP, ColdFusion), PHP is a pretty compelling choice.
It's new, sexy, lightweight, more or less capable, and has lots of buzz.

  However:  Another compelling argument in favor of Perl (against PHP)
is an argument in favor of using an controller-based system instead of a
server page system.

A controller-based system (such as CGI::Application or mod_perl
handlers) combined with a true templating system, such as TT or
HTML::Template, makes the templates subservient to the application
logic.

This is the opposite of server page systems which put the template in
change of choosing functionality.  In the latter, an HTTP request goes
to a template which controls execution.  If the template in this system
decides that a different template should be displayed, chaos erupts --
redirect city, snarls of spaghetti code.

In a controller-based system, the HTTP request goes to a controller
which runs the logic and then chooses a template.  This is a more
rational chain of events, allowing the form to *follow* function --
literally.  The controller can naturally choose which template without
having to twist itself in a pretzel to do so.


Add to that the fact that in spite of the claim that it is possible to
separate code from HTML in a server page system, in reality it is too
difficult and nobody does it.


OTOH, if you can't fight the PHP wave, here's an alternative:

  Offer to prototype the system in Perl, and migrate it to PHP!

It so happens that a fellow named Tomas Styblo ([EMAIL PROTECTED]) wrote a
version of HTML::Template for PHP:

  http://htmltmpl.sourceforge.net/


This means that you could quickly, and cheaply get a system up and
running with Perl and HTML::Template, and migrate it eventually to PHP.
(If the prototype happens to be so good that it takes the wind out of
the sails of migration, so be it.)


TTYL,

-Jesse-


--

  Jesse Erlbaum
  The Erlbaum Group
  [EMAIL PROTECTED]
  Phone: 212-684-6161
  Fax: 212-684-6226

Re: templating system opinions - Mason recommendation

[Randal L. Schwartz]

 Stas == Stas Bekman [EMAIL PROTECTED] writes:

Stas While Andy is working on it, you can read a TT for mod_perl chapter in
Stas Practical mod_perl, written by Andy as well! (http://modperlbook.org)

Man, that guy is *everywhere*!

:-)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: templating system opinions

[Barry Hoggard]

Jesse Erlbaum wrote:

The big players are Template::Toolkit and HTML::Template.  It's no
secret that I'm a fan of HTML::Template -- Sam and I worked together
when he wrote it, and my module, CGI::Application, uses it out of the
box (although it does support TT).  

I use HTML::Template because designers can't be trusted to set
variables.  Boolean logic is about all their simple minds can handle.
Anything which doesn't look like HTML is likely to cause them to have a
stroke.  Yes, I'm a programmer-snob and a fascist, and I like to take
sharp objects away from the gentle creative types.
Aside from the fact that HTML::Template uses less RAM and is faster than
TT, this is the foremost reason I continue to use it.
I used to use HTML::Template for projects, but I moved to 
Template::Toolkit because I felt the former's syntax was just too 
limited.  I know we want to separate code and logic, but H::T keeps me 
from even referencing the attribute of an object.  You can't say

TMPL_VAR NAME=user.name

and pass in a user object with the attribute (method) or even a hash key 
called name.  You have to either treating it like a loop with one item 
(because loops use arrayrefs of hashrefs) or flatten it into variable 
names in your code.  In a good OO system with objects representing the 
data model, I found it exhausting to use H::T when I could just to this 
in TT:

[% user.name %]

Am I just being stupid, or are there better ways of doing these things 
in H::T?



--
Barry Hoggard
Tristan Media LLC
e: [EMAIL PROTECTED]
w: www.tristanmedia.com
aim: hoggardb

Re: templating system opinions

[Stas Bekman]

Jesse Erlbaum wrote:
Hey Ken --


Search the guide:

http://perl.apache.org/search/swish.cgi?query=templatesbm=submit=sear
ch

I'm deeply amused that there are nearly as many articles about
templating systems on perl.apache.org (30) as there are templating
modules on CPAN!
The search shows matching sections, not articles. Most of these matches belong 
to a single tutorial:
http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: templating system opinions

[Ken Y. Clark]

On Fri, 18 Jul 2003, Patrick Galbraith wrote:

 Date: Fri, 18 Jul 2003 14:25:32 -0700 (PDT)
 From: Patrick Galbraith [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: templating system opinions

 Hi there,

 Just wondering what the best templating system is to use and/or learn.

 I've briefly read up on the pros and cons of each, and am just wondering
 which one is the most widely _used_ and best to learn if you're wanting to
 know something that there are jobs for.

 thanks ;)

Search the guide:

http://perl.apache.org/search/swish.cgi?query=templatesbm=submit=search

ky

Re: templating system opinions

[Chris Devers]

On Fri, 18 Jul 2003, Patrick Galbraith wrote:

 Just wondering what the best templating system is to use and/or learn.

 I've briefly read up on the pros and cons of each, and am just wondering
 which one is the most widely _used_ and best to learn if you're wanting to
 know something that there are jobs for.

What's best depends on what your requirements are. As far as I can tell,
the big ones are Template::Toolkit, Mason, and HTML::Template; each one
makes different tradeoffs and makes different assumptions about the
division of labor among programmers, web developers,  content producers.
TT is probably the most flexible, but that or might not be what you want.

Honestly, of the three I just listed, none of them are *that* complicated.
If you want to learn these for job hunting purposes -- in which case it's
not really fair to ask you what the requirements are, since you can't
really know that -- you might as well experiment with all three.

A good way to start might be by playing with different content management
etc platforms that use these toolkits. From what I've read, the biggest
examples I can think of are:

 * Slashcode (TT based, runs slashdot.org)

 * Bricolage (H::T, http://www.bricolage.cc/docs/Bric/HTMLTemplate.html,
   CMS used by theregister.co.uk et al)

 * Request Tracker (excellent ticketing system, runs http://rt.cpan.org/,
   home page is http://www.bestpractical.com/rt)

Any of these can be downloaded  used freely. If you have the time for it,
grab a copy of one or more and start playing around.

Have fun :)


-- 
Chris Devers [EMAIL PROTECTED]
http://devers.homeip.net:8080/

drag'n'drop, v.
To throw away your mouse after the first attempt to copy a file leads
to its deletion. See also TRASH CAN.

-- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995

Re: templating system opinions

[Mark Maunder]

Hey Peter,

Template Toolkit rocks! (Sorry about the overt glee, but I am just
finishing a project where it has been very good to me) Besides the
complete seperation that it gives you between presentation and back-end
coding, it's super fast. I benchmarked a 2GHz server with 256 Megs of
RAM using ab (Apache bench) with around 10 concurrent requests and a
total of 10,000 requests and was able to handle over 40 hits per second
on our most dynamic page which has lots of conditionals and loops and
even does a few function calls like this [% IF sess.is_logged_in %]
where 'sess' is a perl object. NOTE: Make sure you cache your template
object in package globals or something like that, or you'll lose
performance.

I've written a couple of workable templating systems myself with good
old $html =~ s///egs and a content handler (as a perl developers rite of
passage don't ya know) and I wouldn't recommend it because you end up
with something non-standard, and are basically re-inventing template
toolkit which seems to have become the standard in templating over the
last coupla years.

Old, but still useful benchmarks if you're interested:
http://www.chamas.com/bench/

mark.

On Fri, 2003-07-18 at 13:26, Ken Y. Clark wrote:
 On Fri, 18 Jul 2003, Patrick Galbraith wrote:
 
  Date: Fri, 18 Jul 2003 14:25:32 -0700 (PDT)
  From: Patrick Galbraith [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Subject: templating system opinions
 
  Hi there,
 
  Just wondering what the best templating system is to use and/or learn.
 
  I've briefly read up on the pros and cons of each, and am just wondering
  which one is the most widely _used_ and best to learn if you're wanting to
  know something that there are jobs for.
 
  thanks ;)
 
 Search the guide:
 
 http://perl.apache.org/search/swish.cgi?query=templatesbm=submit=search
 
 ky
-- 
Mark Maunder [EMAIL PROTECTED]
ZipTree Inc.

Re: templating system opinions - Mason recommendation

[Chris Devers]

Sorry to cc: this to the list, but I stand corrected and might as well
mention that to the list :)


On Fri, 18 Jul 2003, Dave Baker wrote:

 Correction: Bricolage is written in Mason, I believe. That's what the
 Bricolage authors say at http://bricolage.cc/

Hmm, so it does. I wonder where I got the idea that it was H::T based...

 I'm very pleased with Mason -- the online O'Reilly book about Mason is
 at http://www.masonbook.com/book/

A little bird tells me that TT is about to get an O'Reilly book as well,
though it's not on their upcoming titles page (yet).

The only H::T dead-trees material that I know of is a section in _CGI
Programming with Perl_, 2nd edition -- that's where I learned it. I like
the simplicity of H::T, but most other people seem to prefer TT or Mason.
I still think it comes down to whichever system meets your needs the best,
and in different contexts any of them (or others) could be appropriate.


This may have been covered before here, but Zope supports an interesting
template mechanism called TAL, where everything is done by attributes for
the HTML tags, rather than special logical tags as most other systems use
(e.g. the ones mentioned above, SSI, PHP, ASP, JSP, etc). This has the
nice side effect of guaranteeing that all your html templates are always
valid, and so can be used in any html IDE without complication. So for
example, picking a random sample from the spec:


Repeat

  Syntax:
   argument  ::= variable_name expression
   variable_name ::= Name

  When you want to replicate a subtree of your document once for each
  item in a sequence, you use repeat.  The expression should evaluate
  to a sequence. If the sequence is empty, then the statement element
  is deleted, otherwise it is repeated for each value in the sequence.
  If the action is cancelled, then the element is left unchanged, and
  no new variables are defined.

  The variable_name is used to define a local variable and a repeat
  variable. For each repetition, the local variable is set to the
  current sequence element, and the repeat variable is set to an
  iteration object.  You use iteration objects to access information
  about the current repetition (such as the repeat index).
  (Iteration objects are more properly the domain of TALES.)  The
  repeat variable has the same name as the local variable, but is
  only accessible through the builtin variable named repeat (see
  RepeatVariable).

  Examples:

p tal:repeat=txt python:'one', 'two', 'three'
   span tal:replace=txt /
/p
table
  tr tal:repeat=item here/cart
  td tal:content=repeat/item/index1/td
  td tal:content=item/descriptionWidget/td
  td tal:content=item/price$1.50/td
  /tr
/table


It's a pretty clever approach; I'd like to see something like this done
with a Perl backend (I haven't really been keeping track of development,
for all I know there already is a Perl backend...). Read more:

  http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL
  http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4


But anyway, Zope isn't mod_perl, so that's probably not what the original
person was hoping to read about... :)



-- 
Chris Devers[EMAIL PROTECTED]

Re: templating system opinions - Mason recommendation

[Leon Brocard]

Chris Devers sent the following bits through the ether:

 It's a pretty clever approach; I'd like to see something like this done
 with a Perl backend (I haven't really been keeping track of development,
 for all I know there already is a Perl backend...). Read more:

Your wish is my command. Witness the amazing appearance of Petal -
Perl Template Attribute Language - TAL for Perl! on the rather
tastefully-coloured:
http://search.cpan.org/author/JHIVER/Petal-1.00/lib/Petal.pm

Leon
-- 
Leon Brocard.http://www.astray.com/
scribot.http://www.scribot.com/

... Have you seen Quasimoto? I have a hunch he's back!

Re: templating system opinions

[Patrick Galbraith]

Thanks much,

Yeah, I worked with TT when I was on the Slash team ;) 

On Fri, 18 Jul 2003, 
Chris Devers wrote:

 On Fri, 18 Jul 2003, Patrick Galbraith wrote:
 
  Just wondering what the best templating system is to use and/or learn.
 
  I've briefly read up on the pros and cons of each, and am just wondering
  which one is the most widely _used_ and best to learn if you're wanting to
  know something that there are jobs for.
 
 What's best depends on what your requirements are. As far as I can tell,
 the big ones are Template::Toolkit, Mason, and HTML::Template; each one
 makes different tradeoffs and makes different assumptions about the
 division of labor among programmers, web developers,  content producers.
 TT is probably the most flexible, but that or might not be what you want.
 
 Honestly, of the three I just listed, none of them are *that* complicated.
 If you want to learn these for job hunting purposes -- in which case it's
 not really fair to ask you what the requirements are, since you can't
 really know that -- you might as well experiment with all three.
 
 A good way to start might be by playing with different content management
 etc platforms that use these toolkits. From what I've read, the biggest
 examples I can think of are:
 
  * Slashcode (TT based, runs slashdot.org)
 
  * Bricolage (H::T, http://www.bricolage.cc/docs/Bric/HTMLTemplate.html,
CMS used by theregister.co.uk et al)
 
  * Request Tracker (excellent ticketing system, runs http://rt.cpan.org/,
home page is http://www.bestpractical.com/rt)
 
 Any of these can be downloaded  used freely. If you have the time for it,
 grab a copy of one or more and start playing around.
 
 Have fun :)
 
 
 

-- 
Patrick Galbraith
Senior Software Developer
[EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]

Re: templating system opinions

[Patrick Galbraith]

The one thing about TT was that I don't know if I really liked how it 
had a different syntax than perl. Plus, as far as performance, we did 
some specific coding to make it faster for Slash so our templates would 
be in the DB.

On 18 Jul 2003, Mark Maunder wrote:

 Hey Peter,
 
 Template Toolkit rocks! (Sorry about the overt glee, but I am just
 finishing a project where it has been very good to me) Besides the
 complete seperation that it gives you between presentation and back-end
 coding, it's super fast. I benchmarked a 2GHz server with 256 Megs of
 RAM using ab (Apache bench) with around 10 concurrent requests and a
 total of 10,000 requests and was able to handle over 40 hits per second
 on our most dynamic page which has lots of conditionals and loops and
 even does a few function calls like this [% IF sess.is_logged_in %]
 where 'sess' is a perl object. NOTE: Make sure you cache your template
 object in package globals or something like that, or you'll lose
 performance.
 
 I've written a couple of workable templating systems myself with good
 old $html =~ s///egs and a content handler (as a perl developers rite of
 passage don't ya know) and I wouldn't recommend it because you end up
 with something non-standard, and are basically re-inventing template
 toolkit which seems to have become the standard in templating over the
 last coupla years.
 
 Old, but still useful benchmarks if you're interested:
 http://www.chamas.com/bench/
 
 mark.
 
 On Fri, 2003-07-18 at 13:26, Ken Y. Clark wrote:
  On Fri, 18 Jul 2003, Patrick Galbraith wrote:
  
   Date: Fri, 18 Jul 2003 14:25:32 -0700 (PDT)
   From: Patrick Galbraith [EMAIL PROTECTED]
   To: [EMAIL PROTECTED]
   Subject: templating system opinions
  
   Hi there,
  
   Just wondering what the best templating system is to use and/or learn.
  
   I've briefly read up on the pros and cons of each, and am just wondering
   which one is the most widely _used_ and best to learn if you're wanting to
   know something that there are jobs for.
  
   thanks ;)
  
  Search the guide:
  
  http://perl.apache.org/search/swish.cgi?query=templatesbm=submit=search
  
  ky
 

-- 
Patrick Galbraith
Senior Software Developer
[EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]

Re: templating system opinions

[Chris Devers]

On Fri, 18 Jul 2003, Patrick Galbraith wrote:

 Yeah, I worked with TT when I was on the Slash team ;)

Then why are you asking a question like this?? :)


-- 
Chris Devers [EMAIL PROTECTED]
http://devers.homeip.net:8080/

Turing machine, n. [After Alan M. Turing (1912-1954), British
  mathematician and computer pioneer.]
The earliest but still the fastest and most reliable computing system
ever conceived. Dis maschine vill run und run (K. Godel).

-- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995

Re: templating system opinions

[Patrick Galbraith]

TT was ok, but it did use a bunch of ram ;)

I gotta have something to counter PHP people with too ;)

On Fri, 18 Jul 2003, Chris 
Devers wrote:

 On Fri, 18 Jul 2003, Patrick Galbraith wrote:
 
  Yeah, I worked with TT when I was on the Slash team ;)
 
 Then why are you asking a question like this?? :)
 
 
 

-- 
Patrick Galbraith
Senior Software Developer
[EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]

Re: templating system opinions

[Dave Rolsky]

On Fri, 18 Jul 2003, Patrick Galbraith wrote:

 TT was ok, but it did use a bunch of ram ;)

So does Mason.  HTML::Template is no doubt much leaner, but it's also lean
on features.  Nothing wrong with that if it suits your needs, though.

Most Perl templating systems are probably slower and/or bulkier than PHP.

The best counter for PHP folks is one word, CPAN ;)

Also, Mason at least provides lots of features beyond templating, and is
as much of an app framework as anything.  This may be true of TT and the
others, I'm not really sure.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/