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

[Andy D. <an...@ma...>]

I'm late to the discussion, and I like the idea you present, but I want 
to be sure care is taken to provide for non standard "beans" or form 
objects.  We have several cases where we use DataObjects (as in the SDO 
spec) as opposed to JavaBeans.  We get these to work with the Spring 
Rich Form framework by using a custom PropertyAccessStrategy (amongst 
other things).  Since the form framework already has the idea of a 
"ValueModel", why not have some sort of ClassModel (insert better name 
here) that drives the layout of the FormModel properties?  A convenience 
method could be provided that adapts a Java Class to a ClassModel.

  - Andy


Jan Hoskens wrote:
> 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
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
> .
>
>