On Thu, 16 Jan 2003, Kris Schneider wrote:
> Date: Thu, 16 Jan 2003 16:12:36 -0500
> From: Kris Schneider <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> 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.
>
Why would it be necessary to add XSLT functionality to Struts tags, when
the <x:transform> tag already exists. Or, to put it another way, what
does the <x:transform> tag (by itself) *not* do that you think would be
helpful?
My gut feel is that further XMLish integration into Struts itself should
focus more on things like defining a processing pipeline in struts-config
-- sort of like Cocoon's sitemap, but not quite so much work. In other
words, focus on enriching the controller functionality.
Tag libraries like JSTL are designed to interoperate with each other, so
if you happen to be using JSP for output, it makes perfect sense (at least
to me) to use them.
> 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/>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
