struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Louis Leung <louis.le...@sun.com>
Subject Re: Form -> Bean conversion
Date Fri, 15 Feb 2002 23:06:31 GMT
I agree.  That is really the point of the Action Form.

But in the application I'm working on, the majority of the values in the value
objects are just string.  So my ActionForms really just do nothing except for
mapping the values coming in back to the actual value beans directly.  With nearly
1000 forms and more than 5000 properties that needs to be implemented, such method
becomes a pain for the developers.

So we chose to map the input values directly to the actual value beans, and save
the invalid values (values that cannot be mapped) in a Hashmap.  We then plan to
modify the <html:text> tag to first look at the Hashmap to see if the property
exists, then use the actual bean property if such property is not in the Hashmap.

Althought this is ruining the purpose of the action form, but we think this will be
alot easier for the development.



Ted Husted wrote:

> The underlying issue is transmitting the input by HTTP. Everything is
> passed by HTTP as a String. The problem with binary properties in
> ActionForms is what happens if the input doesn't convert to a String?
> There is no place to store the string that didn't convert and return it
> to the user, so the property comes up null.
>
> The BeanUtils will convert the standard types, but that doesn't help
> much when the conversion fails. In the end, you need some type of String
> property buffer for all the binary properties, or else the input cannot
> be returned to the user for correction.
>
> I can appreciate not wanting to replicate the properties, but it's
> important to note that these are not input, but prospective input, that
> needs to be scrubbed and validated before it can be passed along to the
> business beans.
>
> You are not so much re-creating the bean properties, but creating a
> String buffer for the HTML controls, which, as a convenience, may share
> the same name with a property on your beans.
>
> For more see,
>
> http://www.mail-archive.com/struts-user@jakarta.apache.org/msg08070.html
>
> http://www.mail-archive.com/struts-user@jakarta.apache.org/msg20833.html
>
> http://www.mail-archive.com/struts-user@jakarta.apache.org/msg19338.html
>
> "John M. Corro" wrote:
> >
> > The particular base bean's (the bean that is an instance variable of the
> > ActionForm) accessor/mutator methods handle very specialized data types
> > (custom written classes).  Assuming the ActionServlet is unable to do the
> > conversion, would I have to alter the source code?  Is it possible to extend
> > the ActionServlet to provide for this custom conversion and then modify the
> > web.xml file so that it references the updated ActionServlet?
> >
> > <servlet>
> >
> >     <servlet-name>action</servlet-name>
> >
> >     <servlet-class>com.ExtendedActionServlet</servlet-class>
> >
> >     ...
> >
> > </servlet>
> >
> > ----- Original Message -----
> > From: "Louis Leung" <louis.leung@sun.com>
> > To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> > Sent: Friday, February 15, 2002 3:47 PM
> > Subject: Re: Form -> Bean conversion
> >
> > > yeah, but on your <html:text> tag, your property should look something
> > like
> > >
> > > property="someBean.someProperty"
> > >
> > > then, what struts will do is ActionForm.getSomeBean().getSomeProperty().
> > >
> > > Regarding to the actually bean's property something that is not string, I
> > think
> > > the ActionServlet does the convertion for you.  Check out the
> > ActionServlet
> > > source, processPopulate() method, and ConvertUtil.java in util package of
> > struts
> > > source.
> > >
> > > "John M. Corro" wrote:
> > >
> > > > Unless I'm misunderstanding, I'm not sure if that will do what we're
> > hoping
> > > > for....
> > > >
> > > > When you use the html:form tag (and corresponding input tags from the
> > html
> > > > tag lib) on a JSP page there's error checking to make sure you have a
> > > > corresponding get/set method in the ActionForm.  If we have the original
> > > > bean as an instance variable in the ActionForm and have no other
> > > > getters/setters hardcoded into the ActionForm, won't that cause a
> > > > compile-time error on the JSP?
> > > >
> > > > ----- Original Message -----
> > > > From: "MacKellar, Kimberly" <Kimberly.MacKellar@tfn.com>
> > > > To: "'Struts Users Mailing List'" <struts-user@jakarta.apache.org>
> > > > Sent: Friday, February 15, 2002 2:54 PM
> > > > Subject: RE: Form -> Bean conversion
> > > >
> > > > > I have instances of beans within the ActionForm and then access them
> > with
> > > > > the name of the bean and the name of the property in the bean when
> > using
> > > > > them in the JSP.  The only problem is having non-Strings in the bean.
> > You
> > > > > need to do some sort of conversion within the ActionForm to get around
> > > > this.
> > > > >
> > > > > Kimberly MacKellar
> > > > >
> > > > > -----Original Message-----
> > > > > From: John M. Corro [mailto:john.corro@cornerstone.net]
> > > > > Sent: Friday, February 15, 2002 2:53 PM
> > > > > To: struts-user@jakarta.apache.org
> > > > > Subject: Form -> Bean conversion
> > > > >
> > > > >
> > > > > We have a bunch of existing beans that we'd like to use w/
> > ActionForms.
> > > > For
> > > > > each bean we'll need to obviously expose the getters/setters in the
> > > > > corresponding ActionForm.  The ideal scenario we'd like to see happen
> > is
> > > > > prevent the ActionForms from having all the corresponding
> > getters/setters
> > > > > hardcoded into it.  We're ok w/ coding the validate() method for
each
> > > > class
> > > > > by hand, but we'd like to avoid having to code each ActionForm w/
a
> > > > > getter/setter (even if it is templated out for us by a Struts plug
in
> > or
> > > > > even a custom written batch file).
> > > > >
> > > > > Has anyone implemented something like this?
> > > > >
> > > > > --
> > > > > 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>
> > >
> > >
> > >
> >
> > --
> > To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Java Web Development with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
>
> --
> 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