Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-06-08 10:45:35
|
Alef, I wouldn't mind such a refactoring. However, I don't see the clear = distinction between the new base class and BeanWrapperImpl: If the base = class contains everything including bean introspection, what exactly is = BeanWrapperImpl supposed to add - respectively, what does your own = subclass do differently? I assume that your own subclass wouldn't implement the BeanWrapper = interface in the first place, because it has its own API way. I just = wonder what it looks like then :-) I doubt that there will ever be an alternative implementation of the = BeanWrapper interface itself. It still makes sense to decouple interface = and implementation here, if just for testability. BeanWrapperImpl = already is a quite complex piece that you shouldn't necessarily work = with directly. In particular, BeanWrapperImpl has some public methods that are *not* in = the BeanWrapper interface, for advanced functionality that is not = typically needed in application code. If the changes don't affect the public BeanWrapper API, I wouldn't mind = including them in 1.0.3 - provided that we're just talking about a = refactoring that does not modify existing functionality. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Rod Johnson Sent: Tuesday, June 08, 2004 10:37 AM To: spr...@li... Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction Alef >Would it be an idea to do a small refactoring of the BeanWrapper (for 1.1 or 1.2) and to create the following: AbstractBeanWrapper: - customer editors - introspection stuff - convenience methods (getPropertyNameTokens and some of the other ones) BeanWrapperImpl: - backed by an object and doing the actual setting and getting of properties >Yes yes, I know, extending the BeanWrapper is a rare use case, but by doing it I don't have to change a thing to my web layer ;-) I'm in favour of this refactoring. After all, the BeanWrapper interface = only makes sense if BeanWrapperImpl isn't the only possible impl. Rgds 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 |
|
From: Alef A. <al...@jt...> - 2004-06-08 12:16:51
|
> I wouldn't mind such a refactoring. However, I don't see the clear > distinction between the new base class and BeanWrapperImpl: If the base > class contains everything including bean introspection, what exactly is > BeanWrapperImpl supposed to add - respectively, what does your own > subclass do differently? To allow for partial results to be returned from (Hibernate) queries but still letting the clients believe it's a concrete object, my own BeanWrapper is backed by a PropertyValues object rather than the real object. A call to getWrappedInstance() returns a Proxy, proxying to BeanWrapper to retrieve the values. This allows me to without changing anything to the view (the view can still use the databinder and the actual wrapped instance as internally that uses the BeanWrapper backed by the PropertyValues) switch from full-objects to partial objects being returned to the view or fat client. Reason for all this: complex domain model with huge objects (healthcare and the like) with stringent security requirements (certain parts of objects just cannot be transferred over the wire for example). Both the security requirements are met as well as the performance troubles (heavily interlinked domain model, where clients hardly ever need to view more than 5% of all data available). The latter could probably be solved by using the open session in view stuff, but it's problematic with fat and remote clients. > I assume that your own subclass wouldn't implement the BeanWrapper > interface in the first place, because it has its own API way. I just > wonder what it looks like then :-) Yes it does implement BeanWrapper ;-). It has the exact same functionality (you cannot modify properties with it, just read them). > I doubt that there will ever be an alternative implementation of the > BeanWrapper interface itself. It still makes sense to decouple interface > and implementation here, if just for testability. BeanWrapperImpl already > is a quite complex piece that you shouldn't necessarily work with > directly. It's a rare use case, but actually makes sense (to me ;-). Same functionality, different wrapped object. > If the changes don't affect the public BeanWrapper API, I wouldn't mind > including them in 1.0.3 - provided that we're just talking about a > refactoring that does not modify existing functionality. In my use case the only thing that changes is the wrapped instance (more specifically, the data container actually holding the data of the (proxied) interface being wrapped). Basically I would stick with the current API of the BeanWrapper and implement the AbstractBeanWrapper as a somewhat strategy-like class, where the current BeanWrapperImpl just has to override get/setPropertyValue(propertyName, actualName, key) method, currently delegating to the read/writeMethods of the object being wrapped (there is where I need to make changes). alef |
|
From: <jue...@we...> - 2004-06-08 12:42:01
|
OK, I see. But I don't see a strong need to factor a base class out, = actually. Rather, I see a need to make some of the currently private = methods in BeanWrapperImpl protected, to allow for easier subclassing - = in particular: - getPropertyValue(String propertyName, String actualName, String key) - setPropertyValue(String propertyName, String actualName, String key, = Object value) Can you try to figure out the exact set of methods that you need = protected rather than private? We can then still decide to factor out a = base class; but for a start, it would be good enough to allow for = subclassing BeanWrapperImpl itself. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Alef Arendsen Sent: Tuesday, June 08, 2004 2:19 PM To: spr...@li... Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction > I wouldn't mind such a refactoring. However, I don't see the clear > distinction between the new base class and BeanWrapperImpl: If the base > class contains everything including bean introspection, what exactly is > BeanWrapperImpl supposed to add - respectively, what does your own > subclass do differently? To allow for partial results to be returned from (Hibernate) queries but still letting the clients believe it's a concrete object, my own BeanWrapper is backed by a PropertyValues object rather than the real object. A call to getWrappedInstance() returns a Proxy, proxying to BeanWrapper to retrieve the values. This allows me to without changing anything to the view (the view can still use the databinder and the actual wrapped instance as internally that uses the BeanWrapper backed by the PropertyValues) switch from full-objects to partial objects being returned to the view or fat client. Reason for all this: complex domain model with huge objects (healthcare and the like) with stringent security requirements (certain parts of objects just cannot be transferred over the wire for example). Both the security requirements are met as well as the performance troubles (heavily interlinked domain model, where clients hardly ever need to view more than 5% of all data available). The latter could probably be solved by using the open session in view stuff, but it's problematic with fat and remote clients. > I assume that your own subclass wouldn't implement the BeanWrapper > interface in the first place, because it has its own API way. I just > wonder what it looks like then :-) Yes it does implement BeanWrapper ;-). It has the exact same functionality (you cannot modify properties with it, just read them). > I doubt that there will ever be an alternative implementation of the > BeanWrapper interface itself. It still makes sense to decouple interface > and implementation here, if just for testability. BeanWrapperImpl already > is a quite complex piece that you shouldn't necessarily work with > directly. It's a rare use case, but actually makes sense (to me ;-). Same functionality, different wrapped object. > If the changes don't affect the public BeanWrapper API, I wouldn't mind > including them in 1.0.3 - provided that we're just talking about a > refactoring that does not modify existing functionality. In my use case the only thing that changes is the wrapped instance (more specifically, the data container actually holding the data of the (proxied) interface being wrapped). Basically I would stick with the current API of the BeanWrapper and implement the AbstractBeanWrapper as a somewhat strategy-like class, where the current BeanWrapperImpl just has to override get/setPropertyValue(propertyName, actualName, key) method, currently delegating to the read/writeMethods of the object being wrapped (there is where I need to make changes). alef ------------------------------------------------------- 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 |
|
From: Dmitriy K. <dko...@ru...> - 2004-06-08 13:35:05
|
I'll add my 2c. If there is a possibility for an alternative implementation of BeanWrapper indeed (which personally I can't see since BeabWrapperImpl is sophisticated and robust enough) then adding a base abstract class would be a good idea. Otherwise I'm for Juergen's suggestion to "open up" some of the needed private methods to enable easy subclassing of BeanWrapperImpl directly. Regards, Dmitriy. jürgen höller [werk3AT] wrote: > OK, I see. But I don't see a strong need to factor a base class out, actually. Rather, I see a need to make some of the currently private methods in BeanWrapperImpl protected, to allow for easier subclassing - in particular: > > - getPropertyValue(String propertyName, String actualName, String key) > - setPropertyValue(String propertyName, String actualName, String key, Object value) > > Can you try to figure out the exact set of methods that you need protected rather than private? We can then still decide to factor out a base class; but for a start, it would be good enough to allow for subclassing BeanWrapperImpl itself. > > Juergen > > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...]On Behalf > Of Alef Arendsen > Sent: Tuesday, June 08, 2004 2:19 PM > To: spr...@li... > Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction > > > >>I wouldn't mind such a refactoring. However, I don't see the clear >>distinction between the new base class and BeanWrapperImpl: If the > > base > >>class contains everything including bean introspection, what exactly > > is > >>BeanWrapperImpl supposed to add - respectively, what does your own >>subclass do differently? > > > To allow for partial results to be returned from (Hibernate) queries but > still letting the clients believe it's a concrete object, my own > BeanWrapper is backed by a PropertyValues object rather than the real > object. A call to getWrappedInstance() returns a Proxy, proxying to > BeanWrapper to retrieve the values. > > This allows me to without changing anything to the view (the view can > still use the databinder and the actual wrapped instance as internally > that uses the BeanWrapper backed by the PropertyValues) switch from > full-objects to partial objects being returned to the view or fat > client. > > Reason for all this: complex domain model with huge objects (healthcare > and the like) with stringent security requirements (certain parts of > objects just cannot be transferred over the wire for example). Both the > security requirements are met as well as the performance troubles > (heavily interlinked domain model, where clients hardly ever need to > view more than 5% of all data available). The latter could probably be > solved by using the open session in view stuff, but it's problematic > with fat and remote clients. > > >>I assume that your own subclass wouldn't implement the BeanWrapper >>interface in the first place, because it has its own API way. I just >>wonder what it looks like then :-) > > Yes it does implement BeanWrapper ;-). It has the exact same > functionality (you cannot modify properties with it, just read them). > > >>I doubt that there will ever be an alternative implementation of the >>BeanWrapper interface itself. It still makes sense to decouple > > interface > >>and implementation here, if just for testability. BeanWrapperImpl > > already > >>is a quite complex piece that you shouldn't necessarily work with >>directly. > > It's a rare use case, but actually makes sense (to me ;-). Same > functionality, different wrapped object. > > >>If the changes don't affect the public BeanWrapper API, I wouldn't > > mind > >>including them in 1.0.3 - provided that we're just talking about a >>refactoring that does not modify existing functionality. > > In my use case the only thing that changes is the wrapped instance (more > specifically, the data container actually holding the data of the > (proxied) interface being wrapped). Basically I would stick with the > current API of the BeanWrapper and implement the AbstractBeanWrapper as > a somewhat strategy-like class, where the current BeanWrapperImpl just > has to override get/setPropertyValue(propertyName, actualName, key) > method, currently delegating to the read/writeMethods of the object > being wrapped (there is where I need to make changes). > > alef > > > > ------------------------------------------------------- > 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 |
|
From: Keith D. <kd...@cs...> - 2004-06-08 14:16:51
|
Just a related suggestion:
One point that was brought up on the rich client dev list was the =
suggestion
to extract a "PropertyAccessor" interface that is independent of any =
bean
access mechanism. This could support different mechanisms for accessing
bean properties, for example, via standard java beans, via maps, or via
apache dyna beans. While BeanWrapper could serve in this regard, it =
does
have several methods that are specific to the javabeans model - =
specifically
the bean metadata interfaces (PropertyDescriptor stuff.)
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.
Keith
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Dmitriy Kopylenko
Sent: Tuesday, June 08, 2004 9:35 AM
To: spr...@li...
Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction
I'll add my 2c. If there is a possibility for an alternative =
implementation
of BeanWrapper indeed (which personally I can't see since =
BeabWrapperImpl is
sophisticated and=20
robust enough) then adding a base abstract class would be a good idea.
Otherwise I'm for Juergen's suggestion to "open up" some of the needed
private methods to enable=20
easy subclassing of BeanWrapperImpl directly.
Regards,
Dmitriy.
j=FCrgen h=F6ller [werk3AT] wrote:
> OK, I see. But I don't see a strong need to factor a base class out,
actually. Rather, I see a need to make some of the currently private =
methods
in BeanWrapperImpl protected, to allow for easier subclassing - in
particular:
>=20
> - getPropertyValue(String propertyName, String actualName, String key)
> - setPropertyValue(String propertyName, String actualName, String key,
Object value)
>=20
> Can you try to figure out the exact set of methods that you need =
protected
rather than private? We can then still decide to factor out a base =
class;
but for a start, it would be good enough to allow for subclassing
BeanWrapperImpl itself.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alef Arendsen
> Sent: Tuesday, June 08, 2004 2:19 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
>=20
>=20
>=20
>>I wouldn't mind such a refactoring. However, I don't see the clear
>>distinction between the new base class and BeanWrapperImpl: If the
>=20
> base
>=20
>>class contains everything including bean introspection, what exactly
>=20
> is
>=20
>>BeanWrapperImpl supposed to add - respectively, what does your own
>>subclass do differently?
>=20
>=20
> To allow for partial results to be returned from (Hibernate) queries =
but
> still letting the clients believe it's a concrete object, my own
> BeanWrapper is backed by a PropertyValues object rather than the real
> object. A call to getWrappedInstance() returns a Proxy, proxying to
> BeanWrapper to retrieve the values.
>=20
> This allows me to without changing anything to the view (the view can
> still use the databinder and the actual wrapped instance as internally
> that uses the BeanWrapper backed by the PropertyValues) switch from
> full-objects to partial objects being returned to the view or fat
> client.
>=20
> Reason for all this: complex domain model with huge objects =
(healthcare
> and the like) with stringent security requirements (certain parts of
> objects just cannot be transferred over the wire for example). Both =
the
> security requirements are met as well as the performance troubles
> (heavily interlinked domain model, where clients hardly ever need to
> view more than 5% of all data available). The latter could probably be
> solved by using the open session in view stuff, but it's problematic
> with fat and remote clients.
>=20
>=20
>>I assume that your own subclass wouldn't implement the BeanWrapper
>>interface in the first place, because it has its own API way. I just
>>wonder what it looks like then :-)
>=20
> Yes it does implement BeanWrapper ;-). It has the exact same
> functionality (you cannot modify properties with it, just read them).
>=20
>=20
>>I doubt that there will ever be an alternative implementation of the
>>BeanWrapper interface itself. It still makes sense to decouple
>=20
> interface
>=20
>>and implementation here, if just for testability. BeanWrapperImpl
>=20
> already
>=20
>>is a quite complex piece that you shouldn't necessarily work with
>>directly.
>=20
> It's a rare use case, but actually makes sense (to me ;-). Same
> functionality, different wrapped object.
>=20
>=20
>>If the changes don't affect the public BeanWrapper API, I wouldn't
>=20
> mind
>=20
>>including them in 1.0.3 - provided that we're just talking about a
>>refactoring that does not modify existing functionality.
>=20
> In my use case the only thing that changes is the wrapped instance =
(more
> specifically, the data container actually holding the data of the
> (proxied) interface being wrapped). Basically I would stick with the
> current API of the BeanWrapper and implement the AbstractBeanWrapper =
as
> a somewhat strategy-like class, where the current BeanWrapperImpl just
> has to override get/setPropertyValue(propertyName, actualName, key)
> method, currently delegating to the read/writeMethods of the object
> being wrapped (there is where I need to make changes).
>=20
> alef
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
> -------------------------------------------------------
> 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
|
|
From: john b. <jb...@pe...> - 2004-06-08 20:16:01
|
I agree with Keith's suggestion. We recently did some work to allow =
data
binding to occur to a dom object instead of a bean. We ran into several
places where this was made difficult because of BeabWrapperImpl.
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Keith Donald
Sent: Tuesday, June 08, 2004 7:17 AM
To: spr...@li...
Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
Just a related suggestion:
One point that was brought up on the rich client dev list was the =
suggestion
to extract a "PropertyAccessor" interface that is independent of any =
bean
access mechanism. This could support different mechanisms for accessing
bean properties, for example, via standard java beans, via maps, or via
apache dyna beans. While BeanWrapper could serve in this regard, it =
does
have several methods that are specific to the javabeans model - =
specifically
the bean metadata interfaces (PropertyDescriptor stuff.)
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.
Keith
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Dmitriy Kopylenko
Sent: Tuesday, June 08, 2004 9:35 AM
To: spr...@li...
Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction
I'll add my 2c. If there is a possibility for an alternative =
implementation
of BeanWrapper indeed (which personally I can't see since =
BeabWrapperImpl is
sophisticated and=20
robust enough) then adding a base abstract class would be a good idea.
Otherwise I'm for Juergen's suggestion to "open up" some of the needed
private methods to enable=20
easy subclassing of BeanWrapperImpl directly.
Regards,
Dmitriy.
j=FCrgen h=F6ller [werk3AT] wrote:
> OK, I see. But I don't see a strong need to factor a base class out,
actually. Rather, I see a need to make some of the currently private =
methods
in BeanWrapperImpl protected, to allow for easier subclassing - in
particular:
>=20
> - getPropertyValue(String propertyName, String actualName, String key)
> - setPropertyValue(String propertyName, String actualName, String key,
Object value)
>=20
> Can you try to figure out the exact set of methods that you need =
protected
rather than private? We can then still decide to factor out a base =
class;
but for a start, it would be good enough to allow for subclassing
BeanWrapperImpl itself.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alef Arendsen
> Sent: Tuesday, June 08, 2004 2:19 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
>=20
>=20
>=20
>>I wouldn't mind such a refactoring. However, I don't see the clear
>>distinction between the new base class and BeanWrapperImpl: If the
>=20
> base
>=20
>>class contains everything including bean introspection, what exactly
>=20
> is
>=20
>>BeanWrapperImpl supposed to add - respectively, what does your own
>>subclass do differently?
>=20
>=20
> To allow for partial results to be returned from (Hibernate) queries =
but
> still letting the clients believe it's a concrete object, my own
> BeanWrapper is backed by a PropertyValues object rather than the real
> object. A call to getWrappedInstance() returns a Proxy, proxying to
> BeanWrapper to retrieve the values.
>=20
> This allows me to without changing anything to the view (the view can
> still use the databinder and the actual wrapped instance as internally
> that uses the BeanWrapper backed by the PropertyValues) switch from
> full-objects to partial objects being returned to the view or fat
> client.
>=20
> Reason for all this: complex domain model with huge objects =
(healthcare
> and the like) with stringent security requirements (certain parts of
> objects just cannot be transferred over the wire for example). Both =
the
> security requirements are met as well as the performance troubles
> (heavily interlinked domain model, where clients hardly ever need to
> view more than 5% of all data available). The latter could probably be
> solved by using the open session in view stuff, but it's problematic
> with fat and remote clients.
>=20
>=20
>>I assume that your own subclass wouldn't implement the BeanWrapper
>>interface in the first place, because it has its own API way. I just
>>wonder what it looks like then :-)
>=20
> Yes it does implement BeanWrapper ;-). It has the exact same
> functionality (you cannot modify properties with it, just read them).
>=20
>=20
>>I doubt that there will ever be an alternative implementation of the
>>BeanWrapper interface itself. It still makes sense to decouple
>=20
> interface
>=20
>>and implementation here, if just for testability. BeanWrapperImpl
>=20
> already
>=20
>>is a quite complex piece that you shouldn't necessarily work with
>>directly.
>=20
> It's a rare use case, but actually makes sense (to me ;-). Same
> functionality, different wrapped object.
>=20
>=20
>>If the changes don't affect the public BeanWrapper API, I wouldn't
>=20
> mind
>=20
>>including them in 1.0.3 - provided that we're just talking about a
>>refactoring that does not modify existing functionality.
>=20
> In my use case the only thing that changes is the wrapped instance =
(more
> specifically, the data container actually holding the data of the
> (proxied) interface being wrapped). Basically I would stick with the
> current API of the BeanWrapper and implement the AbstractBeanWrapper =
as
> a somewhat strategy-like class, where the current BeanWrapperImpl just
> has to override get/setPropertyValue(propertyName, actualName, key)
> method, currently delegating to the read/writeMethods of the object
> being wrapped (there is where I need to make changes).
>=20
> alef
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
> -------------------------------------------------------
> 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: 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
|
|
From: Rod J. <rod...@in...> - 2004-06-09 18:29:50
|
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
|
|
From: Alef A. <al...@jt...> - 2004-06-08 13:20:05
|
Ok subclassing sounds good. I'll have a look at a list of candidates tonight, don't have much time = before then. Alef > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On = Behalf > Of j=FCrgen h=F6ller [werk3AT] > Sent: Tuesday, June 08, 2004 2:46 PM > To: spr...@li... > Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction >=20 > OK, I see. But I don't see a strong need to factor a base class out, > actually. Rather, I see a need to make some of the currently private > methods in BeanWrapperImpl protected, to allow for easier subclassing = - in > particular: >=20 > - getPropertyValue(String propertyName, String actualName, String key) > - setPropertyValue(String propertyName, String actualName, String key, > Object value) >=20 > Can you try to figure out the exact set of methods that you need = protected > rather than private? We can then still decide to factor out a base = class; > but for a start, it would be good enough to allow for subclassing > BeanWrapperImpl itself. >=20 > Juergen >=20 >=20 > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...]On = Behalf > Of Alef Arendsen > Sent: Tuesday, June 08, 2004 2:19 PM > To: spr...@li... > Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction >=20 >=20 > > I wouldn't mind such a refactoring. However, I don't see the clear > > distinction between the new base class and BeanWrapperImpl: If the > base > > class contains everything including bean introspection, what exactly > is > > BeanWrapperImpl supposed to add - respectively, what does your own > > subclass do differently? >=20 > To allow for partial results to be returned from (Hibernate) queries = but > still letting the clients believe it's a concrete object, my own > BeanWrapper is backed by a PropertyValues object rather than the real > object. A call to getWrappedInstance() returns a Proxy, proxying to > BeanWrapper to retrieve the values. >=20 > This allows me to without changing anything to the view (the view can > still use the databinder and the actual wrapped instance as internally > that uses the BeanWrapper backed by the PropertyValues) switch from > full-objects to partial objects being returned to the view or fat > client. >=20 > Reason for all this: complex domain model with huge objects = (healthcare > and the like) with stringent security requirements (certain parts of > objects just cannot be transferred over the wire for example). Both = the > security requirements are met as well as the performance troubles > (heavily interlinked domain model, where clients hardly ever need to > view more than 5% of all data available). The latter could probably be > solved by using the open session in view stuff, but it's problematic > with fat and remote clients. >=20 > > I assume that your own subclass wouldn't implement the BeanWrapper > > interface in the first place, because it has its own API way. I just > > wonder what it looks like then :-) > Yes it does implement BeanWrapper ;-). It has the exact same > functionality (you cannot modify properties with it, just read them). >=20 > > I doubt that there will ever be an alternative implementation of the > > BeanWrapper interface itself. It still makes sense to decouple > interface > > and implementation here, if just for testability. BeanWrapperImpl > already > > is a quite complex piece that you shouldn't necessarily work with > > directly. > It's a rare use case, but actually makes sense (to me ;-). Same > functionality, different wrapped object. >=20 > > If the changes don't affect the public BeanWrapper API, I wouldn't > mind > > including them in 1.0.3 - provided that we're just talking about a > > refactoring that does not modify existing functionality. > In my use case the only thing that changes is the wrapped instance = (more > specifically, the data container actually holding the data of the > (proxied) interface being wrapped). Basically I would stick with the > current API of the BeanWrapper and implement the AbstractBeanWrapper = as > a somewhat strategy-like class, where the current BeanWrapperImpl just > has to override get/setPropertyValue(propertyName, actualName, key) > method, currently delegating to the read/writeMethods of the object > being wrapped (there is where I need to make changes). >=20 > alef >=20 >=20 >=20 > ------------------------------------------------------- > 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 >=20 >=20 > ------------------------------------------------------- > 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 >=20 >=20 |
|
From: Choy R. <ch...@rc...> - 2004-06-09 05:18:30
|
I've been experimenting with BeanWrapperImpl ever since the Map setting
issue. In particular, I was trying to find ways of making implicit
concepts more explicit. I eventually came up with something similar
PropertyAccessor. I called it PropertyWrapper with a similar interface.
I've been toying with how stateless it should be.
Here are some of the concepts that I came up with:
PropertyPath - represents a property path like "child[3].name". knows if
it isNested.
PropertyPathPart - represents one part of a property path. E.g.
"child[3]". Can tokenize itself.
PropertyWrapper - encapsulation of how to access a Bean Wrapper
property. Perhaps include other metadata properties. Implementations
include ArrayPropertyWrapper and DefaultPropertyWrapper.
I heard we might go to an OGNL implementation anyways so it might not be
worth the effort.
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Keith Donald
> Sent: Tuesday, June 08, 2004 10:17 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
>=20
> Just a related suggestion:
>=20
> One point that was brought up on the rich client dev list was the
> suggestion
> to extract a "PropertyAccessor" interface that is independent of any
bean
> access mechanism. This could support different mechanisms for
accessing
> bean properties, for example, via standard java beans, via maps, or
via
> apache dyna beans. While BeanWrapper could serve in this regard, it
does
> have several methods that are specific to the javabeans model -
> specifically
> the bean metadata interfaces (PropertyDescriptor stuff.)
>=20
> Something like:
>=20
> public interface PropertyAccessor {
> public Object getPropertyValue(String propertyName);
> public void setPropertyValue(String propertyName, Object value);
> // get/set multiple
> }
>=20
> 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.
>=20
> Keith
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of
> Dmitriy Kopylenko
> Sent: Tuesday, June 08, 2004 9:35 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction
>=20
> I'll add my 2c. If there is a possibility for an alternative
> implementation
> of BeanWrapper indeed (which personally I can't see since
BeabWrapperImpl
> is
> sophisticated and
> robust enough) then adding a base abstract class would be a good idea.
> Otherwise I'm for Juergen's suggestion to "open up" some of the needed
> private methods to enable
> easy subclassing of BeanWrapperImpl directly.
>=20
> Regards,
> Dmitriy.
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> > OK, I see. But I don't see a strong need to factor a base class out,
> actually. Rather, I see a need to make some of the currently private
> methods
> in BeanWrapperImpl protected, to allow for easier subclassing - in
> particular:
> >
> > - getPropertyValue(String propertyName, String actualName, String
key)
> > - setPropertyValue(String propertyName, String actualName, String
key,
> Object value)
> >
> > Can you try to figure out the exact set of methods that you need
> protected
> rather than private? We can then still decide to factor out a base
class;
> but for a start, it would be good enough to allow for subclassing
> BeanWrapperImpl itself.
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On
Behalf
> > Of Alef Arendsen
> > Sent: Tuesday, June 08, 2004 2:19 PM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
> >
> >
> >
> >>I wouldn't mind such a refactoring. However, I don't see the clear
> >>distinction between the new base class and BeanWrapperImpl: If the
> >
> > base
> >
> >>class contains everything including bean introspection, what exactly
> >
> > is
> >
> >>BeanWrapperImpl supposed to add - respectively, what does your own
> >>subclass do differently?
> >
> >
> > To allow for partial results to be returned from (Hibernate) queries
but
> > still letting the clients believe it's a concrete object, my own
> > BeanWrapper is backed by a PropertyValues object rather than the
real
> > object. A call to getWrappedInstance() returns a Proxy, proxying to
> > BeanWrapper to retrieve the values.
> >
> > This allows me to without changing anything to the view (the view
can
> > still use the databinder and the actual wrapped instance as
internally
> > that uses the BeanWrapper backed by the PropertyValues) switch from
> > full-objects to partial objects being returned to the view or fat
> > client.
> >
> > Reason for all this: complex domain model with huge objects
(healthcare
> > and the like) with stringent security requirements (certain parts of
> > objects just cannot be transferred over the wire for example). Both
the
> > security requirements are met as well as the performance troubles
> > (heavily interlinked domain model, where clients hardly ever need to
> > view more than 5% of all data available). The latter could probably
be
> > solved by using the open session in view stuff, but it's problematic
> > with fat and remote clients.
> >
> >
> >>I assume that your own subclass wouldn't implement the BeanWrapper
> >>interface in the first place, because it has its own API way. I just
> >>wonder what it looks like then :-)
> >
> > Yes it does implement BeanWrapper ;-). It has the exact same
> > functionality (you cannot modify properties with it, just read
them).
> >
> >
> >>I doubt that there will ever be an alternative implementation of the
> >>BeanWrapper interface itself. It still makes sense to decouple
> >
> > interface
> >
> >>and implementation here, if just for testability. BeanWrapperImpl
> >
> > already
> >
> >>is a quite complex piece that you shouldn't necessarily work with
> >>directly.
> >
> > It's a rare use case, but actually makes sense (to me ;-). Same
> > functionality, different wrapped object.
> >
> >
> >>If the changes don't affect the public BeanWrapper API, I wouldn't
> >
> > mind
> >
> >>including them in 1.0.3 - provided that we're just talking about a
> >>refactoring that does not modify existing functionality.
> >
> > In my use case the only thing that changes is the wrapped instance
(more
> > specifically, the data container actually holding the data of the
> > (proxied) interface being wrapped). Basically I would stick with the
> > current API of the BeanWrapper and implement the AbstractBeanWrapper
as
> > a somewhat strategy-like class, where the current BeanWrapperImpl
just
> > has to override get/setPropertyValue(propertyName, actualName, key)
> > method, currently delegating to the read/writeMethods of the object
> > being wrapped (there is where I need to make changes).
> >
> > alef
> >
> >
> >
> > -------------------------------------------------------
> > 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
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
|
|
From: <jue...@we...> - 2004-06-09 06:25:23
|
We can certainly introduce such an interface - as base interface of =
BeanWrapper - already for 1.0.3.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Keith Donald
Gesendet: Di 08.06.2004 16:16
An: spr...@li...
Betreff: RE: [Springframework-developer] BeanWrapperImpl abstraction
Just a related suggestion:
One point that was brought up on the rich client dev list was the =
suggestion
to extract a "PropertyAccessor" interface that is independent of any =
bean
access mechanism. This could support different mechanisms for accessing
bean properties, for example, via standard java beans, via maps, or via
apache dyna beans. While BeanWrapper could serve in this regard, it =
does
have several methods that are specific to the javabeans model - =
specifically
the bean metadata interfaces (PropertyDescriptor stuff.)
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.
Keith
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Dmitriy Kopylenko
Sent: Tuesday, June 08, 2004 9:35 AM
To: spr...@li...
Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction
I'll add my 2c. If there is a possibility for an alternative =
implementation
of BeanWrapper indeed (which personally I can't see since =
BeabWrapperImpl is
sophisticated and
robust enough) then adding a base abstract class would be a good idea.
Otherwise I'm for Juergen's suggestion to "open up" some of the needed
private methods to enable
easy subclassing of BeanWrapperImpl directly.
Regards,
Dmitriy.
j=FCrgen h=F6ller [werk3AT] wrote:
> OK, I see. But I don't see a strong need to factor a base class out,
actually. Rather, I see a need to make some of the currently private =
methods
in BeanWrapperImpl protected, to allow for easier subclassing - in
particular:
>
> - getPropertyValue(String propertyName, String actualName, String key)
> - setPropertyValue(String propertyName, String actualName, String key,
Object value)
>
> Can you try to figure out the exact set of methods that you need =
protected
rather than private? We can then still decide to factor out a base =
class;
but for a start, it would be good enough to allow for subclassing
BeanWrapperImpl itself.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alef Arendsen
> Sent: Tuesday, June 08, 2004 2:19 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
>
>
>
>>I wouldn't mind such a refactoring. However, I don't see the clear
>>distinction between the new base class and BeanWrapperImpl: If the
>
> base
>
>>class contains everything including bean introspection, what exactly
>
> is
>
>>BeanWrapperImpl supposed to add - respectively, what does your own
>>subclass do differently?
>
>
> To allow for partial results to be returned from (Hibernate) queries =
but
> still letting the clients believe it's a concrete object, my own
> BeanWrapper is backed by a PropertyValues object rather than the real
> object. A call to getWrappedInstance() returns a Proxy, proxying to
> BeanWrapper to retrieve the values.
>
> This allows me to without changing anything to the view (the view can
> still use the databinder and the actual wrapped instance as internally
> that uses the BeanWrapper backed by the PropertyValues) switch from
> full-objects to partial objects being returned to the view or fat
> client.
>
> Reason for all this: complex domain model with huge objects =
(healthcare
> and the like) with stringent security requirements (certain parts of
> objects just cannot be transferred over the wire for example). Both =
the
> security requirements are met as well as the performance troubles
> (heavily interlinked domain model, where clients hardly ever need to
> view more than 5% of all data available). The latter could probably be
> solved by using the open session in view stuff, but it's problematic
> with fat and remote clients.
>
>
>>I assume that your own subclass wouldn't implement the BeanWrapper
>>interface in the first place, because it has its own API way. I just
>>wonder what it looks like then :-)
>
> Yes it does implement BeanWrapper ;-). It has the exact same
> functionality (you cannot modify properties with it, just read them).
>
>
>>I doubt that there will ever be an alternative implementation of the
>>BeanWrapper interface itself. It still makes sense to decouple
>
> interface
>
>>and implementation here, if just for testability. BeanWrapperImpl
>
> already
>
>>is a quite complex piece that you shouldn't necessarily work with
>>directly.
>
> It's a rare use case, but actually makes sense (to me ;-). Same
> functionality, different wrapped object.
>
>
>>If the changes don't affect the public BeanWrapper API, I wouldn't
>
> mind
>
>>including them in 1.0.3 - provided that we're just talking about a
>>refactoring that does not modify existing functionality.
>
> In my use case the only thing that changes is the wrapped instance =
(more
> specifically, the data container actually holding the data of the
> (proxied) interface being wrapped). Basically I would stick with the
> current API of the BeanWrapper and implement the AbstractBeanWrapper =
as
> a somewhat strategy-like class, where the current BeanWrapperImpl just
> has to override get/setPropertyValue(propertyName, actualName, key)
> method, currently delegating to the read/writeMethods of the object
> being wrapped (there is where I need to make changes).
>
> alef
>
>
>
> -------------------------------------------------------
> 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: 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
|
|
From: <jue...@we...> - 2004-06-09 21:53:23
|
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.)
=20
Juergen
=20
________________________________
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
|
|
From: Keith D. <kd...@cs...> - 2004-06-12 07:15:45
|
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.)
=20
Juergen
=20
________________________________
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
|
|
From: Alef A. <al...@jt...> - 2004-06-10 14:11:06
Attachments:
beanwrapper.patch
|
Juergen,
The changes to the BeanWrapper are fine with me.
Furthermore, to allow for a different data structure backing an extended =
BeanWrapper, I had to do the following (patch included as an =
attachment).
- *protected* BeanWrapperImpl getBeanWrapperForPropertyPath(String =
propertyPath)
- *protected* List getBeanWrappersForPropertyPath(String propertyPath)
- introduced new method (protected setIntrospectionClass) called from =
setWrappedInstance in BeanWrapperImpl. In my extended bean wrapper I =
don't have a concrete wrapped instance, so object.getClass() does not =
work. The setIntrospectionClass method creates the introspectionResults =
instead of the setWrappedInstance method
- in toString() changed getWrappedObjectInstance().getClass().getName() =
to getWrappedClass().getName() (again because there is no concrete =
wrapped object)
So it's actually not all that much. Could you have a look at this?
Thanx,
Alef
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of j=FCrgen h=F6ller [werk3AT]
> Sent: Thursday, June 10, 2004 12:15 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction
>=20
> 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.)
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> Rod Johnson
> Gesendet: Mi 09.06.2004 20:29
> An: spr...@li...
> Betreff: Re: [Springframework-developer] BeanWrapperImpl abstraction
>=20
>=20
>=20
> Something like:
>=20
> public interface PropertyAccessor {
> public Object getPropertyValue(String propertyName);
> public void setPropertyValue(String propertyName, Object value);
> // get/set multiple
> }
>=20
> >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.
>=20
> +1
>=20
> Rod
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
|
|
From: <jue...@we...> - 2004-06-14 12:15:34
|
This is a post-1.0.2 bug that I've accidentally introduced last week. =
I've just fixed it. Thanks for spotting this!
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Tom Turelinckx
Sent: Monday, June 14, 2004 12:33 PM
To: spr...@li...
Subject: Re: Fw: [Springframework-developer] BeanWrapperImpl abstraction
Juergen,
> 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.
When you register a custom editor "for a certain type", do you register
it for the type of the property or the actual type of the value?
For example, I'm not sure this is desired behavior:
private void test() {
long now =3D 1087206665855L;
System.out.println(getValue(new Date(now), null));
// prints "14/06/2004"
System.out.println(getValue(new Timestamp(now), null));
// prints "2004-06-14 11:51:05.855"
// shouldn't this be "14/06/2004" as well?
System.out.println(getValue(new Timestamp(now), "date"));
// prints "14/06/2004"
}
private Object getValue(Date date, String property) {
DateBean dateBean =3D new DateBean();
dateBean.setDate(date);
DataBinder binder =3D new DataBinder(dateBean, "dateBean");
binder.registerCustomEditor(Date.class, property,
new CustomDateEditor(new SimpleDateFormat("dd/MM/yyyy"),
true));
return binder.getErrors().getFieldValue("date");
}
public class DateBean {
private Date date;
public Date getDate() {
return date;
}
public void setDate(Date date) {
this.date =3D date;
}
}
Suppose I have a form in a web application to edit an object, with a
Controller extending from AbstractFormController. The form backing
object has java.util.Date properties, so I register a custom editor for
all Date properties (property =3D null) in initBinder, like above.
When the form backing object is the result of a database query, its
java.util.Date properties actually contain java.sql.Timestamp objects,
which are then incorrectly displayed in the form, because the property
editor is not used, unless I register a custom editor for every
individual property...
Of course, I don't want to _know_ that the Date properties are actually
Timestamps, so I don't want to register a custom editor for all
Timestamp properties...
Is this the intended behavior or a bug?
Kind regards,
Tom.
-------------------------------------------------------
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
|
|
From: Tom T. <tom...@pr...> - 2004-06-15 06:46:47
|
Works fine now, thanks Juergen! > This is a post-1.0.2 bug that I've accidentally introduced last week. > I've just fixed it. Thanks for spotting this! > > Juergen |
