Answer inline
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Craig R. McClanahan
>
>
> On Thu, 27 Dec 2001, Paulo Gaspar wrote:
>
> > > From: Rey Francois [mailto:[EMAIL PROTECTED]]
>
> ...
>
> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
