[Springframework-rcp-dev] To bean or not to bean.

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

Hi all,

There are some basic things in RCP that keep bothering me. More
specific, the way how the FormModel is created and how it's handled when
it is reset.

FormModel creation is done by providing a bean which is actually as
expected. After all we're working with spring, aren't we? Well, there
are two things I want to point out here:

1) when you create your FormModel, you provide a bean that will be used
to provide the necessary valueModels (VMs). Well, that's what you think
it will do. Say you just created that FormModel with beanA, then right
before showing that screen you set another FormObject beanB. Then the
process of component creation kicks in and starts creating bindings and
the necessary VMs. But at this moment beanB will be used to create VMs
and VMM (ValueModel MetaData). BeanA was never used! And more
troublesome, the VMM can result in a wrongly created binding. Say beanA
only has read access to propertyX, and you expect a readonly field at
that place, but beanB also provides write access to propertyX, so you'll
get a writable field.

In short, the bean given at formModel creation isn't always used, it's
the current bean that is of importance when VMs are created. It even
goes as far as: VMs can be created at any time always based on the
current bean which may have been changed over time.

2) now I know this may seem strange in a spring-world, but why do I even
need to specify a bean? The formModel and it's whole structure of VMs
could be created by looking at Class or Interface level. It is only a
structure that afterwards will be used to contain beans. Wouldn't it be
wonderful to have something like "new FormModel(MyInterface)" not having
to create a dummy bean? Take for example a back-end which provides the
beans. No default constructor is present and the client isn't supposed
to create new beans (only edit). However, RCP requires a bean to create
the formModel, and thus need to provide a dummy bean somehow.


Besides the creation aspect: FormModel reset and setting a null
formObject results in a special handling. The current formObject is used
to instantiate a new bean by calling a default constructor on its class.
So resetting the form actually places a new bean as formObject and this
bean can be different at at any time.

And now the real reason of this mail (finally!). 

Some of these issues could be resolved by storing the initially provided
bean and reusing this when resetting/setting null. This would prevent
the need to have a default constructor, but would not prevent the
creation of VMs on a current bean instead of the initially provided one
though. For some the latter may not be an issue. You do need to be aware
that when creating the formModel, the given bean should be a dummy one.

The second issue is the main thing I've been pondering of: to bean or
not to bean. Should we create the formModel based on beans (current
situation) or based on class/interface? We could create a FormModel
based on a class/interface, then set a FormObject when needed and
provide a null handling. The method getFormObject might actually return
null while no default constructor is needed. No bean at creation time is
needed. Now for al this magic to happen, I need to inform you that the
current implementation does rely on the beans plumbing of spring. This
isn't bad, but does mean a that some serious refactoring/implementing is
needed before this will work. Before I jump into this pit, I'm wondering
if this all makes sense. Is this worth the trip? Would you benefit from
this change? I'm guessing it would, but I'd like to have some feedback
on this first.

ps: it might be that these things have been surfaced a while ago and
that I'm just reopening the discussion. Haven't yet searched the mail
archive. (I remember whining about this a year or so ago, but did I mail
it??)

Kind Regards,
Jan


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