Re: [Springframework-developer] BeanWrapperImpl abstraction

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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