Sorry - typo on that step. The intent was that you use "new Model(model.getObject())" to pull an object out of any potential loadable / detachable model that may be passed in.
-- Jeremy Thomerson http://www.wickettraining.com On Fri, Oct 9, 2009 at 9:09 AM, Jeffrey Schneller < jeffrey.schnel...@envisa.com> wrote: > Thank Jeremy. The LDM was causing the problem. It does make sense > given your explanation. > > What do you intend with this code? > > public MyWizard(IModel<Foo> model) { > super(new Model(model.getObject())); > } > > The Wizard can only accept an IWizardModel and not the model I am going > to back it with. Unless I am completely twisted up. Did you intend > this to be the WizardStep? > > How then can I get my modal popup to store the values entered into it > when the user presses a save button and discard them and keep the values > from the model in the WizardStep if the user presses cancel. > > Thanks. > > Jeff > > > > -----Original Message----- > From: Jeremy Thomerson [mailto:jer...@wickettraining.com] > Sent: Thursday, October 08, 2009 11:03 PM > To: users@wicket.apache.org > Subject: Re: Showing Modal window within a wizard step > > Jeff, > Sorry I have not had time to read the entire post and that you have > not > found better documentation on this issue. However, your problem on this > is > almost certainly caused by the LoadableDetachableModel that is backing > your > CompoundPropertyModel in your wizard. > > Since a wizard is a multi-page process, you can not really use an LDM to > back it unless you persist changes after every step. With an LDM (and > not > persisting changes at every step), you end up with something like this > flow: > > WizardPageOne > - load model from LDM (presumably DB) > - display page with form > - submit page > - load model from LDM (presumably DB) > - stick values onto model object > - redirect to page two > WizardPageTwo > - load model from LDM (presumably DB) > This is where the problem is - because those changes weren't persisted, > the > model was detached, and when page two was rendered, reloaded. The > changes > were lost. > > So, in your situation, substitute the modal window for page two - the > changes weren't making it into the model object that was used in the > modal. > > So, in any multi-page process, you either need to persist the changes > back > down to wherever the LDM is loading from, or simply remove the LDM when > the > wizard (or other multi-page process) is started, OR pass the model > object > directly onto the other steps. > > I find it easiest to do something similar to this: > > public MyWizard(IModel<Foo> model) { > super(new Model(model.getObject())); > } > > Since the model holds on to the actual object between requests, your > changes > stay on the model object without persisting to your data store between > each > request. > > This goes against the standard use of models where you want something to > detach after every request, so it is counter-intuitive, but it is > actually > very similar in thought to most any framework - where you will need to > hold > a transient object in session during a multi-page process or persist a > partially-completed model object to the data store on every request. > > Hope this helps! > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > > On Thu, Oct 8, 2009 at 3:43 PM, Jeffrey Schneller < > jeffrey.schnel...@envisa.com> wrote: > > > I am completely lost. I have no idea what this means. How can the > > resolution to my problem be a JIRA issue that was created earlier > today? > > To find out how to do something who would think to look in the issue > > tracking system which contains bugs and enhancement requests. > > > > Anyhow, I resolved my loading of the modal with data by ditching the > > LoadableDetachableModel for the time being and using a > > CompoundPropertyModel. I know it is not "correct" but it works for > now. > > > > Now I am attempting to get the data back into the form that the modal > is > > called from. You would think this is easy. But again I am stuck. > > > > Wizard > > WizardStep ==> data show is read only with a modify link > > which brings > > the modal up. > > Modal ==> shows the data as editable. Allows user to > press > > submit > > button which closes window and updates the data > > in the WizardStep > > > > > > Please, any help with a simple real example will be appreciated. > > Pointing someone to a past post which may touch on the topic in the > > context of another question is not help. I am sure someone knows how > to > > solve my issue. > > > > Thanks. > > > > PS: I need to stick with Wicket because I am at the point of no > return > > on this project. > > > > > > -----Original Message----- > > From: Pedro Santos [mailto:pedros...@gmail.com] > > Sent: Thursday, October 08, 2009 4:01 PM > > To: users@wicket.apache.org > > Subject: Re: Showing Modal window within a wizard step > > > > I disagree, at the moment a got this trouble, few minutes was > necessary > > to I > > understand what was happening... > > any way: https://issues.apache.org/jira/browse/WICKET-2515 > > > > On Thu, Oct 8, 2009 at 2:32 PM, Jeffrey Schneller < > > jeffrey.schnel...@envisa.com> wrote: > > > > > We are using wicket to have clean html void of jsp tags. Because > they > > > cause maintenance problems as the sites evolve over time. Wicket > was > > > suggested as a possible solution for this. Which it is but the lack > > of > > > decent documentation/examples of real world issues is getting to be > an > > > issue. > > > > > > -----Original Message----- > > > From: Pedro Santos [mailto:pedros...@gmail.com] > > > Sent: Thursday, October 08, 2009 12:38 PM > > > To: users@wicket.apache.org > > > Subject: Re: Showing Modal window within a wizard step > > > > > > I have built multiple large sites with jsp/servlets/javascript/ajax > > that > > > are 1000x more complex than what I am trying to do with less > > headaches. > > > > > > so why you are using wicket? > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > -- > > Pedro Henrique Oliveira dos Santos > > > > > > --------------------------------------------------------------------- > > 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 > >
