Return-Path: Delivered-To: apmail-jakarta-struts-dev-archive@apache.org Received: (qmail 53742 invoked from network); 2 Jul 2002 14:56:12 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Jul 2002 14:56:12 -0000 Received: (qmail 4700 invoked by uid 97); 2 Jul 2002 14:56:06 -0000 Delivered-To: qmlist-jakarta-archive-struts-dev@jakarta.apache.org Received: (qmail 4655 invoked by uid 97); 2 Jul 2002 14:56:05 -0000 Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list struts-dev@jakarta.apache.org Received: (qmail 4643 invoked by uid 98); 2 Jul 2002 14:56:05 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D21BEEB.7F5A2B@apache.org> Date: Tue, 02 Jul 2002 10:55:39 -0400 From: Ted Husted Reply-To: ted@husted.com Organization: Apache Software Foundation / Jakarta X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Struts Developers List Subject: Re: FormBeans ... as an Interface. References: <5484244.1025617629494.JavaMail.root@project1.usiatl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 struts-dev@japache.org 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: > For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: