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

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
>