Fw: [Springframework-developer] BeanWrapperImpl abstraction

[Rod J. <rod...@in...>]

Von: j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 12.06.2004 11:10
An: spr...@li...
Betreff: Re: [Springframework-developer] BeanWrapperImpl abstraction


Are you sure that you this is usefuly for any property access strategy? I=
n
case of a Map-backed strategy, would simply set the Map as wrapped instan=
ce?
If this is what we want, I can of course move setWrappedInstance up to th=
e
PropertyAccessor interface.

-----

BTW, I've committed quite important refinements of BeanWrapperImpl
yesterday - that took me about 6 hours to get right. The problem was: Is =
a
PropertyEditor meant to be applied to an array/Collection itself or to ea=
ch
of its elements? A quite natural way to specify is the required type:

  bw.registerCustomEditor(String[].class, "myArray", myEditor);  // for t=
he
array itself
  bw.registerCustomEditor(String.class, "myArray", myEditor);  // for eac=
h
element in the array

Unfortunately, that hasn't been checked before. No matter for what type, =
the
PropertyEditor was always applied in both cases: for the array itself and
for each element. That typically didn't show, as you usually either popul=
ate
individual array elements *or* the array as a whole. But if you used the
same BeanWrapper for both kinds of property population, you would get typ=
e
mismatches caused by the PropertyEditor!

So what I changed is that the required type specified on editor registrat=
ion
is now kept and evaluated when findCustomEditor is invoked. Only if the t=
ype
matches, the editor will be applied. If there's no explicit type specifie=
d
(which is still possible), the editor will always apply - this is not
advisable for arrays or Collections, though.

All things considered, this is how it should have been in the first place=
:
The type as passed in on editor registration needs to be checked against =
the
actual required type, to avoid potential type mismatches in case of an
array/Collection.

The change should be completely backward-compatible. Only if you specifie=
d a
wrong type on registration (i.e. not the target type that the editor will
actually create), the stricter check will now show. As passing in such a
wrong type is a misuse of the API, this is even desirable, I guess.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Keith Donald
Gesendet: Sa 12.06.2004 09:15
An: spr...@li...
Betreff: RE: [Springframework-developer] BeanWrapperImpl abstraction



Juergen,

Could you include setWrappedInstance(Object bean) in the PropertyAccessor
interface as well?  I think it fits; it makes sense to me to be able to
change out the wrapped object for all property access strategies.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Wednesday, June 09, 2004 5:51 PM
To: spr...@li...
Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction

I've just factored out all getPropertyValue and
setPropertyValue/setPropertyValues methods from BeanWrapper into a new
org.springframework.beans.PropertyAccessor base interface. If this is wha=
t
we agree on, I'm gonna commit it promptly. (A trivial change, actually: j=
ust
affects the BeanWrapper interface itself.)

Juergen


________________________________

Von: spr...@li... im Auftrag von
Rod Johnson
Gesendet: Mi 09.06.2004 20:29
An: spr...@li...
Betreff: Re: [Springframework-developer] BeanWrapperImpl abstraction



Something like:

public interface PropertyAccessor {
public Object getPropertyValue(String propertyName);
public void setPropertyValue(String propertyName, Object value);
// get/set multiple
}

>This would be useful for use within our bean binder framework to allow t=
he
binders to be configured with different strategies for setting / receivin=
g
properties.

+1

Rod



-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer