commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Hernandez" <s...@eorbit.net>
Subject RE: BeanUtils.populate() question
Date Wed, 10 Apr 2002 05:40:22 GMT
Yep, in Maverick (mav.sourceforge.net) we do something very much like
what you have described.

The basic flow is a mapping of the Model-View-Controller arch onto web
applications. We take the request and use the BeanUtils to populate a
bean instance with that data. Then we pass that data (bean) to the
controller which then in turn creates a model, and passes it on to the
view for rendering. So all you need to do is write the setter methods
and you will be populated with the corresponding values from the http
post, or get.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/maverick/src/java/org
/infohazard/maverick/ctl/ThrowawayBean.java?rev=1.2&content-type=text/vn
d.viewcvs-markup

It works great and removed the need to duplicate this type of thing
yourself. We had originally written own populator. :)

Later,
Scott
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org] 
Sent: Tuesday, April 09, 2002 8:01 PM
To: Jakarta Commons Developers List
Subject: Re: BeanUtils.populate() question



On Tue, 9 Apr 2002, Heath Chiavettone wrote:

> Date: Tue, 9 Apr 2002 18:34:52 -0700
> From: Heath Chiavettone <HChiavettone@ariba.com>
> Reply-To: Jakarta Commons Developers List
<commons-dev@jakarta.apache.org>
> To: "'commons-dev@jakarta.apache.org'"
<commons-dev@jakarta.apache.org>
> Subject: BeanUtils.populate() question
>
> I know that this package is mostly used by Struts but it is designed
to be
> used generically.  We are in the process of evolving to Struts, but it
will
> take some time.  So here is the scenario I'm thinking of using this
in.
>

The original design of BeanUtils.populate() was to replace
<jsp:setProperty property="*"/>.  It should do what you described below
(with the extra abilities to handle nested, indexed, and mapped property
names automatically as well).

Craig

>
>
> In our (Model 1) world, we have designed our JSPs to be mated to a
JavaBean
> which is used to process all of the data for the form.  We are using a
> custom tag to "initialize" these beans on in the JSP and then use the
> <jsp:setProperty name="*"/> mechanism in the JSP to "bind" the data to
the
> bean.  Recently, we have begun using a (Servlet 2.3) filter, to
> pre-processed the request and convert the String and String[] into the
> appropriate object types such Integer, BigDecimal, Long, and several
other
> application-specific "primitive" types (using a custom mechanism) and
stores
> them in the request as attributes (keyed to the parameter name).  As a
> result, I can now create a Map that is keyed to the property name, but
will
> contain the not only the basic String or String[] values for all
"real"
> string properties, but also these other object types.  Rather than
using the
> setProperty * mechanism, I would like to modify the custom tag to use
the
> BeanUtils package to improve our "binding" mechanism.  In looking at
the
> Javadoc (see below) for the populate method, I'm not to sure if what I
want
> to do will work.
>
>
>
> I was wondering if the BeansUtil.populate() method could be used in
the
> following manner:
>
>
>
> Parameters:
>
> bean - JavaBean whose properties are being populated
>
> properties - Map keyed by property name, with the corresponding
(String or
> String[]) value(s) to be set
>
>
>
> So I guess I have couple of questions:
>
>
>
> 1.	Can I use populate to accomplish my goal of binding the Map of
the
> various property "Objects" to the appropriate bean properties?
> 2.	If not, then will the PropertyUtils.set*() class of methods
work?
> 3.	If so, will I gain any of the Introspection performance gains
that I
> believe BeanUtils.populate gives me?
>
>
>
> Thanks,
>
>
>
> Heath
>
>


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


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


Mime
View raw message