Well, I've though aabout proxies, but didn't depicted it in my previous message, but since you touched the subject... It's more more complex to do but maybe that's the best approach. You can do this at a project level, without interfering with the framework directly. You can even componentize your solution to be shared by other projects. One could write a java dynamic proxy handler that binds the components and model together and notify the components when the model is about to be updated. The nice thing about his approach is that it does not affect the involved classes (IModel and Component). Of course, you would have to create your models through some kind of factory to have the proxies returned instead (and be carefull not to call modelChanged() twice when the model is changed from the componnent itself). If you really need this functionality it might be worth implementing it.
That sounds like fun... Regards, Daniel 2008/7/31 Hoover, William <[EMAIL PROTECTED]> > 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: [email protected] > 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: [email protected] > > 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: [email protected] > > > 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] > >
