I thought this article was very good, and probably one of the best
approaches I've seen to using XSLT with Struts. If I was in a situation
where I had to use XSLT, I'd probably take an approach similar to this
one.
However, I found the authors' contention that this solution offers a
significant advantage over the standard Struts architecture to be
unconvincing. They cited several disadvantages to using Struts "as-is"
that I thought were not valid and little evidence was given to support
them. They were particularly critical of JSP and the Struts tags, and I
thought this was their weakest argument. They implied that XSLT is an
easier "API" to learn than Struts tags, a notiion which I believe is
entirely false. Most developers I know were able to pick up the Struts
tags by looking at documentation and examples. The same developers had
to buy a book to learn XSLT. One might find a different learning curve
among page designers, but I seriously doubt they have a better grasp of
XSLT than JSP.
The authors also failed to mention the fact that the transformation of
the JavaBeans to XML adds a whole new layer of processing to be done.
JSP doesn't have to "serialize" the beans before it can use them.
Again, I thought the authors did an excellent job at presenting a
framework for using XSLT with Struts. But the article should not have
presented this solution as being in competition with Struts/JSP, in my
opinion.
Greg
winmail.dat
Description: application/ms-tnef
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
