Re: [Springframework-developer] BeanWrapperImpl abstraction

[Dmitriy K. <dko...@ru...>]

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