Jean-Michel Hiver wrote: > Because Petal templates have to be well-formed XML,
This is the sticking point for me, I'm afraid. I can see some of the benefits of having templates written in well-formed XML markup, but I can't see past the drawbacks. XML syntax is crufty at best. It requires you to be strict and tediously correct with every character. 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 and you find yourself tied down to only generating valid XML (which few real world web pages are, even if they should be). 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. This is all personal opinion, of course. 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. 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. But that's what makes the world such a fun place - we all have different ideas about the Right Way to Do It. And that's why there will never be one template module, toolkit, strategy, solution or design pattern that will keep all the people happy all the time. That's not to say that we need 37 different template modules, but we definately need more than one. Vive la difference! A
