I don't get it, from the example you gave, seamstress requires a whole load of extra Perl code as well as a HTML template.
I would say that Seamstress requires a lot of Perl and nothing but id tags in the HTML (a standard thing) while in contrast Petal requires very little Perl but more programming in the XML/HTML. Looking at this another way, the learning curve for Seamstress is nothing but object-oriented Perl an object-oriented API for tree manipulation. The learning curve for Petal is Perl to the level of references and a mini-language for manipulating those references.
Seamstress can unroll tables in two ways:
using a row-oriented iterator method and it can also create tables using grid coordinates.
here is a reference to my query about alternating table rows in Petal... it is different from how Seamstress does it.
I have said time and again here that I do not like mini-languages. I spent enough time learning Perl and HTML so that I dont want to be concerned with hybrid technologies which are no more powerful but do require me to remember yet another set of rules and exceptions and limitations. To each his own, but keep me away from mini-languages personally.
| [reply] |
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.
| [reply] |
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:
# look ma, concise code!
for my $content (qw(name last_login)) {
$tree->look_down('tal:content' => $content)
->replace_content($hash->{user}{$content});
}
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.
Nice discussion. Thanks for your input!
| [reply]
[d/l]
[select] |
