Hi,
It's been quite a long way before I finally arrived at the same conclusion you
guys have reached.
That is use XSLT only for what it is designed for and what it is best at. According to
my experience,
XSLT is great for doing XML to XML transformation. But for complex XML to HTML
transformation,
or whenever you want to do complex logic in the stylesheet, you will find that the
complexity of stylesheet
really offsets the benefit of separation of content from presentation. My
understanding is that using
stylesheet is only hyperthetically ease the job of page designer. In fact it's hard to
learn and use for
page designers. Besides that, there's a performance penalty that can't be easily
conciliated by using cache.
Personally, I would like to use Struts for most of the web applications. As a
true MVC framework,
Struts inherently separates the view from control and model. Armed with a rich set of
Taglibs, you can
actually achieve most of the benefit of xsl and still get the power and ease of use of
JSP. So if you've got
Struts, who needs XSLT for view again? Well, On the other hand, XSLT may be useful in
the future
web services applications, where XML is used as an universal and platform-independent
format for
communication and then xslt can be used to process it. That's my forecast.
For those sites that really need to support multiple languages or skins or
platforms, and if they really
want to use xslt and are ready to accept the complexity and overhead of stylesheet, I
would suggest that
they still use Struts as framework, but in the view part, the jsp pages will use XML
instead of HTML as the
native language and use Taglibs to do the transformation on the fly (or use XSLT
Sevlet filter to do the
transformation, for it readly supports caching & locale).
For those who are really worry about performance, I suggest that they use
Servlet+XSLT, that is to do
the xslt transformation in the ActionServlet, bypassing the JSP implemented views.
Reference: http://www.onjava.com/pub/a/onjava/2000/12/15/xslt_servlets.html?page=2
Hope this helps,
Shengmeng Liu
*****************************************************************
----- Original Message -----
From: "Lewis Lin" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, January 04, 2002 5:26 AM
Subject: RE: Using Struts with XSLT
Hi, Todd,
I 100% agree with you. We did a small project using pure XSL transformation with
Struts. We had to overcome the combo box selection, form validation, and error
handling issues that could be handled much easier with Struts directly. I am really
debating with myself at this point. On one hand, it seems like the whole world is
going with JSP/Struts, on the other hand, I really don't want to give up the beauty of
the truely seperation of the data from the view.
Are you still working on this topic? What area do you mean when you said to limit
the usage of XSL only when it's neccessary?
Regards,
Lewis
-----Original Message-----
From: Todd Fulton [mailto:[EMAIL PROTECTED]]
Sent: Saturday, November 03, 2001 10:42 AM
To: 'Struts Users Mailing List'; [EMAIL PROTECTED]
Subject: RE: Using Struts with XSLT
Yeah, I did the rendering/presentation end for an entire application using
XSLT. The application was a time tracking invoicing type app that we
delivered as an ASP (i.e. failed .com). Spent 18 months with that stuff.
We were using the Sun xml processor and the Saxon xslt compiler.
It wasn't struts, but that shouldn't matter too much. I can imagine
numerous ways one would eventually route the output through a XSL processor
using struts -- including the method you mentioned.
Some things I discovered. #1, the performance definitely was not what I
could have wanted for the application. All that xml/xsl handling added a
certain performance floor that simply could not be overcome. We calculated
that the XSL rendering part of the application added somewhere between .5
and .75 seconds to all requests. Granted, we were doing pretty heavy
rendering -- the xml objects were upwards of 30k or so. And we were getting
somewhere around ~8000 page requests/hour. #2, we had to staff and train a
cadre of XSL stylsheet designers. This was tough, because there were not
(this was 1999/2000) alot of people with this kind of knowledge back then.
The stuff is not rocket science, but still not the easiest thing in the
world -- especially for interface designers. #3, the XSL syntax at the time
was not standardized. We moved between the Lotus XSL processor and Saxon
and had to do a complete rework of the interface layer.
This may sound like a bashing, but it's not. The concept of XSL rendering
is absolutely amazing. It gets one much close to that perfect separation of
data and presentation. And things have progressed substantially since that
time. HOWEVER, if I were to do it again, I would definitely limit the use
of the XSL to areas where it was necessary. In the end, JSP is just easier.
Todd
-----Original Message-----
From: Jan Arendtsz [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 02, 2001 9:10 PM
To: [EMAIL PROTECTED]
Subject: Using Struts with XSLT
I would like to use Struts as my MVC framework but use XSLT for
rendering the final HTML/WML pages. I thought that this would be
somewhat of a common approach but was surprised to find very little
information when searching through these archives. Is this something
that Struts 1.1 will support?
The application that I'm hoping to building should eventually support
several UI devices as well as multiple languages and that's the reason
we would like to use XSLT. However, we are also somewhat concerned
about some of the performance ramifications when using XSLT.
It seems that using Struts 1.0, I would have to do the following:
- Use the action object to call JavaBeans or EJBs to retrieve data from
the database either as XML text, Row sets (JDBC 2.0 extension), or
custom data objects (the optimal way would be not to use XML since it's
not as efficient), and store this data as a request attribute. Once the
action object has forwarded to the corresponding view JSP or Servlet,
this data can be retrieved (since it has a request scope), converted to
a DOM object and transformed using a XSL stylesheet. I was also hoping
to use the stylesheet template caching described in the book "Java and
XSLT" by Eric Burke
(http://oreilly.com/catalog/javaxslt/chapter/ch05.html) to improve
performance. The JSP page used for the view will not contain any Struts
tags and therefore can be a servlet.
Variations to this could include the following:
- Using the Jakarta XSL tag lib within the JSP page to do the
transformation. This could mean that I won't get some of the
performance benefits using stylesheet caching.
- Use filters (new to servlet 2.3 spec). Don't know much about this,
especially on the performance side.
For those of you have worked on a similar application, do you have any
suggestions or best practices? I'm trying to use both Struts (purely as
the Model 2) and XSLT together and this does not seem to be a common
practice. I could drop one or the other if the solution is a good one.
Does anyone have thoughts or experience with other frameworks such as
Coccon, Turbine, and Barracuda?
Thanks
Jan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
