Hmmm...that's a good question. I think there are pieces of stxx it would be good to provide with Struts for the casual user who wants to take an existing Struts action, and render content via XSLT/XSL-FO with little effort. To truely do XML processing right, however, I think a stronger solution of Struts and Cocoon integregated together is the answer. This, of course, would fall outside the scope of Struts core.
Could stxx's XML processing features be put into Struts 1.x? Yes, but before that happens, I think some sort of url feature for forwarded paths should be put in first. This would allow a request to easily be forwarded to a different presentation system without modifying or overriding the request processor. For example, a forward to a jsp page could look like: "jsp://Foo.jsp", for tiles: "tiles://Foo.jsp", and for stxx: "stxx://Foo.xsl". This feature would make it easy to have multiple presentation engines, a feature we say Struts supports, but it doesn't really. Don On Fri, 19 Dec 2003, Ted Husted wrote: > Do we still want to integrate stxx into Struts 1.x? > > Don Brown wrote: > > Using JXPath is exactly what XMLForms (http://www.xmlforms.org) does to > > allow the form model to be anything from a DOM to a JavaBean or even a > > DynaBean. XMLForms came out of Cocoon, but I believe they still use > > something simliar. In stxx (http://stxx.sf.net), a Struts extension, I > > have been experimenting using XML as the data model for a form. It is > > particuarly useful as it allows forms to be simultaneously exposed via > > Struts and SOAP. > > > > Don > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
