|Problems? Is your data what you think it is?|
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.
In reply to Re^7: Survey of Surveys on HTML Templating systems