Inline...
Quoting "Craig R. McClanahan" <[EMAIL PROTECTED]>:
>
>
> 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?
>
Communication breakdown there - not at all what I intended to convey. One of my
concerens is that if I move to an architecture where the app outputs XML that is
then transformed, I lose the built-in functionality of the HTML-centric Struts
tags like html and nested. Presumably, that functionality (e.g. rendering form
elements for indexed form bean properties, tokens, etc.) would have to be
handled by the XSLT stylesheets. One of the potential compromises is to use the
Struts tags to output XHTML to generically represent forms and links. So, I
don't have any problems with the Struts tags, just the opposite, I'm concerned
about losing their utility by moving to a more XML-centric approach.
As for the <x:transform> tag, I'm actually thinking that it might obviate the
need for additional add-ons like stxx and StrutsCX. I can have an action forward
to a JSP for the client-agnostic view (i.e. XML) by using something like my
original example. Since <x:transform> can take a dynamic value for the XSLT
stylesheet, it seems like a pretty flexible solution.
> 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.
>
+1
> 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]>
>
--
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]>
