Even without some of the additional test cases that I think I'll add tonight as suggested by Matts and gellyfish, I think my example demonstrates the apprear of code that tries to separate presentation and content. The DBI/print and DBI/CGI solutions are fast, but ugly, IMO (even slicking up the CGI with a map, it's still ugly). All the template and XSLT solutions, on the other hand, have no hint of presentation in the code, and that is all delegated to separate files. Mind you, since TT2 appears to be limited in handling of pure XML data (given the poor speed), you may have to do some massaging of data to get it ready for passing to TT2 as I had to do (the join oneliner).
in reply to Re: Re: Re: XSLT vs Templating, Part 2
in thread XSLT vs Templating, Part 2
Of course, when you then turn to the template files or stylesheets, you may be scared by either one. One thing, though I want to use XSTL, is that unless you are using a editor that can make it easy to distinquish between the XSL directives and the XHTML markup, it might be hard to determine the difference between what's what in the stylesheet; on the other hand, the template specific code is easy to pick out from the [% %] blocks.
But these differences may be simply personal opinion; some might find anything XML-based easy to read, and find the template solution to be tag-soup ( As an aside, I see that in TT2 2.06, if not earlier, you can specify which tags TT2 will look for, including using SGML comments <!-- --> as delimiters.)
However, I suspect the real test will come when I start putting together other parts of a CGI system I'm working on, such that I run through multiple XSLT transformations. This *should* be as easy as chaining the results one after another, but....
Dr. Michael K. Neylon - firstname.lastname@example.org
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important