Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re^7: Survey of Surveys on HTML Templating systems

by fergal (Chaplain)
on Feb 26, 2005 at 03:10 UTC ( #434717=note: print w/replies, xml ) Need Help??

in reply to Re^6: Survey of Surveys on HTML Templating systems
in thread Survey of Surveys on HTML Templating systems

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.

Replies are listed 'Best First'.
HTML::Seamstress' Achilles Heel
by metaperl (Curate) on Feb 26, 2005 at 16:22 UTC
    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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://434717]
[atcroft]: james28909: Make both hands into fists, place them together (with thumbs concealed), and every knuckle is a month (starting with Jan.) has 31 days, every dip (between knuckles) does not....
[atcroft]: (And Feb. is the odd case, because it is 28, unless it is a year divisible by 4, or if it is divisible by both 100 and 400 (at which point it is 29).)
[james28909]: i know but scroll through your calendar on your computer.
[james28909]: i thiught you were going to say make both hands into a fist and puch yourself in the face
[atcroft]: .oO(Sorry, I probably should have said take two normal hands....)
[atcroft]: james28909: No, unless you are a politician, I wouldn't say that (and even if you are, I still probably wouldn't say that).
[james28909]: i mean how hard can it be? its just subtracting days lol
[atcroft]: james28909: What about October 5, 1582?
[stevieb]: atcroft: "Make both hands into fists..."... is something my Ma taught me in our native lang, but I was to ignorant and young to pay attention. Thanks for that :)
[atcroft]: stevieb: Sad to say that I only recently learned that particular trick, but I have since found it very useful.... :)

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2017-04-29 04:27 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (531 votes). Check out past polls.