struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Cancro <DCan...@bridgespan.com>
Subject RE: DynaActionForm Advantages (A different approach)
Date Tue, 09 Jul 2002 17:33:12 GMT
How does your PageField list handle iterative and nested properties?  Can a
PageField's value be a String array?

> -----Original Message-----
> From: Greg.Reddin@alltel.com [mailto:Greg.Reddin@alltel.com]
> Sent: Tuesday, July 09, 2002 10:22 AM
> To: struts-user@jakarta.apache.org
> Subject: RE: DynaActionForm Advantages (A different approach)
> 
> 
> 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:craigmcc@apache.org]
> > 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 <glenmazza@yahoo.com>
> > > Reply-To: Struts Users Mailing List 
> <struts-user@jakarta.apache.org>
> > > To: struts-user@jakarta.apache.org
> > > Subject: Re:  DynaActionForm Advantages
> > >
> > > > Fecha: Mon, 08 Jul 2002 23:37:03 -0400
> > > > A: struts-user@jakarta.apache.org
> > > > De: James Turner <turner@blackbear.com>
> > > > 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:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: 
> > <mailto:struts-user-help@jakarta.apache.org>
> > 
> > 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:struts-user-help@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message