commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Lesiecki" <n...@eblox.com>
Subject RE: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Date Mon, 17 Dec 2001 21:47:43 GMT
<<<
Cases (2) and (3) are the highest on my priority list.  Case (3) is what
Struts users are concerned about -- right now, Struts requires you to
program a separate bean for every form, and it would be nice not to have
to do that.
>>>

AHHHH! Noooooo on case 3! It would be "nice" not to have to do code a form,
but how would I get the values out of the form?

Currently:

MyForm myForm = (MyForm)form;
String value = myForm.getValue();

With DynaBean:

DynaForm dForm = (DynaForm)form;
String value = (String)dForm.get("value");

How is this more desirable than:

String value = (String)request.getParameter("value");

?

One of the things I loved about Struts was that I could rely on Struts to
provide strongly typed inputs to my action classes, with Dynamic form input
I might as well go right to the request. Of course I probably don't have to
use DynaForm, but I'm saying it should not be a use case which drives the
development of DynaBean.

Cheers,

nick

-----Original Message-----
From: craigmcc@neo.austinite.com [mailto:craigmcc@neo.austinite.com]On
Behalf Of Craig R. McClanahan
Sent: Saturday, December 15, 2001 5:50 PM
To: Jakarta Commons Developers List
Subject: Re: [Design Discussion] DynaBean - JavaBeans with dynamic
properties




On Sat, 15 Dec 2001, Jason van Zyl wrote:

> Date: Sat, 15 Dec 2001 17:59:58 -0500
> From: Jason van Zyl <jvanzyl@zenplex.com>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: Re: [Design Discussion] DynaBean - JavaBeans with dynamic
>     properties
>
> On 12/15/01 4:26 PM, "Craig R. McClanahan" <craigmcc@apache.org> wrote:
>
>
> (2)
> > * A way to construct and use "value objects" that extract the
> > properties of an EJB into a structure that can be utilized by a
> > presentation tier technology such as JSP pages, without having
> > to hand code the value object.
>
> (3)
> > * A way to capture *all* of the request parameters from a servlet
> > request as a single object.
>

(Thanks for the numbering ... that helps clarify references :-).

> [snip]
>
> For (3) that would be excellent. So you could match up the dynamic
> properties produced by the request with an object? That would be very
cool!
>
> For (2) I'm not sure I understand what you mean. I don't use JSP or EJB's
so
> I'm not clear on how using a DynaBean in a JSP would differ from using the
> EJB directly in the JSP?
>

Cases (2) and (3) are the highest on my priority list.  Case (3) is what
Struts users are concerned about -- right now, Struts requires you to
program a separate bean for every form, and it would be nice not to have
to do that.

Case (2) is based on a similar design principle when using EJBs.
Conceptually, an entity EJB (representing persistent data from the
underlying persistent store) can be used directly like a JavaBean --
however, it is possible (or likely, depending on your deployment scenario)
that every property getter call will be remote because the EJB itself is
on a different server.  That has unacceptable performance impacts in most
scenarios.  A value object is retrieved from the EJB with one (remote)
call, and then its just a JavaBean for your presentation technology (such
as a JSP page or a Velocity template) to use.

A second reason for using value objects is separation of the presentation
layer state of a transaction (i.e. the changes to the property values that
are being made as the result of form submits) and the state of the
underlying persistent data.  There are at least three important
considerations:

* You don't want to immediately write the input values from
  the user into the persistent object, until the input has all
  been validated AND until you know that the user isn't going
  to undo the transaction.

* Just as with getters, property setters are potentially a bunch of
  individual remote calls (RMI or CORBA or whatever), so you'd be better
  off to do them all in one call.

* Aside from the remote call issue, starting to call property setters
  on an EJB may (depending on how you manage your database transactions
  and container-managed or bean-managed persistence) start a database
  transaction, and therefore lock resources, until the last one is done.
  Good database practice says you want to minimize the amount of time
  that happens, which could be a long while if you're using a multipage
  input form.

The recommended solution, then, is to collect all the updated stuff in a
value bean (or a set of individual properties somewhere) and do the actual
updates with a minimal number of calls (ideally just one).

Traditionally, value objects are painful to develop in the same way that
Struts ActionForms are -- you have to write each one individually, and a
more tedious and boring kind of programming you won't find anywhere.
Using a DynaBean for this purpose means you can reuse one general purpose
class for most or all of these requirements, rather than having to code
one for each different value bean (and maintain them later as the set of
properties evolves over time).

Value objects are useful in non-EJB environments as well, for pretty much
the same design reasons.  One useful source of info about them:

  Alur, Crupi, Malks, CORE J2EE PATTERNS:  BEST PRACTICES
    AND DESIGN STRATEGIES, Prentice Hall, 2001.

The J2EE Blueprints guidelines also recommend using value objects, for the
same sorts of reasons.


> Just a quick set of comments :-)
>
> --
>
> jvz.
>
> Jason van Zyl
>

Craig


--
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