On Mon, 4 Sep 2000, brian moseley wrote:
> On Mon, 4 Sep 2000, Matt Sergeant wrote:
>
> > Unusual bunch :-)
>
> don't think so. xslt is overly verbose and complicated, and
> its model is the inverse of the standard html page. whereas
> a nice little mason page with some simple embedded perl
> looks enough like what everybody's used to, to not be big,
> scary and new.
>
> > Or are you talking about XSLT vs Perl? If so then I'd
> > agree - XSLT is mightily scary compared to a simple HTML
> > template scheme. But infinitely more powerful.
>
> *raises eyebrow*
>
> please expand on that last comment.
I was questioning whether or not your HTML people found Perl easier than
some taglib scheme like HTML::Template, or whether you meant they found it
easier than XSLT.
Now as to why XSLT is infinitely more powerful...
Most HTML template schemes are great where the template wraps the
content. So you've got basically a HTML page with some places to insert
content. This is basically an extension of the SSI concept, and while
these schemes have become more powerful, they lack the ability to do
really powerful transformations.
For example, take a large article. Now with an ordinary "wrapper" template
scheme, the article *HAS* to be encoded as HTML, otherwise it just can't
be inserted into the template. You can do some fancy things with
pre-processing, but then that ends up being in the realm of code
again. With XSLT you can markup your article in some XML format, and have
explicit programmatic control over how that entire article gets presented,
right down to the links and possibly putting in some breakouts, and other
stuff. You can do this down to individual attributes. This is called
declarative processing, and its the key to XSLT's power, and also provided
in a Perl version with AxKit, called XPathScript.
And of course just to add to that, declarative processing is not the only
way you can do XSLT. You're quite welcome to use the style you are used
to, using a single main template with insertion points, but as your source
gets more complex you tend to need the declarative processing more.
And you can do this in ways far more powerful than CSS can cope with, and
not only that, you can do this on the server to generate stuff other than
HTML (which is the only thing your CSS is going to work with), such as
content for WebTV, or WAP, or PDF.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
