struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Devine" <>
Subject Re: Design question - Action Form vs Business Delegates/Value Objects
Date Mon, 26 Nov 2001 15:20:26 GMT
Hi Ted

yes, you are right. The adapters don't have any fields, just getters and
setters essentially telling the business objects what to do.  One thing I'm
not too pleased with is that some of the methods in my adapter end up being
more complex than I'd like. For example a method like setFeature( int
featureId ) will do a lookup to get the feature business object associated
with the featureId and then traverse the business objects starting from the
root business object and fugure out what it needs to do. But I'll live with
that for now.

To be honest regarding your question about conversions/transformations I
have not needed to do that in my application (no dates involved). I think
the adapter could be used to do the transformation but i'm not sure I'd put
it there. If I thought the conversion/transformation was specific to the
presentation layer requirements I would probably try to either (a) somehow
put the conversion/transformation in a reusable tag (probably only works in
displaying info); or (b) write dedicated and reusable helper objects, e.g.
DateTransformer, which can be parameterized (e.g. at the time of
construction), and are capable of producing a Date from a String and vice
versa, based on the date formatting parameters. Then using those helper
objects in the forms so that when setDateString(...) gets called it asks the
transformer for a Date (the form would need to expose the Date via getDate;
the adapter would then only support Date getDate() and void setDate( Date)
whereas the forms support get/setDateString(), get/setDate.  The forms could
even use these transformer helpers as private static objects to avoid
recreating a new object each time.

Does this sound reasonable ?  I am very interested in other people's ideas
and experiences.   I think Struts is a great framework and based on this
mailing list there are a lot of people using it in smart ways. I'm sure
there are a lot of best practices evolving out there which we can all learn

- Paul

----- Original Message -----
From: "Ted Husted" <>
To: "Struts Users Mailing List" <>
Sent: Friday, November 23, 2001 1:30 PM
Subject: Re: Design question - Action Form vs Business Delegates/Value

> That sounds quite clever.
> So the adapter class itself has no fields, only getters and setters?
> Do the adapters need to perform any conversions or transformations, like
> creating a date field from a String, or stripping the non-numeric
> formatting out of a telephone number?
> Paul Devine wrote:
> >
> > I have used an approach similar to that which Ted is outlining.
> > I keep my Form's UI specific, I want ro write as little code as possible
> > the "Strus specific" classes (ActionForm's and Action's).  The interface
> > a form class is naturally different to that on the business objects (in
> > system these are actually closer to the value objects that you are
> > with)    I ended up writing what "Adapter" class(es) between the form(s)
> > the business objects.  An Adapter and a Form share one or more methods
> > the same signature.   In order to populate a form for display, I
> > my "root level" business object of relevance, wrap it an adapter, and
> > call PropertyUtils.copyProperties (the exact method name escapes me for
> > now).  This automatically populates the form by calling it's "set"
> > for those methods with a matching "get" method on the adapter.      When
> > form is submitted and I need to update the state of the business
objects, I
> > do the opposite, copy from the form to the adapter.   Internally the
> > does all the detailed work of setting the information on the right
> > objects, shielding the action of form objects from the complexity of the
> > business object model.  An added bonus for us that is since our business
> > objects have quite a complex model (X has multiple Y, Y in turn has
> > Z, etc.) the adapter provides a simplified method of access into the
> > business object model.
> >
> > For example (Action class)...
> >     Employee employee = new Employee();
> >     // ... do what it takes to load the employee with data
> >     EmployeeAdapter adapter = new EmployeeAdapter( employee );
> >     PropertyUtils.copyProperties( employeeForm, adapter ) ; // can't
> > remember the order of these for now bnut the intent is from employee to
> > form
> >
> > The Adapter implementations may or may not be reusable across projects.
> > Since they are tailored to adapting the business objects to an interface
> > which is convenient for a given form (or set of forms) they may not be
> > reusable.
> >
> > Hope it is of some interest.  Your suggestions for improvement /
> > alternatives are of interest to me .
> >
> > - Paul
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message