Michael, There is very little difference. Others have mentioned support for multiple view, which is great but I don't want to have to do double the effort to support two views instead of one. There is benefit in defining that response in a view neutral way so that interaction could
be between the Struts action Servlet and any supported client. Those clients could be SOAP, html/jsp, XML, SWT, whatever. What I was trying to point out is that the value in supporting multiple views is realized when you can those views from a single definition. That implies some metadata describes the "ins and out". XML is certainly a good starting point for the output stream because it is pretty easy to transform and process. It is also easy to kill performance doing those transformations. Compiling the transformation can help but as far as I know not seen this done with Struts. Client side transformation can help, but that is of little benefit with SOAP clients and limits your client set to a few browsers. That said, it isn't a bad idea to retrofit support for a new view and then factor out the common parts and define the model, view, and controller using metadata. Having built a metadata driven framework for describing and applications I know some of the challenges involved and understand the benefits. I would guess that among struts developers, many use metadata to define the model, a few use metadata to define the view and no one uses metadata (other than the struts-config file) to define the controller. David morris >>> [EMAIL PROTECTED] 01/24/03 03:20PM >>> David, I think it safe to say that many are probably already returning XML with Style sheets from Struts. That being the case I see little difference between the response of a Web Browser action request being an XML/XSLT page or a SOAP Client getting a response with an XML SOAP Response except of course the format. Michael Oliver -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
