Override SwingBindingFactory w/out subclassing AbstractForm

[lstreepy]

Since I have added new component bindings, and I need a simple way to use them (ala the createBoundList in SwingBindingFactory). This leads to the need to override the getBindingFactory() method of AbstractForm (since it currently always returns a new instance of SwingBindingFactory).

It appears that I would have to extend AbstractForm, but that would mean that every form I create in my application would have to then extend from that new base class instead of AbstractForm. This will cause problems down the line when you consider the new form types like AbstractMasterForm and AbstractDetailForm.

It would seem that this problem is best suited by some form of injection configured in the application context. Am I in the weeds, or does this seem reasonable:

1. Define a new bindingFactoryProvider (or bindingFactoryFactory) bean that specifies the class of the provider that will generate BindingFactory instances at runtime.

2. Define a new interface, BindingFactoryProvider, that contains a simple method:

BindingFactory getBindingFactory(FormModel formModel)

Implementing classes would simply instantiate a proper object (like a SwingBindingFactory) using the form model provided.

3. Modify AbstractForm to get the provider from the ApplicationServices and then have the provider construct the BindingFactory.

This would seem like a simple solution (in line with the normal configuration style of Spring) and it would avoid the whole derivation hierarchy issue.

Comments? Is this something that has general value?

Thanks.
Larry.

[snpe]

You can do it with define bean
binderSelectionStrategy
and/or
conversionService

I think that exits example usage in petlinic sample

regards

[oliverhutchison]

Is this something that has general value?

Yes this should be certainly be configurable.

[lstreepy]

Would the approach I outlined be the right way to go?

I'm willing to work on it with a little guidance. :wink:

Thanks,
Larry.

[oliverhutchison]

Larry,

your approach is spot on. Basically what we need is:

* interface BindingFactoryProvider
* class SwingBindingFactoryProvider
* method ApplicaiontServices#getBindingFactory(FormModel) which delegates to a BindingFactoryProvider configured using the app context
* AbstractForm#getBindingFactory modified to delegate to ApplicaiontServices#getBindingFactory
* method AbstractForm#setBindingFactory so can override the factory returned from ApplicationServices if need be

If you can implement this and file an RFE that would be great.

Thanks,

Ollie[/list]

[lstreepy]

Cool - I'll work on this tomorrow.

Thanks for the help.

[lstreepy]

I've hit one snag in this implementation.

AbstractBindingFactory and SwingBindingFactory use ConfigurableFormModel in their constructors. This would seem overly restrictive.

AbstractBindingFactory works just fine with a plain FormModel. Only SwingBindingFactory needs the ConfigurableFormModel.

It seems wrong to declare all the methods in BindingFactoryProvider and ApplicationServices to work on ConfigurableFormModel, as this would prevent them from being used on instances of a NestingFormModel.

Should SwingBindingFactory be changed to take a FormModel and then test at runtime that it is properly typed?

Or is there a better solution? I don't know enough about the various form model types to know if excluding NestingFormModel is even a problem.

Thanks.
Larry.

P.S. Ok - digging a little deeper AbstractBinding internally casts the FormModel to a ConfigurableFormModel, so it appears that regardless of what the interface indicates, Bindings don't work on plain FormModel objects.

So, given that, I'm going to use ConfigurableFormModel in the interfaces and objects I'm creating now.

P.P.S. Or, should I just follow the current practice and have SwingBindingFactoryProvider cast the FormModel to a ConfigurableFormModel? That seems the most congruent with the current implementation.

P.P.P.S - had you worried there was more, huh? :wink:

[lstreepy]

An issue has been created and the implementation has been attached.

See: http://opensource2.atlassian.com/pro...browse/RCP-167

[oliverhutchison]

Thanks for all your hard work!

P.S. Ok - digging a little deeper AbstractBinding internally casts the FormModel to a ConfigurableFormModel, so it appears that regardless of what the interface indicates, Bindings don't work on plain FormModel objects.

So, given that, I'm going to use ConfigurableFormModel in the interfaces and objects I'm creating now.

Hummm... AbstractBindingFactory should not really need to do any configuration on the form model. I think we have this dependency because there are some methods (the 2 getters) on ConfigurableFormModel which really belong to FormModel. I'm reorganizing the form model code so this will be resolved soon.

Ollie

[lstreepy]

It's not in AbstractBingFactory (it can get along just fine with a base FormModel), the problem is in AbstractBinding:

private PropertyMetadataAccessStrategy getPropertyMetadataAccessStrategy() {
        return ((ConfigurableFormModel)formModel).getMetadataAccessStrategy();
    }