You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Gr...@alltel.com on 2002/07/09 19:21:44 UTC
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 <gl...@yahoo.com>
> > Reply-To: Struts Users Mailing List <st...@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 <tu...@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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
An XDoclet approach (was: DynaActionForm Advantages)
Posted by Dave Johnson <sn...@nc.rr.com>.
Greg.Reddin@alltel.com wrote:
>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?
>
In Roller, I solved this problem by using XDoclet. I use an abstract
class marked up with both @struts:form and @ejb:data-object tags for
each of my model objects. Then XDoclet generates both my model objects
(data objects, value objects or whatever you want to call them). The
form object know how to return data objects, so I don't need to do any
mapping.
Here is an example of one of those marked up beans:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/roller/roller/src/org/roller/business/beans/BookmarkBean.java?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup
This is not an ideal approach because 1) it assumes that you will have a
1:1 correspondence between form beans and action beans. But it works
well for me.
If I need to have a form with fields that are no part of the corresponding
data object, then I extend the generated form class and add the fields
that I need.
And 2) the model objects tend to be pretty dumb - but so far this has
not been a big problem.
You can read more about the Roller architecture here:
http://www.onjava.com/pub/a/onjava/2002/04/17/wblogosj2ee.html
I'd love to hear any feedback about this architecture you might have,
especially negative feedback - I'd like to know what I can improve.
- Dave
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DynaActionForm Advantages (A different approach)
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Greg.Reddin@alltel.com wrote:
> 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.
I'm doing something pretty similar based on nested tags & beans, which I
started out using only for pages with rows of records to edit, but now
use even on pages with only one record, since the technique cuts out
duplicating fields in a value bean and a form bean.
My value beans have the normal getter & setter methods with the business
layer uses, and each field also has a string-type field with a string
getter & setter pair which the nested tags and struts use to fetch or
fill the indexed properties.
The string getter methods fetch the value of the normal-type field and
convert it to string, and the form on validation converts the strings to
the normal types.
Works fine, but I'm sure it blurs the boundaries of MVC, although I
haven't come across any problems or issues with it yet.
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: DynaActionForm Advantages (A different approach)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 9 Jul 2002 Greg.Reddin@alltel.com wrote:
> Date: Tue, 9 Jul 2002 12:21:44 -0500
> From: Greg.Reddin@alltel.com
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> 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.
>
No, any "disconnect" that exists for standard ActionForm beans will also
exist for DynaActionForm.
The preferences for Strings in form beans is to deal with bad user input
(such as typing "1a3" into a text field destined to be an integer). Any
solution that does not redisplay the bad data that the user typed (just
like every GUI program in the world does it) is not acceptable, IMHO.
One approach to migrating the data out of the form bean and into the model
bean would be to grab all the properties out into a Map (perhaps by
calling PropertyUtils.describe()) and then using
BeanUtils.populate() to copy these values into your model bean. This will
perform String->whatever conversions for you as it goes.
> 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?
>
I'd certainly be interested in seeing how you've approached this.
> Thanks,
> Greg
Craig
>
> > -----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 <gl...@yahoo.com>
> > > Reply-To: Struts Users Mailing List <st...@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 <tu...@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:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>