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