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?
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? Marco <!-- 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]
