RE: [Springframework-developer] BeanWrapperImpl abstraction

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

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