I, also, have been thinking about Struts within an application which has
some SOAP methods in addition to a human-client interface (web or
otherwise).
My resolution has been, build a back-end set of business classes, and
have my SOAP classes as well as my Struts actions be thin shims to the
back-end business classes. No particular need to rearchitect Struts to
achieve this kind of design. However I'm intruiged by the possibility of
there being better code-reuse or something. I don't know what shape that
would take.
Bryan
On Tue, 2002-02-26 at 11:52, Laine Donlan (DEV) wrote:
Wondering if there has ever been any discussion about moving the controller
portion of Struts to be non-http dependent. Much in the same way as the
workflow component of the commons seems to be going, and providing a way to
not only support multiple client type views (xsl, wap, html, etc) but also
to allow the controller portion to be accessed via multiple clients.
For example there would be some sort of core Servlet that would do all of
what the ActionServlet does now, all of the HTTP concepts would probably
need to be replicated - probably as wrappers of the HTTP implementations -
or of custom implementations for various client types. Various
implementations could then be created as decendants of the ActionServlet -
Web, SOAP, Rmi, etc.
Any feedback would be appreciated.
Laine
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
