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
