Hi Denis, I'm pretty new to struts myself, but it sounds like you could use action form as a container for your value objects and route to JSPs that understand which bits of XML are needed to assemble the final output and to do the compilation (maybe using a tag library to access your XSLT Stylesheet Factory/Cache)
Another way would be to include enough information about what stylesheet to use in your value objects such that you could use a global forward to single servlet that simply reads the value objects to produce XML and does the XSL transformation. Servlet filters would also work...I've been looking at servlet filters myself... If I return an String representation of an XML document, I have to pay the cost of converting it to a DOM tree. If I build a DOM tree to begin with then I don't have to pay that cost. If I use a servlet filter, I think we'd have to pay that cost because (if I'm not incorrect, the servlet filter would expect to work off the response, i.e., the output stream) One way to cut down on processor cycles that works (in theory) is to do browser id to determine if the client is XSLT-aware. IE 4&5 and to a lesser degree, NS 6.1 all support XSLT processing on the client side. It might be interesting to look at pushing off the work of XSL transformation to the client in cases where the client is XSLT-aware. The ultimate problem is that when we use XSLT, some of the benefit of using struts vaporizes in that it is a much tricker to make good use of the tag libraries. I'm not sure where we are going to come down on this issue, but it may be that it is simply a better fit time-wise for us to use struts-enhanced JSPs for now. I dunno yet. --Michael Denis Goeury wrote: > Hi Michael, > > Our application is also based on EJBs. In our case, the business layer can > provide standard Value Objects (through a Session Facade) or their XML > representation. All those XML parts are put together in View objects to > construct our proprietary DOM tree. After that the XSL transformation is > applied and returns the HTML content in a ServletResponse. > > The problem with our current presentation layer is that the control logic is > managed by many different servlets and is therefore very difficult to > maintain. There is also a lot of 'cut & paste' code in those servlets > because there was no concept of ActionForms and Action objects. We would > also like to define the navigation in an XML descriptor instead of putting > it inside the servlets (that's what struts-config.xml does). > > For the transformation, I was also thinking about using a Filter servlet to > transform the XML to HTML and decouple it from the main application. But for > that we need to move to WebLogic 6.1 to get the servlet API 2.3. > > That's what we have now... > > Denis. > > -----Original Message----- > From: Michael Baldwin [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 02, 2001 12:24 PM > To: [EMAIL PROTECTED] > Subject: Re: Using Struts with XML ? > > Denis, > I'm looking at the a similar problem for a new system. I'd very much like > to > apply XSLT to the result. > I'm considering using struts Actions to interact with an EJB layer that will > produce value objects. > I'm thinking then about forwarding on the request to a JSP that understands > how > to transform these value objects into a DOM tree and then uses a XSLT > Transformer to do the real work. > > >From what I can tell, this path has not been well tread using struts, so > I'm > still looking at options. > > How are you currently going about XML document generation and XSLT template > application? Is it all servlet managed? I'd be interested to hear. > > --Michael
