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>
Reply-To: <paulo.gaspar@krankikom.de>
From: "Paulo Gaspar" <paulo.gaspar@krankikom.de>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: RE: [Design Discussion] DynaBeans - Round 2
Date: Fri, 28 Dec 2001 02:52:06 +0100
Message-ID: <NEBBJJIICDPIINBNIJHJGEBOMMAA.paulo.gaspar@krankikom.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20011227125855.N63322-100000@localhost>
Importance: Normal

Answer inline

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

Cool!


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

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
    parameter;
  - 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.
=:o)


> > > 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!).
=;o)


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


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

http://www.krankikom.de
http://www.ruhronline.de


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