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