So are you telling me that the chain package is going to define a common object that can handle the form controls that an Action and an Applet could manage?
One critically important thing to remember is that applets run inside the client machine, while Struts runs on the server. So commons-chain, or any other such framework, is not going to be of much direct use for communicating between the client and the server -- for that, you'll need to define data formats for messages that your applet will send to the server, and the response it receives. XML is a popular choice for such a data format lately - that's what "web services" is really all about at the foundational level.
Would it imply, for instance, that Actions and Applets will have reference to a package such as chain, will query their controls, will build the 'chain object', and the business lier will be able, thanks to the chain package, and unaware about the presentation adapters, to manage this object and create a response that then would be re-transormed in a presentation response?
I don't know the price that we should pay for it, maybe it justifies the benefits, but is it not what it's already happening in the Actions?
I think that tons of paper have been written about the correct methodology to follow when writing MVC applications: the controller should act as a 'proxy', dealing only with objects that strictly are related to request/response. This is already happening...My question was: what if I create an applet (for several reasons, let's say that it gives to me better control on the page presentation) which contains form controls, and I want those controls be managed by servlets (in this case identified by the Struts framework)? I would like to have the flexibility ensured by applets with the standard of a MVC application.
Is the chain package going to be the bridge between the business lyer and whatever presentation lyer?
I don't see how chain has much to do with client-server communication. It *can be* about what happens when the applet's request arrives at the server in order to satisfy the request, but you can also just have your applet call directly to the URLs of Struts actions that do whatever is necessary to return the response.
Chain can help your requriements if the server side processing required to perform a task is complex, and is suitable for being decomposed into a bunch of small steps. It's helpful to someone like the Struts developers building Struts itself, because it lets us break apart the RequestProcessor so that you can insert your own custom processing steps more easily.
MarcoCraig
<!-- ORIGINAL MESSAGE --> This is the general direction we are going with the Common Chain package.
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/
So, to answer your question, it's no so much that we need to pass a generic component object to an Action, but that the Action (and Applet) should pass a generic object to your business layer. (The less done in Action classes, the better.)
-Ted.
---------------------------------------------------------------------
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]
