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/