RE: [xsl] Need 3 good reasons why XSLT is better than JSP+Velocit y

["Hunsberger, Peter" <Peter.Hunsberger@xxxxxxxxxx>]

> Yeah, this is the point, though -- XSLT is good when you are going from
> the data layer pretty directly to the presentation layer.  If you need
> to do a bunch of "procedural code" things between the data and
> presentation layer, you probably want to use a procedural language. 

That is of course a reason business logic should be coded in it's own layer
using Java (not XML). Having said that I will note that XML hierarchy in
itself can represent business rules.  You don't have to use XML as a
procedural language to get the same (or better) power of expression. If you
stop looking at the problem procedurally and start looking at as object
representation and linkage you'll find that XML can simplify your life
considerably.  

> Of course, it is possible to have the business-logic tier produce XML 
> that then gets transformed with XSLT to become the presentation, but 
> once you are already using a procedural template like ASP or JSP, it is 
> much less attractive to be adding an extra step of complexity when you 
> could just as easily produce the XHTML directly from the JSP.  

Fixing a broken architecture always has a cost.  It's often hard to justify
the benefit.  I do hope we can provide some justification...

> And if the business
> and presentation are on different physical tiers, you would be taking a
> serious scalability hit for dubious added value. 

I don't buy that.  Although there's not a lot of ways to cache XML/XSLt
there are effective architectures for managing them.  Things like Translets
make it a lot easier.  You may need some extra horsepower, but overall I
think for most (not all) applications XML/XSLt will scale ok.

> It is also *possible*
> to call the business logic from within XSLT extensions or script blocks,
> but in my opinion this violates the spirit of XSLT and is in any case
> much less productive way to do business logic -- we have modern object
> oriented languages and lots of experience doing it other ways, and using
> those tools will result in faster, more stable code.

Here I disagree completely.  XML is a very good and flexible way of
representing object hierarchy and relationship (one could argue equivalent
to Java since neither truly allow multiple inheritance).  As such, XML makes
a really good way to dynamically glue together Java objects: having an XSLt
template determine what order what objects need to be invoked to build
presentation is much simpler than trying to code the same business rules as
Java objects and relationships.

Many people seem to have an aversion to XSLt extensions that in my book is
not justified.  Extensions do need to be more formally embraced and
architected, but when used properly they are a natural way to exploit the
power of XML for representing meta data and therefore object relationships.




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list