Menu
▾
▴
RE: [Springframework-developer] BeanWrapperImpl abstraction
|
From: Keith D. <kd...@cs...> - 2004-06-13 10:56:49
|
Juergen,
Basically what I need for rich-client is the ability to update the =
target
domain object for a form model instance (a form model being, in my case, =
a
buffered model mediating commits to the domain layer in response to user
interaction in the GUI.) When the replacement occurs, perhaps because =
the
GUI is reusing a commonly used form instance across multiple =
transactions,
the form needs to be notified of the change so it can notify the =
controls.
All this may be somewhat out of scope of the PropertyAccessor interface; =
in
fact, for now I just went ahead and defined a new interface that wraps a
BeanWrapper; see "AspectAccessStrategy", "MutableAspectAccessStrategy", =
and
"BeanPropertyAspectStrategy" in org.springframework.rules.values. =
However,
there is some overlap here. Maybe we should decide of that what of this =
is
worth integrating into the core.beans framework.
BTW - I've tested the pluggable "aspect" (where aspect=3Dproperty in =
this
case) access strategy need and it works quite nicely; currently the =
system
has implementations for standard bean property access (as I mentioned =
using
BeanWrapper under the covers) as well as my "FormModel" interface for
validating buffered (but not committed) form changes. What this allows =
me
to do is pass either strategy to the rules subsystem for validation, so
rules is agnostic to where the data to be validated comes from. It =
would be
quite simple to add a Map implementation, or some other access strategy.
Keith
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Rod Johnson
Sent: Sunday, June 13, 2004 3:42 AM
To: spr...@li...
Subject: Fw: [Springframework-developer] BeanWrapperImpl abstraction
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? =
In
case of a Map-backed strategy, would simply set the Map as wrapped =
instance?
If this is what we want, I can of course move setWrappedInstance up to =
the
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 =
each
of its elements? A quite natural way to specify is the required type:
bw.registerCustomEditor(String[].class, "myArray", myEditor); // for =
the
array itself
bw.registerCustomEditor(String.class, "myArray", myEditor); // for =
each
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 =
populate
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 =
type
mismatches caused by the PropertyEditor!
So what I changed is that the required type specified on editor =
registration
is now kept and evaluated when findCustomEditor is invoked. Only if the =
type
matches, the editor will be applied. If there's no explicit type =
specified
(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 =
specified 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 =
what
we agree on, I'm gonna commit it promptly. (A trivial change, actually: =
just
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 =
the
binders to be configured with different strategies for setting / =
receiving
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
-------------------------------------------------------
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
|
