> 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.
Re-use of business logic is one thing. But I think that re-use of client side logic is also very important. My thinking here is that any client (or many at least) would want to leverage the implied workflow of actions, data validation, etc. As far as re-architecting, I won't attempt to speak to the entirety of what would be needed, but from what I see the core concepts and constructs of the controller would remain intact. The internal semantics would change to be more nuetral. I think that named parameter based inputs would still be the way to go and therefore the bean and form manipulation would remain intact. Client implementations would then be responsible for accepting incoming requests, mapping them to the defined Struts format and letting the Struts controller do the rest. I would also wrap the UI / View portion of it into specific client implementations. So, in the current model the HTTP or web implementation would include the HTTP Servlet and set of tag libraries. >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]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
