----- Original Message ----- From: "Bob Lee" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, April 10, 2002 9:37 AM Subject: Re: Is FormBean mandatory???
> ----- Original Message ----- > From: "Jing Zhou" <[EMAIL PROTECTED]> > To: "Struts Developers List" <[EMAIL PROTECTED]> > Sent: Wednesday, April 10, 2002 4:28 AM > Subject: Re: Is FormBean mandatory??? > > > > Form beans can be shared by multiple views in a wizard like applications. > > In particular, we want users to be able to use 'Previous', 'Next', > 'Finish', > > and 'Cancel' buttons to move between screens. Using form beans will save > > a lot of coding work and these requirements are mandatory regardless > > how large or small the applications are. > > Is it ever necessary to retain erred inputs past the request context? I > still don't understand why you need getters and setters for every form field > when the data is readily available in the request object. Some argue better > type checking, but the fact is half this benefit is lost when you start > depending on reflection. Also, Struts tools would be a lot easier to develop > if you could just work against a field map rather than having to dynamically > generate Java interfaces; from what I gather, this is what the DynaBean > accomplishes. > > Thanks, > Bob > > The current Form Bean implementation (ActionForm + DynaBean) is to provide a base for possible sophysisticated implemenations. The *advanced* versions of Form Bean should accomplish the following goals (in my personal opinions) * The internal data structure or model for the Form Bean could be regular Java Bean or XML DOM or HashMap. But from outside point of view, These internal models are interchangable, nestable, with uniform and consistent access methods and developers should not worry about getter/setter any more. * Initialization could happen when STRUTS initialize itself or on demand. Consider the system has 5000 form bean models in database, it can't initialize all of them at startup. STRUTS tool may help here. * Form Bean should know how to reset/validate its internal properties given a view model. It should reset those properties with respect to a view, not reset all properties. The same is true for validation. * Form Bean should also know how to persist itself into strings and reload from strings as well as provide some callbacks for custom actions. Again not all fields are to be persisted. This is needed when replaying the submission processes is necessary in certain business requirements, like address corrections when you moved. Can any validator validate your address? :-) Our internal system basically accomplish the above goals therefore a visual tool is developed for it. The system also manage the security of the Form Bean as well as multi-user access to the same From Bean. The EJB security and concurrent services are not enough. The presentation layer needs those concepts too before the data reaching EJB server. So, if stay with the Form Bean, the benifits are a lot than just type checking. > -- > 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]>
