Hi,
I once had a similar problem and made it work even with static steps.
Please allow me to share it.
I wanted to use statics steps in order "to feel them". Just for the fun, as
I did wizard with dynamic steps before.
So, I had a class Profile and wanted the wizard to create a new one (the
wizard was also for editing. I had a boolean representing that).
In the wizard, I use a CompundPropertyModel.
My solution was to pass the profile instance to the summary step in the
constructor.
The "magic" of the CPM made the profile instance updated.
In the summary step, I used onBeforeRender to show the updated profile.

Here's some code:

    private void initProfileWizard(final Profile *profile*, final boolean
newProfile,
            final PageParameters pageParametersForMainPage) {
        setModel(new CompoundPropertyModel(profile));
        final Profile originalProfile = new Profile(profile); // Used in
case of canceling edit.
        WizardModel wizardModel = new WizardModel() {
            private static final long serialVersionUID = 1L;

            @Override
            public void cancel() {
                super.cancel();
                if (newProfile) {
                    setResponsePage(ExtractRdbPage.class,
pageParametersForMainPage);
                } else {
                    final ViewProfilePage profilePage = new
ViewProfilePage(originalProfile, pageParametersForMainPage);
                    setResponsePage(profilePage);
                }
            }

            @Override
            public void finish() {
                super.finish();
                setResponsePage(ExtractRdbPage.class,
pageParametersForMainPage);
            }
        };
        wizardModel.add(new ProfileBasicInfoStep(newProfile, ...));
        wizardModel.add(new ProfileParametersStep(...));
        wizardModel.add(new ViewProfileStep(*profile*, newProfile, ...));

        init(wizardModel);
    }

the above method is called from the constructor. The input profile may be
new in one constructor or as parameter in another one.
The wizard can be activated from two different pages (new profile, or edit
profile), so I override the cancel.
Don't mind other parameters...

Here's the summary step:
public ViewProfileStep(final Profile *profile*, boolean newProfile, ...) {
...
    @Override
    public void applyState() {
        if (newProfile) {
            profile.add();
        } else {
            profile.update();
        }
    }

    @Override
    protected void *onBeforeRende*r() {
        addOrReplace(new ViewProfilePanel("viewProfile", profile));
        super.onBeforeRender();
    }
...
}

I know, I could easily do it with Dynamic steps...



Eyal Golan
egola...@gmail.com

Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74

P  Save a tree. Please don't print this e-mail unless it's really necessary


On Wed, Dec 2, 2009 at 10:06 AM, John Armstrong <siber...@siberian.org>wrote:

> Found my problem. I needed to be using a DynamicWizardModel, not a
> WizardModel. This lets me add the steps as required and therefore get
> access to the version of the model at that stage of the process.
>
> I'd done this before, just had to paw through my personal svn to find
> how I implemented it.
>
> Yes, it was a 'Doh!' moment.
>
> Tx-
> John-
>
> On Mon, Nov 30, 2009 at 7:21 AM, John Armstrong <siber...@siberian.org>
> wrote:
> > I believe my models are dynamic and self-contained. For example one is
> > a Serviceorder that lives in the net.pnc.model.Serviceorder class. I
> > have one instance of this in my wizard that is shared between all
> > screens. All properties of Serviceorder are private to Serviceorder
> > and accessed via getters/setters. So for example:
> >
> > add(new TextField("email", new PropertyModel(theOrder, "email")));
> >
> > where 'theOrder' is the wizard scoped instance of a Serviceorder.
> >
> > That seems correct to me, can you confirm?
> >
> > I see in the wicket examples project there is a Wizard that uses a
> > StaticContentStep for just this case. This leads me to believe that
> > the only way to accomplish this task is to do the same and basically
> > wrap that entire last step into the properties file and feed it the
> > model? Feels wrong to me..
> >
> > John-
> >
> > On Mon, Nov 30, 2009 at 3:07 AM, bgooren <b...@iswd.nl> wrote:
> >>
> >> Sounds like you are using static models instead of dynamic models.
> >>
> >> E.g. if you use Model.of("test"), the model is essentialy
> self-contained.
> >> Whereas if you have a property called "value" in your wizard and you use
> >> new PropertyModel( Wizard.this, "value" )
> >> , the model will depend on the value of the "value" property.
> >>
> >> Bas
> >>
> >>
> >> John Armstrong-3 wrote:
> >>>
> >>> It may just be late and I am missing the obvious but..
> >>>
> >>> I have a wizard. The last step needs to be a confirmation step however
> >>> it is constructed when added to the WizardModel in the Wizard
> >>> constructor and at this stage all of the backing models are empty
> >>> since, well, the user hasn't done anything.
> >>>
> >>> This means when I access models on the confirmation step all of the
> >>> model data is empty (it was built by wicket earlier in the process).
> >>>
> >>> What am I missing? This is a common use pattern so I am doing
> >>> something wrong since obviously the form has the data as back/forth
> >>> show it just fine. The only work-around I can think of is to not add
> >>> this step and then insert this step at the end myself (once the
> >>> objects are populated). Seems hacky though.
> >>>
> >>> Tx
> >>> John-
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >>>
> >>
> >> --
> >> View this message in context:
> http://old.nabble.com/Wizard-and-confirmation-screens-tp26570806p26572871.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>

Reply via email to