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: <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]>
