RE: Using Struts with XSLT

[Taylor Cowan]

Yes, you are correct about comlexity.  However, when you define the XML
format, you only need 1 style sheet.  Then you are modifying the XML.  As
for things XSLT cannot do see
http://www.javaworld.com/javaworld/jw-12-2001/jw-1221-xslt.html?

Taylor

-Original Message-
From: Shengmeng Liu [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 03, 2002 10:40 PM
To: Struts Users Mailing List
Subject: Re: Using Struts with XSLT


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 

Re: Using Struts with XSLT

[Sushant Patney]

Hi,
I can tell u the problems i faced using Xalan XSLT.  It forcefully puts all
attributes defined in XSL as
 even if they dont have a entry in the XML file. This
feature created problem as HTML is not well formed and also in WML which
wants perfect structured'ness.
Thanks

- Original Message -
From: "Shengmeng Liu" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Friday, January 04, 2002 9:09 AM
Subject: Re: Using Struts with XSLT


> 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 

Re: Using Struts with XSLT

[Shengmeng Liu]

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 separ

RE: Using Struts with XSLT

[Luke Studley]

Hi Jan

I'm relatively new to struts - but have come from a background of using XSLT
with Servlet2.3 filters.

Have to say this worked great, although as people have pointed out there is
a performance hit. But I found with optimization I could reduce this to a
nearly negligible amount (I also used SAXON - which is great and has
improved quite a bit in recent releases performance wise.)

I have a working site using XSLT, but it was written and maintained purely
by me - so it was a nightmare for other people to support - as all the
presentation stuff was in the XSL, i.e. raw XML data (from app server)
driving XSLT sheets with embedded HTML/WML etc.

This lead me to want to split out the data some more and have 2 XML streams
- one describing the data and one describing the presentation (sounding
familiar yet?) which I implemented myself using XSLT URIResolvers.

Around this time I also discovered Cocoon and spent an interesting, but
ultimately unfruitful, time evaluating and porting to it. It has a lot of
nice features (many of which I'd already implemented for myself previously -
annoyingly :), but I realized that what I was ultimately doing with my dual
XML data flows was effectively implementing custom tags using XSLT. (Also
see Cocoons XSP templating language)

E.g. In your presentation XML you write something like 




And in your XSLT you have something like:






You also find your self wanting to substitute data values for elements which
may come from secondary XML streams or you may want to read values directly
from Java classes. This becomes a lot more cumbersome. XSLT - Java bindings
are non standard and mostly awkward to use.

Then I (re-)found JSP and Struts. Taglibs have come a long way since I last
looked at JSPs about 2 years ago and I realized I had the solution to my
problem. Use JSP to generate the presentation layer (as it was meant to do)
and use the taglibs provided by struts and Jakarta. The presentation is
still separated out, using Java to access data is much simplified, and I can
still bring in my XML data using the xtags library.

Currently I am not planning on using XSLT at all for the moment (which makes
me sad as I love it). Although I am considering that it may be useful in
i18n, as I don't like all the properties files you get from the taglib. And
it may be useful in defining on the fly look and feels by restructuring your
XHTML etc.

I'm still not ultimately convinced JSP/Struts is the 'best' way - and in
general I liked cocoon. But now there are so many useful tag libraries
(including support for XSLT) why go re-invent them yourself in XSLT? Plus
ultimately when it comes to getting someone to support my pages when I want
to move on to the next new thing ;-) I know I'm going to find it easier to
find someone to support a JSP/Struts solution than my own bespoke XSLT one!

Hope some of those ramblings were useful.

Luke




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Using Struts with XSLT

[Lewis Lin]

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

Re: Using Struts with XSLT

[Vic Cekvenich]

Yet another way to use XSL:
This way is very fast and offloads processing of the app. server for 
greater performance under load (and it has less net traffic).

Consider... how we used CSS and that most browsers for the past year 
support XML. Those that do not support XML/XSL can  javasript to do this.

And the way is:
Emitting XML from JSP!  If you do this, you can have skin-able interface 
and be able use FOP, and other advanced designs.
When you emit XML from JSP, one of the things you send to a browser in 
addition to XML, is which XSL to use (similar to if you sent HTML, you 
would say what CSS to use).
Then The browser does the XSLT, on the client side, thus offloading 
work of the server.
I tested this and it works nice. IE 6 is easiest and other browser work 
as well, but you have to learn more.
To test this, just write a send out a simple XML from JSP to your 
browser, and tell the browser what XSL to use. Then change the XSL to 
use, but keep the XML.
Neat! Elegant! Fast!
Vic


Ted Husted wrote:

> The wall most people run into is that, AFAIK, you have to give up the
> tag extensions to use XSL at runtime, which is an issue for many Struts
> developers. 
> 
> Another way to use XML in a Struts application is to use the Digester to
> convert the XML into a JavaBean, and then pass that along in the
> request. However, that would not help with your requirement to render
> different markup for different devices. 
> 
> It may be possible to use the Tiles to create different styles of pages
> for the different devices, but I really haven't looked at that myself. 
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
> 
> 
> Jan Arendtsz wrote:
> 
>>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:   
> For additional commands, e-mail: 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Using Struts with XSLT

[Ted Husted]

The wall most people run into is that, AFAIK, you have to give up the
tag extensions to use XSL at runtime, which is an issue for many Struts
developers. 

Another way to use XML in a Struts application is to use the Digester to
convert the XML into a JavaBean, and then pass that along in the
request. However, that would not help with your requirement to render
different markup for different devices. 

It may be possible to use the Tiles to create different styles of pages
for the different devices, but I really haven't looked at that myself. 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/


Jan Arendtsz wrote:
> 
> 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:   
For additional commands, e-mail: 

RE: Using Struts with XSLT

[Todd Fulton]

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:   
For additional commands, e-mail: