On Mon, 4 Sep 2000, Matt Sergeant wrote:
> 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.
ah yes. xslt vs mason, specifically.
> 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.
ok, sure. i'm coming from a different place than you are, so
i think about the question differently. my application isnt
editorial/content driven. the html people are concerned with
making the header and footer of the page have our customers'
navigation elements; in specifying colors and such. the data
that is presented in the content area of our page is
fragmented and comes from many disparate data sources. its
quite easy to assemble with embedded code, and would be
quite unweildy with xslt (i know, i've tried the approach).
in general, your point is well taken, and you've even helped
me see a use for it inside my system that i hadn't
previously seen. but that's still not as an aid to my html
people - it's so that i don't have to embed html markup into
my message catalogs (where my localized strings come from).
perhaps i can use xslt to transform catalog source in xml
format to several sets of catalogs, one for html, one for
wml. maybe. see below comments. but i still am much more
inclined to go with the html template approach for the
page's framing elements - which means the artifact that my
html people manipulate is still an html page. not an xsl
stylesheet.
> 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.
mm, we've found in the real world that a 'one source fits
all' transformation simply can't cope with the vast
differences between devices. perhaps for simple content
presentation its ok, but for a sophisticated application,
the flow has to change quite dramatically across devices.
it's been more practical for us to use separate sets of jsp
templates for each device, with a custom template
inheritance mechanism to provide the benefits of sharing.
