commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <>
Subject RE: [Design Discussion] DynaBeans - Round 2
Date Fri, 28 Dec 2001 01:52:06 GMT
Answer inline

> -----Original Message-----
> From: []On Behalf Of
> Craig R. McClanahan
> On Thu, 27 Dec 2001, Paulo Gaspar wrote:
> > > From: Rey Francois []
> ...
> I'm planning on ripping the getConverter() back out of DynaClass -- it's
> too restrictive.


> Paulo, did you ever run into a scenario where you had to be accessing the
> same Record with different Converters at the same time ... perhaps even on
> separate threads?  This would cause some grief with the idea of assigning
> a Converter to a DynaBean instance.

Nops, but I already thought about that possibility.

It is quite interesting since multi-threaded access demands synchronized
access and each thread's code could be using a different Locale. My default
implementation is not synchronized.

Keep in mind however that I do not declare the Converter in my DynaBean
interface, just in the common abstract class I use for my different

On the multi-threading issue, I do not see any common use situation where I
would want to synchronize on the property level. I would usually want to
synchronize before accessing the property. (To use a DynaBean as a Map, I
would use a Map.)

On the Locale issue, keep in mind that my common implementation is made for
the most common use model, which is not this one. But since I already have
such a nice and cozy infrastructure to deal with DynaBeans, I would try to
keep using it as it is by:
  - Placing the data in a "normal" DynaBean with a NoOp Converter, for
    which the convert() method always returns the value passed as
  - Accessing the data by using a ProxyDynaBean wrapper per Locale, all of
    them wrapping the data DynaBean and each of them using a Converter
    specific for their Locale.

> > This situations also made me implement my converters in a
> hierarchical way,
> > meaning that converter may just add or override a few
> conversion rules to a
> > "parent" converter. Some of those conversion rules may add context
> > information like "Locale" or "Base directory".
> >
> That makes a lot of sense.

I am willing to contribute.

> > > 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.
> >
> > You only need to place that kind of thing in the implementation. The
> > interface can stay as it is.
> That's certainly obvious in retrospect :-).

Like using a PropertyDescriptor (which I did not!).

> I like Converter-per-Locale (or for whatever extra context information it
> needs).  I'm still thinking about explicitly tying converters to DynaBean
> instances ...
> Paulo, do you normally design your Converters to go both directions (i.e.
> so you can use them in the getters *and* the setters), or just one way?
> In the latter case, you'd probably need two.

Just on the setters and then I wrap the destination when the destination
also as a type per property/column/field/parameter.

Of course that if you want to convert al propertied to text it is easier
to do it by using a Converter outside the bean.

> > Notice that my DynaBean (actually called IRecord) interface
> does not know
> > anything about converters - only my most used implementation does so.
> >
> Ah ... so you really could use two one-way Converters if you wanted to ...
> but the key is that support for conversion is a feature of a particular
> DynaBean implementation class -- not of the top-level interface.

Yes, I am still shy of putting it in the interface, although I am not yet
sure whether I should or should not.

But Converter support is implemented for ALL my DynaBeans at their common
abstract superclass and I love it this way. So, I should not say "most
used implementation" - I should say "my only implementation. Sorry!

Anyway, two one-way converters for the same DynaBean only make sense to
me trough at different moments (sections of code) or trough proxies as
described above.

> > ...
> >
> > > First not all situations require the use of conversions.
> >
> > The above NoOpConverter solves that. And notice that I am
> talking about an
> > implementation - I agree that the converter should be kept away from the
> > interface.
> >
> You could of course also implement a DynaBean base class that doesn't
> support the conversion functionality at all for cases where it's not
> needed.

Yes. I choused doing it this way while trying to avoid an explosion of
DynaBean classes.

If I consider all possible aspects and possibilities of using a DynaBean
and try to cover them and their possible combinations with specialized
classes I will go nuts.

So, I try following the most common use pattern and the fact is that I
need some kind of data conversion almost every time I use a DynaBean.
(Actually, I do not remember any exception.)

I am only now getting on the validation issues and these are much less

> > ...
> >
> > > Seems like an overkill... Also doing such conversion in an
> ActionForm is
> > > in some cases introducing some overlap with validation.
> >
> > It is complementary to Validation. For an input value to be
> valid it must
> > be possible to convert it to the destination type.
> >
> In my Struts-based designs, I tend to check for convertability in my
> ActionForm validate() methods -- conversion success is necessary but not
> sufficient for validity, so you're checking for other stuff there anyway.

Yes of course. That is what I mean with complementary.

In the cases I need validation I am first converting the values - just by
using a DynaBean with an appropriated Converter and its set() method - and
then performing further validation over the converted values.

In my HTML form processing stuff I grab per property exceptions for both
steps (assignement/conversion and validation), ignoring validation
exceptions for properties that were not converted.

Of course there are often bean-level or form-level validation rules too.
I am talking here about per-property validation rules. I am trying to
signal all the fields with input errors in HTML forms, hence my focus on
this issue.

> > ...
> Craig

Have fun,
Paulo Gaspar

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

View raw message