RE: [Springframework-developer] BeanWrapperImpl abstraction

[Alef A. <al...@jt...>]

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