I think you're seriously overestimating the amount of programming involved in the templates in Petal. It's deliberately designed to stop you from doing anything more than substitutions, loops over an array and conditionals. It is not a turing complete language.

As for the mini-language for manipulating references, the only rule for the language is / means go down another level so a/b/c is $h->{a}->{b}->{c}. It hardly deserves the name mini-language.

Imagine a page with 20 variables. The templates look almost exactly the same for Petal and Seamstress but Seamstress also requires 40 almost identical lines of Perl to find the ids and replace them.

This means that each ID tag has to appear twice, once in the template and once in your Perl, plenty of opportunity for typos. Lets say you decide that your template should display a field that was previously omitted. Now you have to change your template _and_ add 2 more lines of Perl to make sure it gets replaced.

I don't like mini-languages either but I would quickly become bored writing a find line and a replace line for each datum. I'd probably decide on a convention for the id tags so that the the id taq can be interpreted as a path down into a hash of data. At which point I'd have basically invented the main part of TAL. Mini-languages are bad but I'll take a small, tight mini-language any day over lines and lines of cookie cutter coding.

Imagine a page with 20 variables. The templates look almost exactly the same for Petal and Seamstress but Seamstress also requires 40 almost identical lines of Perl to find the ids and replace them.

Actually, I believe your assessment is based on my slow, plodding
examples which dont use the convenience methods in
HTML::Element::Library. Please take a look at
that library module, in particular the content_handler
subroutine and then understand that the Seamstress code can be
quite concise.
In
fact, even without looking at that, did you notice my
second way of rewriting the example? I did not use the id tag
from the HTML more than once in the Seamstree code. I repeat:

This means that each ID tag has to appear twice, once in
the template and once in your Perl, plenty of opportunity for
typos.

I have the same thing in both places: an id tag. Petal has a data
structure in one place and a mini-language to drive access to the
data structure in the other. Typos happen. Test suites catch
them. Both frameworks have things to do in Perl and HTML.

Lets say you decide that your template should display a field that was previously omitted. Now you have to change your template _and_ add 2 more lines of Perl to make sure it gets replaced.

And with Petal, you have to go retrieve the field again and make sure
that the
access of the field syncs up with TAL specifier. We both have to
do work and again you overstate the number of code lines due to
lack of familarity with convenience libraries.

And at some point, you are going to have to go into the HTML and do
your mini-programming. I _never_ have to touch the HTML as long
as the designer puts an id tag wherever dynamic functionality is
needed.

At which point I'd have basically invented the main part
of TAL. Mini-languages are bad but I'll take a small, tight
mini-language any day over lines and lines of cookie cutter
coding.

Perl is a powerful general purpose programming language offering
numerous facilities for re-use: hashes,
subs, modules, objects, normalized database
access, etc. Writing cookie-cutter code in _any_ domain is
un-necessary if you know Perl and have a background in software
engineering. The codebase of Seamstress in the
online website I just
developed does not suffer from your proposed weakness.

Further, when the unrolling tasks becomes more difficult, such
as moving around div elements or adding 2 or 3 attributes to an
element based on complex business logic, I expect the
mini-language to peter out or resort to PERL tags while my
end-to-end Perl approach
will continue to support me even at such higher levels of
dynamic HTML munging.

At any rate, Petal and Seamstress and
XML::LibXML all stress
non-invasive HTML templating. And any of the 3 is hugely
preferred over any other existing approaches for me.

And don't forget: Seamstress is not alone! It has a
counterpart in the Java world
named XMLC. And I must thank Chris Winters, the person who
initially pointed this framework out to me.

In fact, even without looking at that, did you notice my second way of rewriting the example?

My point is that you have to write _something_. It can be reduced to a minimum but you still have to write it and in fact the more steps you take towards minimising the amount of stitching code, the closer you get to having a mini-language. If you insist on avoiding a mini-language then you will always require repeated code. You can avoid massive repetition on each page by using a loop or using content_handler but you still have code repeated across a set of pages.

I have the same thing in both places: an id tag.

But that's a bad thing. Having to repeat the same thing in 2 places is something you should be trying to avoid. The only reason I can see to do it this way is if lots of little pieces of data are generated by lots of functions but most of the time with web programming you're dump out structured data where it makes sense to think of the data as records or objects which may contain further records/objects inside. In which case you have to encode the path into the structure somewhere so it may as well be in the HTML because you have to put something in the HTML anyway and assuming you have a good mini-language the path _is_ the best name for the data.

Typos happen. Test suites catch them.

Typos don't happen when there's no typing. The no-typing you do the more no-typos you get!

And with Petal, you have to go retrieve the field again and make sure that the access of the field syncs up with TAL specifier.

This is not correct. The field is specified once in the template and populated once in the Perl. That's the fundamental difference I'm getting at. With seamstress I have to populate my data, name it with ids and map from ids to the data in extra Perl code. In Petal the mapping stage does not exist (I should say it's handled automatically).

One other thing is that Petal templates can be compiled down to a very fast form. Last year I had them running as fast as Text::Template (and with some syntax tweaks, considerably faster) but the changes were never integrated into Jean Michel's releases. Something which manipulates HTML trees at run time can't do this.

We both have to do work and again you overstate the number of code lines due to lack of familarity with convenience libraries.

Any number of lines is too much, I don't see any great benefit to being able to employ the full power of Perl for manipulating the HTML (or I can see how it would be good in very special cases but not for a general purpose templating system).

And at some point, you are going to have to go into the HTML and do your mini-programming.

Why? The interface between programmer and deigner is the spec for the data available at template time. You can tell the designer that there'll be these 10 strings with these names or if your designer is at all smart you can give him a hierarchical schema and he can dig through it in whatever way he fancies at run time. It's still not programming, any more than saying click File->New->Word Document and c:\files\photos\family\xmas.jpg. It's just flat naming or hierarchical naming.

The codebase of Seamstress in the online website I just developed does not suffer from your proposed weakness.

I'm sure you have factored them out so that they are at their minimum but I also know that every single seamstress id tag in your system is repeated twice and that every single page in your system involves a call to content_handler and every single array that is dump as html requires a Perl for loop (or a wrapper around a Perl for loop).

Further, when the unrolling tasks becomes more difficult, such as moving around div elements or adding 2 or 3 attributes to an element based on complex business logic, I expect the mini-language to peter out or resort to PERL tags while my end-to-end Perl approach will continue to support me even at such higher levels of dynamic HTML munging.

No business logic is encoded in Petal templates complex or otherwise. Assuming the business logic is captured by objects in the system then having 0, 1, 2, 3 etc attributes appear or not is quite straight forward. Moving stuff around is where includes and METAL come in. Although manipulation of the HTML tree would allow you to pick up any part and move it to any part, that's a very unusual requirement. The number of destinations would normall be quite limited or be uniformly distributed over a list of places, in either case conditional includes work nicely.

There are things you can't easily do in Petal, for example rearranging the page in arbitrary ways at a fine level of granularity but (for this application anyway) you're probably better off with style sheets.

One other thing is that Petal templates can be compiled down to a very fast form. Last year I had them running as fast as Text::Template (and with some syntax tweaks, considerably faster) but the changes were never integrated into Jean Michel's releases. Something which manipulates HTML trees at run time can't do this.

Here, you have hit the nail dead on the head. You have found the Achilles' Heel of HTML::Seamstress. I had parried and dodged and ducked, but here is where you achieve touche'. Seamstress does runtime tree manipulations with the number of tree traversals per page linear to the number of templating actions. Put in plain talk: each time you need to do some sort of templating action you need to search through the tree to do it.

I recently began work on a compiler to optimize this but quit doing it after realizing that under mod_perl, the HTML tree needs to be created afresh for each new templating operation: I found this out in my test suite. When the first test case was fine but all the rest kept failing. Then I printed out the tree and OMG! The tree is mangled! Must start afresh!

Thanks for the reference to METAL, I had not heard of that. I learned some things about Petal from this. I have noticed a number of repetitive idioms in my HTML manipulation and may one day create shortcuts and a compiler for them. It's just right now I don't want to be telepathic about what I might need.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other