If you can design your ActionForms to share the same property names (or "protocol") as your data transfer objects, then it does become very easy for an application to develop a standard, automatic way to populate the DTO from the ActionForm properties.
But since this is "pretty easy", there just isn't a lot of value to adding this sort of thing to the base ActionForm. It could easily start us down the slipperly slope where it looks like Struts is trying to dictate what your dto or value objects are suppose to look like. We do have some standard Actions, like DispatchAction, in the framework distiubtion. These are quite handy in some instances, but there's no reason to add this functionality to the base Action. Likewise, if people develop standard ActionForms with methods that might be handy in some instances, these too can be published and offered to the community. AFAIC, if anything should be an interface, it should be the dto. Then you can let your ActionForm implement the dto interface, instead of the other way around. Applications that don't already do this may have other bad habits, which in good conscious, we respectfully decline to encourage =:-) In Struts 1.1, between DynaActionForms and map-backed beans, the maintenance issues for ActionForms are diminished or even eliminated, and so like 90% of "the problem" becomes a non-issue. -- Ted Husted, Husted dot Com, Fairport NY US -- Java Web Development with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services [EMAIL PROTECTED] wrote: > > You state: > > The ActionForm contains a *proposed* > > state change to the model or one of > > its beans. As Web developers, it's > > our job to confirm that the state > > change is reasonable (validate the > > input) and ~then~ update the model. > > Using a value object would be a standard way of handling this. If the ActionForm >were coded to have a property that references a value object, then you've allowed >Struts to populsate its fields and have still separated the code that applies the new >values. (In other words, your server application will still have a method named >something like "setInfo(MyValueObject vo)" called by our Action classes.) > > This would all be pretty easy, except that as far as I can tell, there is no way to >initialize an ActionForm other than hard-code the creation of the view's ActionForm >in the Action. > > -- > Posted via jApache.org > > -- > 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]>
