Re: [Springframework-rcp-dev] Class based FormModel

[Jan H. <jh...@sc...>]

> > 
> > - the current implementation (BeanPropertyAccessStrategy - BPAS) is
> > using the BeanWrapperImpl behind the scenes. This implies that if
> > there's a property method with the incorrect visibility, it will be
> > 'fixed' to provide access. Do we need the same functionality here? I
> > personally don't think so.
> 
> no, although if you look at hibernate (which is bean-2-database mapping, 
> instead of bean-2-form mapping) it does support it. But when in doubt - 
> leave it out, we can always put it back in.

Yep, I agree.

> > 
> > - the BPAS is based on beans and thus can inspect collections/maps etc.
> > The CPAS cannot look into these and currently doesn't support them. Any
> > comments on this? Should we provide this and how? Geoffrey already gave
> > a remark about this: we could use annotations to provide information
> > about the element type and then go on. WDYT?
> 
> I think we can do more then we think:
> For example if you give hibernate:
> 
>    class Boss {
>      public List<Person> getMyList
>    }
> 
> hibernate knows that it's a list of Person (not just Object), at runtime.
> 
> Erasure doesn't erase that knowledge on the Boss class methods.
> (It does erase that knowlegde on list instances).
> So it must be available with the Reflection API.

You do implicitly refer to switch to java 1.5 when talking about
generics?  Not sure we can do this, though it's nice to know that it is
possible. 

> 
> Nevertheless I believe in time we could use annotations on the beans to 
> fine tune bindings. But of course they should also be extactly alike 
> creatable with an xml, much like orm.xml is to define JPA/hibernate 
> annotations on non-annotated classes.

Indeed, some form of annotation could provide a nice way out.

> 
> > 
> > - I provided both options BPAS and CPAS in order not to break anything.
> > This leads to changes in
> > FormModelHelper/AbstractFormModel/DefaultFormModel.  Should we continue
> > with both of them or evaluate both and remove one from the mentioned
> > classes? The 'removed' can always be used when with the specific
> > constructor on DefaultFormModel which takes a
> > MutablePropertyAccessStrategy.
> 
> How about we remove BPAS directly after the release of 0.3.0?
> 
> This of course depends how big the big pain is to switch.
> It could be close to zero if we can make a CPAS intead of BPAS based on 
> instance.getClass() etc in depricated methods.

Not a bad idea. We'll make a release before I put in the CPAS.

> Personally, I believe the whole idea of determining read-only access 
> based on existence getters/setters is flaky at best.
> If something needs to be read-only, use 
> getFieldMetaData(...).setReadOnly(true).
> Same goes for setEnabled(false).

The read-only access you mention should be at hand, no doubt about that.
Actually it's the other way around. Making something read-only is
limiting, while I'm referring to expanding to writable. The reason is
that you typically have a super interface/class which you would like to
use to create the form. This can be used throughout the whole process,
except for creating new objects which needs write access to (almost) all
fields. So you got a complete CPAS based on PropertyDescriptors of a
certain class/interface X and then you want the added write-access of
interface/class Y implements/extends X. Your setter isn't defined on X
so no propertyDescriptor exists. And you cannot go the other way around:
creating the CPAS with Y and then using it for objects that conform to X
won't work and will throw an exception.

Or do I not see where your aiming at? Then enlighten me ;-)


Kind Regards,
Jan


 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm