Yes,
We are using XSL as our output format instead of JSP. Here's what we've done:
1) We created a "Message" object that is an ActionForm. All of our ActionForms
inherit from this object. This way we enforce that the "Message" object is
present for each action and is either in session or request scope and we get all
the functionality of Struts' ActionForms. The message object encapsulates and
enforces our XML Source Document format. The source document is rendered as a
DOM within this object and is used as the source for the XSLT transform. An
action's data is copied into this DOM as it is created.
2) We have one JSP that all actions forward to. This JSP contains the XSLT
Processor. The JSP pulls the source doc out of the Message object, sucks in the
XSL file off the disk, performs the transform and spits out HTML.
Advantages
---------------------
1) Flexibility. Our clients (or page designers) could write their own pages if
they know XSL. They don't have to know Java or JSP or understand our beans or
anything like that. We tell them our source doc format and they go off and
write pages. We could also support JSP in a combined environment if need be.
2) Productivity. Not having written any JSP tags, I'm not really in a position
to say this, but it seems that XSL templates are a lot easier to write than
custom tags. And they accomplish most of the same purposes, at least within
what we do. Before XSL, we used to write a load of Java scriptlets in our JSP,
and XSL works a lot better for us. Plus you can test it in a static environment
without the web server running. That's harder to do in JSP.
Issues
-----------------------
1) Performance. It seems to take longer for the XSLT processor to run than the
JSP "processor". We cache our pages so that it works similarly to the JSP
compiler. If all of your page data is not in XML you have to DOMify it or
otherwise get it into XML before running your page. This can cause performance
hits as well.
2) Design. Perhaps the "Message" object could be better designed. It is
really only needed at request scope, but since it is an ActionForm, it is
usually held at session scope. So it has to be reinitialized on every request
to keep stale data out. Maybe it would work better if it was some sort of
static thing, or something that was stored in the request to be made available
to the JSP.
3) Perhaps the biggest disadvantage in the way we've implemented it is
deviation from the Struts architecture. When using Struts the way it was
designed you have access to all the custom tags, automatic form population, and
other things that we had to try to create on our own.
Conclusion
-------------------
For us it's worked out well. Our data comes from the backend in XML so it makes
sense to leave it there and use XSL to transform it. It also allows us to be
very flexible in how we develop our pages and interact with other apps.
Performance could be better, but we have yet to test it in a real environment.
That will come soon. If we could do it all again (and I'm sure we will
eventually) we'd probably make some tweaks in the design, but my opinion is that
you can make Struts work very well with XSLT, even if you have to make some
extensions to the system to do it right.
Hope that helps.
Greg
-----Original Message-----
From: [EMAIL PROTECTED]
Sent: Tuesday, April 03, 2001 12:22 PM
To: [EMAIL PROTECTED]
Subject: Struts & XML/XSL
Has any one integrated struts with XML/Xsl?
I'd like to know a few thoughts/issues/ideas/patterns
on that.
Thanks,
Ven
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
