You *might* be able to use XHTML and let everything through for you HTML clients, and then you'd only require a XSL stylesheet for the VoiceXML client. Since XHTML *is* XML - this might work?
HTH, Matt -----Original Message----- From: Kris Schneider [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 2: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:[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]>
