springframework-rcp-dev

[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

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

[Rogan D. <ro...@da...>]

Jan Hoskens wrote:
> Hi all,
> 

> 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

Hi Jan,

Not having worked very heavily with FormModels, but struggling when I 
did, I agree with your analysis.

It DOES make more sense to have the FormModel based on a Class or 
Interface, rather than an instance.

Rogan

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

[Benoit X. <bx...@ob...>]

Hi all,

I agree with Jan's case and go further in that replacing the form object
seems to trigger some strange behaviour due to the call to reset. I'm =
not
sure it is actually required... surely not in all cases anyway.

This is especially true if one has a lot of "business" logic hanging of =
the
model (things handled by PropertyListeners on some properties). Changing =
the
formObject then has a massive ripple effect due to the reset call, it =
then
requires some specific code to simply "be ignored!".  I did raise this =
about
a year ago as I was facing exactly the case of having to provide a =
'dummy'
bean before asking the user for the Id of the bean and then fetch it and
display it by calling setFormObject... I'd like FormModel to be able to =
take
a class/interface.

It would also be useful to have the ability to enable / disable ALL
PropertyListeners in the subsequent ValueModels. So one could have a =
'dead'
form, set the object, then enable logic for handling potential changes.

I'd like to add that a parametizable/generics FormModel would also be =
useful
I think. But that would either require a move to 1.5 or to be in the =
tiger
module. Furthermore, it would be useful to provide helper methods on
ValueModel to get an Integer, a String, a Date, a BigDecimal... that =
would
remove much casting... Again, use of generics could help.

In any case, please do not break dramatically the existing interfaces...

My =A30.02 worth comments,

Thanks

Benoit


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Rogan Dawes
Sent: 20 July 2007 10:05
To: spr...@li...
Subject: Re: [Springframework-rcp-dev] To bean or not to bean.

Jan Hoskens wrote:
> Hi all,
>=20

> 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.
>=20
> 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??)
>=20
> Kind Regards,
> Jan

Hi Jan,

Not having worked very heavily with FormModels, but struggling when I=20
did, I agree with your analysis.

It DOES make more sense to have the FormModel based on a Class or=20
Interface, rather than an instance.

Rogan


-------------------------------------------------------------------------=

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

No virus found in this incoming message.
Checked by AVG Free Edition.=20
Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: =
19/07/2007
18:10
=20

No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: =
19/07/2007
18:10
=20

Re: [Springframework-rcp-dev] To bean or not to bean. => Class based formmodels

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

+1  to creating a FormModel based on a Class (or interface)

We 've discussed this before, but no one felt strong enough to implement it:


Replay of an old mail of mine "Class based formmodels - WDYT"

===
Currently form models are instance based.
- they can't handle null values. A possible use case for a null value
could be the details form of a master-detail view when nothing is
selected. I think Larry had to sort of hack that.
- it limits us from dependency injecting forms (as they need a form
model based on an instance)

Should they be class based,
just like ORM mappings are also class based?
What do you think?


Backward compatibility can be ensured like this:

public FormModel(Object o) {
    this(o.getClass());
    setFormObject(o);
}
===

spring-core always uses bean instances, but spring-core is an 
initialization framework NOT a binding framework.
jpa, hibernate, toplink are class based, they are binding frameworks (to 
the database instead of the gui however).

With kind regards,
Geoffrey De Smet

Benoit Xhenseval schreef:
> Hi all,
> 
> I agree with Jan's case and go further in that replacing the form object
> seems to trigger some strange behaviour due to the call to reset. I'm not
> sure it is actually required... surely not in all cases anyway.
> 
> This is especially true if one has a lot of "business" logic hanging of the
> model (things handled by PropertyListeners on some properties). Changing the
> formObject then has a massive ripple effect due to the reset call, it then
> requires some specific code to simply "be ignored!".  I did raise this about
> a year ago as I was facing exactly the case of having to provide a 'dummy'
> bean before asking the user for the Id of the bean and then fetch it and
> display it by calling setFormObject... I'd like FormModel to be able to take
> a class/interface.
> 
> It would also be useful to have the ability to enable / disable ALL
> PropertyListeners in the subsequent ValueModels. So one could have a 'dead'
> form, set the object, then enable logic for handling potential changes.
> 
> I'd like to add that a parametizable/generics FormModel would also be useful
> I think. But that would either require a move to 1.5 or to be in the tiger
> module. Furthermore, it would be useful to provide helper methods on
> ValueModel to get an Integer, a String, a Date, a BigDecimal... that would
> remove much casting... Again, use of generics could help.
> 
> In any case, please do not break dramatically the existing interfaces...
> 
> My £0.02 worth comments,
> 
> Thanks
> 
> Benoit
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> Rogan Dawes
> Sent: 20 July 2007 10:05
> To: spr...@li...
> Subject: Re: [Springframework-rcp-dev] To bean or not to bean.
> 
> Jan Hoskens wrote:
>> Hi all,
>>
> 
>> 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
> 
> Hi Jan,
> 
> Not having worked very heavily with FormModels, but struggling when I 
> did, I agree with your analysis.
> 
> It DOES make more sense to have the FormModel based on a Class or 
> Interface, rather than an instance.
> 
> Rogan
> 
> 
> -------------------------------------------------------------------------
> 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
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19/07/2007
> 18:10
>  
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition. 
> Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19/07/2007
> 18:10
>  
> 
> 
> -------------------------------------------------------------------------
> 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/

Re: [Springframework-rcp-dev] To bean or not to bean. => Class based formmodels

[Roland R. <rr...@vd...>]

+1 to creating a FormModel based on a class (or interface)

This could make it possible to create FormModels on abstract Classes and 
do some sort of inheritance, instead of creating an FormModel (and Form) 
for every implementation of the base class.

Roll

Geoffrey De Smet wrote:
> +1  to creating a FormModel based on a Class (or interface)
>
> We 've discussed this before, but no one felt strong enough to implement it:
>
>
> Replay of an old mail of mine "Class based formmodels - WDYT"
>
> ===
> Currently form models are instance based.
> - they can't handle null values. A possible use case for a null value
> could be the details form of a master-detail view when nothing is
> selected. I think Larry had to sort of hack that.
> - it limits us from dependency injecting forms (as they need a form
> model based on an instance)
>
> Should they be class based,
> just like ORM mappings are also class based?
> What do you think?
>
>
> Backward compatibility can be ensured like this:
>
> public FormModel(Object o) {
>     this(o.getClass());
>     setFormObject(o);
> }
> ===
>
> spring-core always uses bean instances, but spring-core is an 
> initialization framework NOT a binding framework.
> jpa, hibernate, toplink are class based, they are binding frameworks (to 
> the database instead of the gui however).
>
> With kind regards,
> Geoffrey De Smet
>
> Benoit Xhenseval schreef:
>   
>> Hi all,
>>
>> I agree with Jan's case and go further in that replacing the form object
>> seems to trigger some strange behaviour due to the call to reset. I'm not
>> sure it is actually required... surely not in all cases anyway.
>>
>> This is especially true if one has a lot of "business" logic hanging of the
>> model (things handled by PropertyListeners on some properties). Changing the
>> formObject then has a massive ripple effect due to the reset call, it then
>> requires some specific code to simply "be ignored!".  I did raise this about
>> a year ago as I was facing exactly the case of having to provide a 'dummy'
>> bean before asking the user for the Id of the bean and then fetch it and
>> display it by calling setFormObject... I'd like FormModel to be able to take
>> a class/interface.
>>
>> It would also be useful to have the ability to enable / disable ALL
>> PropertyListeners in the subsequent ValueModels. So one could have a 'dead'
>> form, set the object, then enable logic for handling potential changes.
>>
>> I'd like to add that a parametizable/generics FormModel would also be useful
>> I think. But that would either require a move to 1.5 or to be in the tiger
>> module. Furthermore, it would be useful to provide helper methods on
>> ValueModel to get an Integer, a String, a Date, a BigDecimal... that would
>> remove much casting... Again, use of generics could help.
>>
>> In any case, please do not break dramatically the existing interfaces...
>>
>> My £0.02 worth comments,
>>
>> Thanks
>>
>> Benoit
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On Behalf Of
>> Rogan Dawes
>> Sent: 20 July 2007 10:05
>> To: spr...@li...
>> Subject: Re: [Springframework-rcp-dev] To bean or not to bean.
>>
>> Jan Hoskens wrote:
>>     
>>> Hi all,
>>>
>>>       
>>> 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
>>>       
>> Hi Jan,
>>
>> Not having worked very heavily with FormModels, but struggling when I 
>> did, I agree with your analysis.
>>
>> It DOES make more sense to have the FormModel based on a Class or 
>> Interface, rather than an instance.
>>
>> Rogan
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition. 
>> Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19/07/2007
>> 18:10
>>  
>>
>> No virus found in this outgoing message.
>> Checked by AVG Free Edition. 
>> Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19/07/2007
>> 18:10
>>  
>>
>>
>> -------------------------------------------------------------------------
>> 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/
>>     
>
>
> -------------------------------------------------------------------------
> 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/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>   

Re: [Springframework-rcp-dev] To bean or not to bean. => Class based formmodels

[Vamsi P. <vpu...@gm...>]

Hi Geoffrey,

I have a question:

how do I integrate persistence into the AbstractDetailForm, I have extended
this form to add it into the commit method. This propogates the commited bu=
t
unsaved instance to the master side. Is there a better place for me to
commit the form model, persist it and propogagte it back to the form model?

Thanks


Vamsi

On 7/23/07, Geoffrey De Smet <ge0...@gm...> wrote:
>
> +1  to creating a FormModel based on a Class (or interface)
>
> We 've discussed this before, but no one felt strong enough to implement
> it:
>
>
> Replay of an old mail of mine "Class based formmodels - WDYT"
>
> =3D=3D=3D
> Currently form models are instance based.
> - they can't handle null values. A possible use case for a null value
> could be the details form of a master-detail view when nothing is
> selected. I think Larry had to sort of hack that.
> - it limits us from dependency injecting forms (as they need a form
> model based on an instance)
>
> Should they be class based,
> just like ORM mappings are also class based?
> What do you think?
>
>
> Backward compatibility can be ensured like this:
>
> public FormModel(Object o) {
>     this(o.getClass());
>     setFormObject(o);
> }
> =3D=3D=3D
>
> spring-core always uses bean instances, but spring-core is an
> initialization framework NOT a binding framework.
> jpa, hibernate, toplink are class based, they are binding frameworks (to
> the database instead of the gui however).
>
> With kind regards,
> Geoffrey De Smet
>
> Benoit Xhenseval schreef:
> > Hi all,
> >
> > I agree with Jan's case and go further in that replacing the form objec=
t
> > seems to trigger some strange behaviour due to the call to reset. I'm
> not
> > sure it is actually required... surely not in all cases anyway.
> >
> > This is especially true if one has a lot of "business" logic hanging of
> the
> > model (things handled by PropertyListeners on some properties). Changin=
g
> the
> > formObject then has a massive ripple effect due to the reset call, it
> then
> > requires some specific code to simply "be ignored!".  I did raise this
> about
> > a year ago as I was facing exactly the case of having to provide a
> 'dummy'
> > bean before asking the user for the Id of the bean and then fetch it an=
d
> > display it by calling setFormObject... I'd like FormModel to be able to
> take
> > a class/interface.
> >
> > It would also be useful to have the ability to enable / disable ALL
> > PropertyListeners in the subsequent ValueModels. So one could have a
> 'dead'
> > form, set the object, then enable logic for handling potential changes.
> >
> > I'd like to add that a parametizable/generics FormModel would also be
> useful
> > I think. But that would either require a move to 1.5 or to be in the
> tiger
> > module. Furthermore, it would be useful to provide helper methods on
> > ValueModel to get an Integer, a String, a Date, a BigDecimal... that
> would
> > remove much casting... Again, use of generics could help.
> >
> > In any case, please do not break dramatically the existing interfaces..=
.
> >
> > My =A30.02 worth comments,
> >
> > Thanks
> >
> > Benoit
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behal=
f
> Of
> > Rogan Dawes
> > Sent: 20 July 2007 10:05
> > To: spr...@li...
> > Subject: Re: [Springframework-rcp-dev] To bean or not to bean.
> >
> > Jan Hoskens wrote:
> >> Hi all,
> >>
> >
> >> 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 retur=
n
> >> 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 fro=
m
> >> 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
> >
> > Hi Jan,
> >
> > Not having worked very heavily with FormModels, but struggling when I
> > did, I agree with your analysis.
> >
> > It DOES make more sense to have the FormModel based on a Class or
> > Interface, rather than an instance.
> >
> > Rogan
> >
> >
> >
> -------------------------------------------------------------------------
> > 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
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date:
> 19/07/2007
> > 18:10
> >
> >
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date:
> 19/07/2007
> > 18:10
> >
> >
> >
> >
> -------------------------------------------------------------------------
> > 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/
>
>
> -------------------------------------------------------------------------
> 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/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

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