Re: Models, and preventing obsolete objects being manipulated by Ajax requests
It would be nice to have closures in Java ;). Yes, you should definitely work with models. If your problem persists you have to show us some code. Sven On 09/29/2012 09:32 AM, Ondrej Zizka wrote: On Sat, 2012-09-29 at 08:51 +0200, Sven Meier wrote: >Page#setDefaultModel( new PropertyModel( this, "user" ) ); And then in on* methods, >I should use getPage().getDefaultModelObject(). Models offer no magic: Doing the above versus just directly accessing the page's property doesn't change much (depending on what "this" is referring to). Well, my point was, that in onClick etc. I am creating kind of closure, and this closure keeps the reference it's given, even if the Page object's reference to User changes (whyever* should that happen). So, accessing it through getPage().getDefaultModelObject() will always give me the right one. The model object changes e.g. when ajax request executes `this.user = UserDao.update( this.user )`, e.g. if forms which update the entity on each input change. >Is that correct, or should I look for some other bug in my code? Your components are probably holding references to different User objects. Cleaning up your code using models might help. Sven On 09/29/2012 05:26 AM, Ondrej Zizka wrote: Hi, I have observed that if I simply refer to Page object's (say, User) member field everywhere, sometimes I get a strange behavior: Ajax requests update the User object properly. But then I have non-ajax save (submit) button, and this one actually saves the old state of the object, before editations. I get it I am supposed to use models in this case, like, Page#setDefaultModel( new PropertyModel( this, "user" ) ); And then in on* methods, I should use getPage().getDefaultModelObject(). Is that correct, or should I look for some other bug in my code? And also, what does the "default" mean in the methods names getDefaultModel*() ? Can the page/component have multiple models? Thanks, Ondra - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Models, and preventing obsolete objects being manipulated by Ajax requests
On Sat, 2012-09-29 at 08:51 +0200, Sven Meier wrote: > >Page#setDefaultModel( new PropertyModel( this, "user" ) ); And then in > on* methods, > >I should use getPage().getDefaultModelObject(). > > Models offer no magic: Doing the above versus just directly accessing > the page's property doesn't change much (depending on what "this" is > referring to). Well, my point was, that in onClick etc. I am creating kind of closure, and this closure keeps the reference it's given, even if the Page object's reference to User changes (whyever* should that happen). So, accessing it through getPage().getDefaultModelObject() will always give me the right one. The model object changes e.g. when ajax request executes `this.user = UserDao.update( this.user )`, e.g. if forms which update the entity on each input change. > > >Is that correct, or should I look for some other bug in my code? > > Your components are probably holding references to different User > objects. Cleaning up your code using models might help. > > Sven > > > On 09/29/2012 05:26 AM, Ondrej Zizka wrote: > > Hi, > > > > I have observed that if I simply refer to Page object's (say, User) > > member field everywhere, sometimes I get a strange behavior: > > Ajax requests update the User object properly. But then I have non-ajax > > save (submit) button, and this one actually saves the old state of the > > object, before editations. > > > > I get it I am supposed to use models in this case, like, > > Page#setDefaultModel( new PropertyModel( this, "user" ) ); > > And then in on* methods, I should use getPage().getDefaultModelObject(). > > > > Is that correct, or should I look for some other bug in my code? > > > > And also, what does the "default" mean in the methods names > > getDefaultModel*() ? Can the page/component have multiple models? > > > > Thanks, > > Ondra > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org >
Re: Models, and preventing obsolete objects being manipulated by Ajax requests
Each component can have as many models it needs. For an example see ListChoice which has one model for its selection and a second one for the available choices. Wicket's Component base class has a default model, which offers convenience (it's automatically detached after request) and some other goodies (i.e. inherited models). Read more here: https://cwiki.apache.org/WICKET/working-with-wicket-models.html >Page#setDefaultModel( new PropertyModel( this, "user" ) ); And then in on* methods, >I should use getPage().getDefaultModelObject(). Models offer no magic: Doing the above versus just directly accessing the page's property doesn't change much (depending on what "this" is referring to). >Is that correct, or should I look for some other bug in my code? Your components are probably holding references to different User objects. Cleaning up your code using models might help. Sven On 09/29/2012 05:26 AM, Ondrej Zizka wrote: Hi, I have observed that if I simply refer to Page object's (say, User) member field everywhere, sometimes I get a strange behavior: Ajax requests update the User object properly. But then I have non-ajax save (submit) button, and this one actually saves the old state of the object, before editations. I get it I am supposed to use models in this case, like, Page#setDefaultModel( new PropertyModel( this, "user" ) ); And then in on* methods, I should use getPage().getDefaultModelObject(). Is that correct, or should I look for some other bug in my code? And also, what does the "default" mean in the methods names getDefaultModel*() ? Can the page/component have multiple models? Thanks, Ondra - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
