Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Thu, 27 Dec 2001 12:10:32 -0800 (PST)
From: "Craig R. McClanahan" <craigmcc@apache.org>
Sender: craigmcc@localhost
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: RE: [Design Discussion] DynaBeans - Round 2
In-Reply-To: 
 <F471DF278BF9D4119F5700508BB3647A01AF69D1@beannts01.bean.capco.com>
Message-ID: <20011227115333.Y41459-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

See interspersed.

On Thu, 27 Dec 2001, Rey Francois wrote:

> Date: Thu, 27 Dec 2001 16:45:24 +0100
> From: Rey Francois <Francois.Rey@capco.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] DynaBeans - Round 2
>
> First about the DynaBean concept, I fully support it. Many times I found
> myself thinking of such generic and dynamic data containers and how they
> could ease various aspects of development, notably in Struts.
>

Obviously one ofmy motivations as well ... :-)

> Now the reason for this email is because I had a quick glance at the code
> that Craig committed earlier, particularly the Converter interface:
>     public Object convert(Class type, Object value);
>
> I had to crate a similar interface in a data mapper framework I developed,
> however in the signature of the conversion method I included an additional
> parameter for the Locale. Without it, support for internationalized
> conversions is difficult. Perhaps this could be added in a new method of the
> Converter interface, or perhaps it can be included in another interface
> extending the Converter, e.g. LocalizedConverter extends Converter.
>

I think it makes sense to have an additional convert() method with the
Locale as an extra argument.  It also seems reasonable to add it to the
same Converter interface -- a Converter implementation that didn't care
about localization could just punt and call the two-argument version,
while everyone building Converters would be reminded that they really
should think about this.

> What do you think?
>
> Actually the more I think about this, the more I'm wondering if it makes
> sense to include a conversion feature into DynaBeans. My gut feeling would
> be to restrict DynaBeans to be only dynamic data containers, and handle
> conversions separately. First not all situations require the use of
> conversions. Secondly if conversions need to be done, I'd probably handle it
> separately from the original bean. Most of the time conversions are
> necessary because of a specific usage situation requiring a different and
> specific format, and you cannot or do not want to change the original format
> to accommodate this new usage situation (either because you do not own the
> original format specification, or because you don't want to make it specific
> and prefer to keep it generic and reusable).
>

One way to incorporate conversion into DynaBeans directly would be to add
additional set() method signatures that take a Converter along with.
However, I'm inclined *not* to do this at the moment:

* You can always do your conversion separately ahead of time
  (looking up the property data type using getPropertyDescriptor()
  as necessary).

* You *must* do the conversions ahead of time if you're dealing with
  "real" JavaBeans instead -- in the way that PropertyUtils does
  underneath the covers, so this would maintain consistency.

That being said, we could leave conversions to the user in the case of
standard DynaBeans (and access them via PropertyUtils), but implement
conversion capabilities in things like BeanUtils.copyProperties() that
does the right thing for DynaBeans just like it would for standard beans.

> Supposing we have an EJB backend that provides a value object. Should the
> value object be coded to support String conversions for GUI display? You can
> do this, but that means all your client have to follow the same formatting
> conventions. To avoid this you either convert on-the-fly (e.g. using some
> kind of wrapper), or you create another data container that stores the
> converted values. Either way the conversion are handled outside the original
> bean itself. In the case of Struts we use a separate data container (there
> are good reasons for this), ActionForms, and conversions are either custom
> coded or handled by the ConvertUtils class.
>

I would use two different DynaBeans for the value objects and the GUI
display (in Struts, a DynaActionForm), for the same reason that you do
today in standard JavaBeans.  The DynaVO would have the native data types
of the EJB layer (why should it care about presentation-layer questions?),
while the DynaActionForm would do the necessary conversions (typically to
String).  Interestingly, it's usually only in the latter case where you
need the locale-specific conversions, also.

> If we had to use DynaBeans in Struts for implementing ActionForms, we could
> make a case for making these "DynActionForms" able to perform some
> conversions.

Having a DynaActionForm is definitely in my plans.  Of course, it will
live inside of Struts rather than here.

> We could implement transparently the use of converters in the
> set() method like Paulo Gaspar suggests in order to populate a DynActionForm
> from a value object (or business object). However we would probably need to
> do the reverse conversion in the get() method so that we can populate a
> value object with a DynActionForm.

Yep ... conversions both ways are required.  My bet at this point is that
it will be easier to design this kind of thing as two separate converters,
but we'll see.

> This would require some ways of passing
> the target type to the get() method so it can select the appropriate
> converter.

As above, I would not suggest embedding the conversion into the DynaBean
directly -- that's something you can either do externally on a property by
property basis, or generically by extending BeanUtils.copyProperties()
with a Converter argument.

Regular JavaBeans don't have built-in converters.  Therefore, I don't
think DynaBeans should either.

> Such design would also mean that we must easily differentiate
> between the various input/output types: it should be possible for a JSP page
> to ensure it gets an appropriate display value as a String, while on the
> other side it should be possible to get an appropriate "business" value.
> Using the same getter method for these two scenario seems to introduce some
> complications. What if the business value is already a String, which has to
> be properly converted to another String for display (e.g. O<->Open)? In such
> case you cannot really use the Class as a discriminant between the different
> types, since both are Strings. Should we use two get methods instead? Seems
> like an overkill... Also doing such conversion in an ActionForm is in some
> cases introducing some overlap with validation. Sometimes being able to
> successfully convert a display String to a business value is enough to
> validate it, at least partially: a String successfully parsed by
> SimpleDateFormat is a valid date, no need to validate each character, and on
> the resulting Date object further validation can be performed (is it a
> future date, etc.). Finally add the internationalization issue I started
> with...
>
> Ok, I will conclude here because my written thinking is getting too long ;)
>
> My conclusion would be to leave aside the conversion feature and focus only
> on the data container aspect.
>
> Fr.
>

Craig


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