Something that has always bothered me in Struts is the "disconnect" between Form Beans and Model Beans. How many times do you have a Form Bean and a model bean that contain the same data? The disconnect makes some sense because you want everything that could come in from a JSP page to be String-based, while you want the properties of your model beans to be properly typed. Plus there are often things on the Form Bean that will not be in the model bean or will be represented differently. But I've found myself constantly trying to find an easy way to map the data from my form beans back to the model beans in Struts without manually copying the data. It appears DynaBeans don't fix this.
Our company has developed a framework loosely based on Struts, that has a single component for storing page data and mapping it back to model beans. Each JSP page has a bean that holds its data. The data is contained in a list of PageField objects. The PageField has getFieldValue() and setFieldValue() methods that return and take Strings respectively. The PageField also has a mapping that will map the field back to a model bean, if desired. The mapping is specified in the JSP tag. Page data that is contained in a model bean is automatically retrieved from and populated to the model bean by reflection. Page data that does not cleanly map back to the bean is kept in PageField's internal storage. This works great for us because we do not have to write form beans for every page. Whatever beans we need to use are automatically populated by the framework. Would something like this be useful to the Struts community? Do you see issues with the approach? Thanks, Greg > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 09, 2002 11:47 AM > To: Struts Users Mailing List > Subject: Re: DynaActionForm Advantages > > > > > On Tue, 9 Jul 2002, Glen Mazza wrote: > > > Date: Tue, 9 Jul 2002 09:58:29 -0500 (CDT) > > From: Glen Mazza <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: Re: DynaActionForm Advantages > > > > > Fecha: Mon, 08 Jul 2002 23:37:03 -0400 > > > A: [EMAIL PROTECTED] > > > De: James Turner <[EMAIL PROTECTED]> > > > Asunto: RE: DynaActionForm Advantages > > > > > > My two cents on the topic. > > > > > > As mentioned, once you move to a good Java IDE like > > > JBuilder, writing > > > getters and setters is no longer nearly the pain it > > > used to be. > > > > > > > Correct--the ActionForm follows the standard JavaBeans > > approach--reduced learning curve for newcomers, and > > already generated by most IDE's. > > > > > > > What bothers me about the DynaBean approach is that > > > it's *yet another* > > > file, and *yet another* level of indirection that > > > obscure what's really > > > going on. I can look at an ActionForm, see all the > > > properties, look at the > > > validation, all in one step. Making it a DynaBean > > > form means having to > > > maintain another file with the XML, always having to > > > remember where it is, etc. > > > > > > > Mostly agree. It's not "yet another" file, because > > DAF's were (I believe) originally designed to reduce > > the number of ActionForms you'd have to implement. > > I.e., if you don't have any special validation to do, > > don't bother subclassing an ActionForm--just put the > > variables in the struts-config and you're done. Very > > nice design. > > > > The problem was that the DAF class was not made final. > > Allowing it to be subclassed is creating the mess you > > describe--the variables in the XML file and actions on > > them in the DAF subclass. (Another was writing about > > putting member variable initializations in the > > validate() function--the DAF subclass may also start > > encouraging other messier programming habits.) > > > > As for those who don't like getter/setters and want to > > use the common-beanutils "get" functions described by > > Craig: Might it have been better, in addition to > > making the DAF class final, > > Making DAF final would have prevented the use case where you want to > subclass it for custom reset() or validate() methods. This would have > forced the use of two classes instead of one -- IMHO that > would have been > more confusing, not less. > > > to just have ActionForms > > implement "get"'s interface? Just newbie thinking... > > And the "set" methods also, I presume? That's an interesting > idea -- then > users of the form beans could always use get()/set() and not > care whether > it was actually a DynaActionForm or not ... > > > > > Glen > > > > Craig > > > -- > 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]>
