Re: Application Design
On Saturday 11 August 2001 17:58, Mike.Champion@S... wrote: > > If only the world were so simple! > > So, let's make it that simple :~) Maybe XSLT isn't what we really need, > but maybe there's a subset of XSLT that hits the 80/20 point, or maybe > there's a more elegant alternative that does what we hoped XSLT would do. There is definitely (imho) a subset of XSLT that meets the 80/20 point. What I like about XSLT is that it is strict. While strictness is definitely a bad thing in _general_ purpose solutions because you loose the security of being able to find your own solution to the problems that the inventors of the solution hadn't thought about (eg the bondage & discipline programming languages), it is a great thing to have in special purpose solutions, the ones you want to do one job and do it well. XSLT for me falls into that latter category. It transforms trees and does it reasonably well (albeit, of course, with a few limitations, but that's what 80/20 is all about). Anyone trying to do anything else with XSLT is bound to run into the same kind of problem as someone trying to light a cigarette with a coffee mug (don't ask): it may work but you don't want to know how. > For what it's worth, I'm predisposed to consider XSLT (along with "common" > XML 1.0, DOM, and XPath) as part of the solid core of XML technologies that > really more or less do what they are advertised to do and have a real track > record of success. I'd agree with that. > I'd be very interested in hearing from people who have tried to implement > more complex XSLT applications. When does XSLT generally hit the wall? Is > there an alternative (given than you have XML data as the input) other than > just writing code? (For example, does anyone other than Al Snell find PHP > templates to be a more powerful, easier to use alternative?) How do people > feel about XQuery's output reformatting capabilities as an 80/20 point for > real-world web applications? I've been using XSLT intensively for a number of months, and have clearly hit some walls. I still consider it to be too young a technology (for me at least) to be able to produce guidelines, but some elements are starting to emerge. For instance, using XSLT to produce similarly or less complex documents than the original is easy, trying to produce a document that's richer than the original will likely lead to problems. That's to be expected, after all the T does stand for transformation, and not for destruction or for production. Whatever information you want in the output should be present more or less as-is in the input. This is obvious but a lot of people tend to forget it. Problems relating to producing some types of tabular documents are well known (and addressed in the XSLT 2.0 requirements) so I won't go into them here (though I've been badly bitten by them, and resorting to xsl:text + disable-output-escaping + CDATA is something I'd rather not think of during dinner). One major problem I'm seeing presently with XSLT is that of the compared document orders of the source and the output. If they differ too greatly, or in some specific ways (of which the tabular example is just a specific case) then you'll end up using far too many value-ofs and copy-ofs, and worse, far too many call-templates. I'm actually on the verge of saying that an XSLT document is as good as its density in apply-templates. Of course, that would be an exageration as the other ways to jump accross templates are useful there, and in fact XSLT would be pretty much useless without them. However, too few apply-templates in an XSLT document probably means that you should be using another language optimized for another processing model. At least it should raise a warning of whether you're doing it right. As for PHP templates (I haven't used PHP, but I'm talking from experience with the 200 or probably more templating modules -- some of which are truly excellent -- that can be found in the Perl community, and more precisely on CPAN) I think that they serve a different role from XSLT (and unfortunately the word templates or even templating system is used in both, causing confusion). The template modules such as those made for Perl are very good at dealing with *text*. In fact, they are far better than XSLT is at a number of tasks. They are general purpose solutions, and they can do just about everything, but they're favoured output format is text, not XML. And because of that, there is no serializer that takes care for you of issues such as encoding, tag pairing, escaping, etc. XML is much more than just text, and that's where XSLT fits in. If I had to query a remote SOAP server, grab something from a database, update an object repository, and feed the results to a webpage I'd definitely use XSLT only as the very last step. The first ones would be carried out in Perl (replace with your favourite general purpose programming solution), probably used through XSP (in order to garantee valid XML output). XSLT would simply transform the programmatic structure produced by my application into another structure, fit for consumption by browsers/users. Any alteration of the said structure would probably have to happen within a space within which I have more control. So I guess the best practice here is (surprise !) "apply where appropriate". -- _______________________________________________________________________ Robin Berjon <robin@k...> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com ----------------------------------------------------------------------- The first myth of management is that it exists.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format