Any take on having the filter perform the transform vs. JSTL (see original example)? Seems like you ought to be able to work up a caching approach with JSTL as well.
How 'bout the fact that by creating XML you give up some of the Struts tags? Quoting Jacob Hookom <[EMAIL PROTECTED]>: > If you are dealing with two platforms, I would say use filters. Request > processes would go like such: > > www.mysite.com/public/viewAll.html > -->Filter catches request, wraps the response and forwards to: > www.mysite.com/viewAll.do?format=html&forward=xml > -->Struts generates beans and forwards to JSP for XML generation > www.mysite.com/WEB-INF/transform.jsp?format=html > -->Page outputs XML data, but remember the filter gets the response back > so it then looks at the format again or another request attribute to get > the style sheet to do the transformation and setting of the headers. > > So your Struts actions know nothing of what formatting to use or what > XML is, they just get the business objects you need based on the > request. Then your action can possibly check for the forward tag to > actually forward to a JSP that will take the output and create XML. > Then it is up to your filter to catch the returning response and do an > XSLT transformation on it and set the appropriate headers. This output > can be cached for faster access next time. > > Jacob Hookom > > | -----Original Message----- > | From: Kris Schneider [mailto:[EMAIL PROTECTED]] > | Sent: Thursday, January 16, 2003 3:13 PM > | To: Struts Users Mailing List > | Subject: Struts app design for multiple client types > | > | I'm in the process of designing a single web app to support two > different > | client > | types: HTML and VoiceXML. Yes, yes, I know, XSLT is just the ticket. > That > | was my > | initial take at least, but I'd like to bounce some things off the > Struts > | hive > | before committing to it. To add some context, I'll be deploying on a > full > | J2EE > | 1.3 platform, so things like servlet filters and JSTL get to play. I'm > | also > | aware of existing XML/XSLT solutions like Cocoon, stxx, and StrutsCX > and > | have > | done some preliminary investigation of each. The application itself is > | generally > | form/data driven. The major issues I'm currently spinning on are the > | following: > | > | What do the existing solutions offer that I couldn't do with JSTL and > | relatively > | simple filters? For instance, my JSPs might just become: > | > | <x:transform xslt="${dynamicallyAssignedBasedOnUserAgent}"> > | <!-- body specifies XML document and transform params --> > | </x:transform> > | > | How difficult would it be to duplicate the functionality of the Struts > | html and > | nested tags? Those tags do a lot of work on a page author's behalf > with > | respect > | to handling form rendering, indexed form bean properties, transaction > | tokens, > | URL encoding, etc. If the app is just dumping XML, then it seems like > the > | XSLT > | styleheets could get pretty hairy. I suppose the Struts tags could > still > | be used > | to output XHTML fragments which might make the transforms less > painful. > | > | If you've got some specific insight into those issues, or would just > like > | to > | share your approach to using Struts for apps that support multiple > client > | types, > | I'd love to hear about it. Thanks. > | > | -- > | Kris Schneider <mailto:[EMAIL PROTECTED]> > | D.O.Tech <http://www.dotech.com/> > | > | -- > | To unsubscribe, e-mail: <mailto:struts-user- > | [EMAIL PROTECTED]> > | For additional commands, e-mail: <mailto:struts-user- > | [EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- Kris Schneider <mailto:[EMAIL PROTECTED]> D.O.Tech <http://www.dotech.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
