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

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

> How hard would it be to adapt ClassPropertyAccessStrategy to non-class 
> based backing objects, such as Data Objects, Maps, or DOMs?  We actually 
> use some of these already with Spring Rich (by using our own custom 
> MutablePropertyAccessStrategy) - it would be nice to reuse some of 
> ClassPropertyAccessStrategy if possible.

I haven't thought of this yet, but this is a good moment to start. Is it
possible to send some examples of your implementation? Maybe you already
got some tests as well?

> > - 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.
> >   
> I agree (for now).

So at the moment we all do :-)

> > - 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?
> >   
> As Geoffrey has already mentioned, generic types are available at the 
> Class level, just not the Collection instance level.  This means one can 
> inspect the generic type signature of the Class to determine the 
> Collection element type.  Even so, this should still be configurable, 
> not just with annotations, but also at runtime (maybe some sort of 
> binding context key to override the collection type).  This is useful 
> when a broad collection is defined (List<MyBaseObject>), but at runtime 
> we know it will contain only MySpecificBaseObject.

Same remark as with Geoffrey: we're targeting 1.4 now. Should we move to
1.5 to use generics? 

> > - 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.
> >   
> As it is, if CPAS directly uses Java reflection, then we will be forced 
> to use our own MutablePropertyAccessStrategy, since some of our forms 
> use non-JavaBean backing objects.  However, if CPAS is designed to use 
> an abstracted interface for introspection, one that could easily be 
> swapped out for some other type of backing object (such as a 
> DataObject), then CPAS could do the job all by itself (we could reuse 
> everything CPAS has to offer and only have to implement the 
> introspection interface for our custom backing objects).

At the moment it's pretty fixed to classes, but as said before it is the
moment to put in the extra bit of work to have some more flexibility.
I'll definitely polish things up before pushing it into RCP.

(other comment waaay below)

> We just did something very similar to this.  In our case, we bound to a 
> property, something like this:
> "agency.address.name"
> However, the "agency" happens to be null when the form is first 
> displayed and isn't filled in until the user selects an agency from a 
> combo box.  The requirement was that all components bound to the agency 
> will be disabled until the agency becomes non-null.  Since we are using 
> our own custom MutablePropertyAccessStrategy (MPAS), we decided the 
> easiest path would be if a ValueModel could indicate whether it is 
> "enabled" or not.  If a ValueModel is from a property path containing 
> "null", then it is considered disabled, otherwise it is considered 
> enabled.  So, we created a GuardedValueModel interface:
> 
> public interface GuardedValueModel extends ValueModel, Guarded, 
> PropertyChangePublisher
> {
>   String ENABLED_PROPERTY = "enabled";
> }
> 
> And implement this interface in the custom ValueModels returned from our 
> custom MPAS.  The ValueModel detects when the parent ValueModel becomes 
> non-null, then changes its enabled state (as defined in the Guarded 
> interface from Spring Rich), which fires a property change event.  We 
> then link this property change event to the Form's FieldMetadata by 
> overriding the postProcessNewValueModel method in DefaultFormModel:
> 
>   @Override
>   protected void postProcessNewValueModel(final String formProperty, 
> final ValueModel valueModel)
>   {
>     super.postProcessNewValueModel(formProperty, valueModel);
>     final GuardedValueModel guarded;
>     if(valueModel instanceof GuardedValueModel) {
>       guarded = (GuardedValueModel)valueModel;
>     } else if(valueModel instanceof ValueModelWrapper) {
>       final ValueModel inner = 
> ((ValueModelWrapper)valueModel).getInnerMostWrappedValueModel();
>       if(inner instanceof GuardedValueModel) {
>         guarded = (GuardedValueModel)inner;
>       } else {
>         guarded = null;
>       }
>     } else {
>       guarded = null;
>     }
> 
>     if(guarded != null) {
>       final FieldMetadata fieldMetadata = getFieldMetadata(formProperty);
>       
> guarded.addPropertyChangeListener(GuardedValueModel.ENABLED_PROPERTY, 
> new PropertyChangeListener() {
>         public void propertyChange(PropertyChangeEvent evt) {
>           fieldMetadata.setEnabled(guarded.isEnabled());
>         }
>       });
>     }
>   }
> 
> This isn't perfect, but works for our needs.
> We decided GuardedValueModel was easier than making, say, the "readable" 
> and "writeable" properties of PropertyMetaAspectAccessor mutable (and 
> observable) once we got into the guts of DefaultFormModel (and 
> AbstractFormModel).

Hmm, this looks like another use-case to me. You're referring to
transitive properties and their parent path which may return a null
value. I'm taking note of this, if I'm correctly the current BPAS
doesn't allow this and will give an exception when a parent path returns
null.

I guess your selected agency always has write/read access to the name
property and this doesn't change when having another implementation of
agency. So my use case would be having AgencyReadOnlyName and
AgencyWriteName (extending the former one). Then the field should switch
between read-only and writable.

Kind Regards,
Jan


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