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

[Geoffrey De S. <ge0...@gm...>]

With kind regards,
Geoffrey De Smet

Jan Hoskens schreef:
> Hi all,
> 
> I'm currently looking at a way to provide class based formModels. Well
> actually it boils down to a different implementation of
> MutablePropertyAccessStrategy called ClassPropertyAccessStrategy (CPAS).
> It all kinda starts to work, but there are a few things that bother me:
> 
> - 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.

> 
> - 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.

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.

> 
> - 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.

> 
> - I want to provide some feature to allow write access when
> possible/needed. I'll explain with an example:
> 
> interface Person{
> 	String getName();
> }
> 
> class Admin implements Person {
> 	String getName()...
> }
> 
> class BadPerson implements Person{
> 	String getName()...
> 	void setName(String)...
> }
> 
> Now creating a formModel based on Person will only provide you with read
> access. Which can be ok for most cases. But when I want write access for
> BadPerson, I don't want to create a separate formModel. So I want some
> flexibility to state that, when possible, the property name may be
> writeable. It would be nice to be able to define a number of properties
> that may be writable if the current backing bean allows it. So the class
> provided to create the formModel will define the properties and their
> getters as a minimum together with the setters of those that are always
> writable. If specified, a bean that provides a setter for one of these
> properties might enable write access.

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).

> 
> I think I can do this by providing some backingBean specific logic in
> the CPAS. But I would like to hear your comments on this first.
> 
> 
> Kind Regards,
> Jan
> 
> 
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/