(jeffa) Re: XSL/XML/Perl as a development process

[jeffa]

Nice post (but do we really need the CSS?). Question: why is the XML file static? I myself have used static XML files before (if i need a new record, i add one by hand via vim), but in 'real world', that data is stored in a relation database. If you had used XML::Generator::DBI, then i could see the point better, but having the "boss" handle the XML file seems, wrong.

Also, i feel compelled to mention that unless you are looking for platform independence, XML/XSLT just isn't as fun as a pure Perl templating solution, such as HTML::Template or Template, IMHO. I really think this would have been a better article if you had included them as well. But effort++. :)

Addendum: indeed, i really wish you had made this article more general, as what you are describing is the model view control "pattern".

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

[chunlou]

CSS       Right, it wouldn't lose much for the discussion even should the CSS not included. It's just more complete as an example with one.

STATIC XML       The static XML file is for the Artist (or Web/Frontend Designer) to be able to do the HTML markup with XSL without the Perl script even ready.

The static XML also serves as a req spec doc. In a working app, you probably won't have or need a static XML file sitting around. The XML will be generated dynamically from within a Perl script by then. But during the devel proc, it's good to have a static XML file against which to check your Perl's generated XML.

BOSS       Sorry for not explaining the BOSS-XML part. A BOSS could be your Project Manager or System Analyst or Team Leader. Or, to read that relation another way, a BOSS-Client conveyed a req to your Project Manager to your Lead Programmer who came up with the XML.

No, a non-techie BOSS handling XML won't be a good idea.

HTML::Template       Template is really a clean solution. Easy to use. It does the job of separating Perl and HTML. Especially nice when the same person who does both the HTML and the Perl. Not to hard for less technical Web designer to handle a Template either.

However, sometimes (or most of the times) a Template need to wait for a Perl script in order to see the complete HTML result. Hence, lacks the independency. XSL can check it against a static XML, not Perl script.

Also, when changes were made to both Template and Perl script simultaneously and something went wrong, you might need to check a Template and a Perl script against each other--an a bit more troublesome debugging process--whereas (in theory) XSL and Perl script check against XML (which is supposed to be locked/frozen).

Yet another situation, you need output to multiple media. A common req is that a client wants a report to be on the Web, as well as on PDF. (Well, refer to your phone bill, for example.) XSL makes a sensible solution, though I won't claim it's the best.

One more thing, you can't swap your "backend" (the Perl script) with Template. XSL doesn't care what backend you use.

Of course, if those are not your concerns, HTML::Template makes a good choice.

XML/XSLT NOT FUN       I must say, XML does require more discipline than many Web development companies are willing to commit to. (Many organizations tried to come up with some XML templates and ended up nowhere.) No, XML/XSLT isn't fun. Neither is trying to make a "quick fix" to a live system, just because some client/account manager forgot some "minor" req.

The point is not so much about using XML as it's about thinking things through. It's a mixed blessing that you don't need much planning to code a PHP page, for instance. XML forces you to do a bit more thinking.

A FOOTNOTE       Actually, to be more correct or "orthodox," when I said checking a Perl script's XML result against XML, I probably should or could have said DTD or Schema, in lieu of XML. But not everyone bothers with DTD or Schema. XML alone is an enough start.

[zby]

You can use templating with XPath expressions (this is possible with Template::Toolkit - don't know how about other templating libraries). This way the templates could be used with static XML. So at least the XSLT part can be replaced.

[chunlou]

I didn't usually find "general" theory as a first lecture worked pedagogically. I found people learnt better with concrete examples.

Most people (if not all) learnt arithematic before learning set theory (if they ever did). And most CS students (if not all) learnt Pascal or Java or BASIC first, not lambda-calculus.

But then, I also always adjust my presentation to suit the audience.