Hi Paul,
thanx for your answer.
I will have a look at extending it. :-)
kind regards
Patrick
Am 17.02.2014 22:44, schrieb Paul Bors:
> We need to build the WizardModel in a dynamic way. Although I think there
> is a better more dynamic step too that can be used here.
>
> So one cheap solution is to keep an enum or some sort of a definition of
> your wizard steps:
> public static enum WizStep {
> /** Step 1 of N */ STEP_ONE(1),
> /** Step N of N */ STEP_N;
> ...
>
> private int stepNum;
>
> WizStep(int stepNum) {
> this.stepNum = stepNum;
> }
>
> public int getNum() {
> return this.stepNum;
> }
> }
>
> Then extend the wizard and build the model starting at the given step like
> so:
> private class MyWizard extends Wizard {
> private static final long serialVersionUID = 1L;
>
> public MyWizard(String id, WizStep startStep) {
> super(id);
> setDefaultModel(ediPojoModel);
>
> WizardModel model = new WizardModel();
> if(WizStep.STEP_ONE.getNum() >= startStep.getNum()) {
> model.add(new FirstWiwardStep()});
> }
> // Keep adding the rest of the steps
> ...
> if(WizStep.STEP_N.getNum() >= startStep.getNum()) {
> model.add(new NthStep());
> }
>
> init(model);
> }
> }
>
> Maybe a better approach is to create your own parent intelligent wizard
> step that will skip itself in the init() or onInit() method till it get to
> the Active step then you could build your model as normal.
>
> Have fun.
>
>
>
>
> On Mon, Feb 17, 2014 at 12:21 PM, Patrick Davids <
> [email protected]> wrote:
>
>> Hi all,
>> what is the best way to start a Wizard in a particular step?
>>
>> I tried:
>> - to override onInit of WizardStep and setting this to activeStep, when
>> the state is the right one, but init() of WizardModel always determines
>> the next step after me (the current active), so this seems not to be a
>> good way. I could set the prevoius, but this is quite faked.
>>
>> - to implement a condition; state is determined correct, but than all
>> buttons are deactive, hmm...
>>
>> - manually setting setActiveStep() after init of WizardModel, but this
>> needs to unpack model object to construction time to evaluate my state
>> on my own (but it worked as expected).
>>
>> Did I miss something? Or is the third implementation the best trade-off?
>>
>> kind regards
>> Patrick
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
