That is true... it would require a proxy service in order to intercept the IModel#setObject calls.
-----Original Message----- From: Daniel Freitas [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 7:02 PM To: users@wicket.apache.org Subject: Re: Component#modelChanging and Component#modelChanged when IModel#setObject What would happen if more than one component uses the same model? Would we keep a list of components to notify? If that's the case why not just implement listeners instead, so then any class could listen to model changes. It's a nice idea except that IModel would have to be turned in to a class instead of an interface and that seems more restrictive than not having those methods being called :(. I'm new to Wicket and never needed to use those methods but I guess that making IModel a class and increasing the coupling between model and component is a price too high to pay for it. 2008/7/31 Hoover, William <[EMAIL PROTECTED]> > Yes, it does seem to be a difficult task to accomplish unless the > model itself is component aware. Nonetheless, it seems relatively > useless to have the onchanging/onchanged methods if they cannot do > what they claim they can do- don't you agree? > > If models were component aware it would simply be a matter of setting > the component on the model when Compopnent#setModel is called. Then > when IModel#setObject is called it could in turn call > Component#modelChanging/modelChanged. This obviously requires a tight > coupling relationship between the component and the model, but at > least notifications of model object changes can be guaranteed. > > -----Original Message----- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 31, 2008 6:16 PM > To: users@wicket.apache.org > Subject: Re: Component#modelChanging and Component#modelChanged when > IModel#setObject > > well, it notifies if the model is changed through the component. > > there is no way for us to really intercept a setobject call on an > arbitrary model instance, figure out which components it is currently > attached to, and call modelchanging methods on them. > > -igor > > On Thu, Jul 31, 2008 at 3:08 PM, Hoover, William <[EMAIL PROTECTED]> > wrote: > > Well, I am still trying to hash that one out- any ideas? > > > > I just think that if there is a method that indicates that it will > > be called anytime that a model is changing that it should follow > > through with that contract. > > > > -----Original Message----- > > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > > Sent: Thursday, July 31, 2008 6:01 PM > > To: users@wicket.apache.org > > Subject: Re: Component#modelChanging and Component#modelChanged when > > IModel#setObject > > > > how should we handle that? > > > > -igor > > > > On Thu, Jul 31, 2008 at 2:43 PM, Hoover, William > > <[EMAIL PROTECTED]> > > wrote: > >> Seems strange that Component#modelChanging and > >> Component#modelChanged > > >> are never called when IModel#setObject is called... > >> > >> https://issues.apache.org/jira/browse/WICKET-1764 > >> > >> > >> ------------------------------------------------------------------- > >> -- To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
