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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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