@edvin Partially commits sound good to me

@gtnarg Yeah, I think so too. I think people would run into this issue pretty quickly if we don't address it now, and it makes the whole ViewModel and ValidationContext nicer, so I'll try to add support for this right away.

I think it worked. It was a very minor refactoring, so definitely worth it.

@edvin How about a Keyboard Layer Mapping Wizard? Select keyboard type (ex, POK3R), select a profile (ex, IntelliJ mappings), language mappings (ex, Norwegian)

pull in an image with the selection on Step 1

@carlw Hehe.. so niche 🙂 But I found out that it is important to shine light on how to deal with committing to the same viewmodel from different wizard pages, so what I have now is small enough to not be confusing while just complex enough to get the point across.

@edvin Does the wizard have a final commit to the model and a chance to bail out?

Had a long working day and did not get around to test the wizard yet, will play with them tomorrow... night guys..and thanks @edvin work the great work

No problem, I'm still working on it, it's missing some features and adjustments.

@nimakro You might as well hold of with testing the Wizard until I have ironed out some more bugs 🙂

I'm unsure of when the Next button should be enabled, same for Finish. I'm dead tired now, but I'll describe it better tomorrow and ask for advice.

@edvin Regarding the next and finish button, how about to enable the button as soon as all the required fields in one step are satisfied?

could that be an option?

I have a use case where I want to switch between the steps without having to fill in all the fields

@ron Well if you fields are not required then that would work out of the box? @edvin Or optionally you could pass in a callback function which returns a boolean and depending on that value the button is enabled?

What I have done now is to enable the back/next button whenever there is a previous/next step. There is an override available where you can specify

canGoNext

and

canGoBack

as a

BooleanExpression

if you want another behavior. Same goes for

Finish

. By default, it is always available, but you can override

canFinish

and create some binding or property which you update based on the input. This gives the flexibility to only enable buttons when they can actually do something meaningful, but we don't require the author of the Wizard to create a water tight scheme for the button states.

Whenever you hit

Next

, the

onSave

callback for the current view is triggered. After

onSave

has run, the Wizard will check if the current page's

complete

boolean expression returns true (You can trigger it manually by setting

isComplete = true/false

. By default, all wizard pages are complete, so you don't need to deal with this unless you want to prevent the user from going to the next page until the step is complete.

The same goes for the

Finish

button. If

canFinish

is true (it is by default), you can hit the button. If the

complete

state of the Wizard is then true, the Wizard will close. You hook your "complete action` inside

onSave

of the Wizard itself.

So basically, the wizard itself and the wizard pages behaves the same way.

onSave

is called so you can perform your action, and you are required to change

complete

state if you want to prevent it from going to the next page or finishing, respectively.

A typical thing to do in

onSave

on a Wizard step, would be to update the complete state based on validation of the inputs in the current page. For example:

@User uploaded a file: Untitled

This configures the complete functionality based on the validation/commit state of those three properties.

Alternatively, you could bind the complete state directly in the view:

We could of course create a valid binding for specific fields so you can write:

Dealing with specific fields is only necessary if the same ViewModel is shared between different Wizard Pages. If we just call

commit

we would require all validators on all Wizard Pages for this ViewModel to be valid.

I'm trying to come up with a way to share a ViewModel, but have a ValidationContext that is local only to the current Page. Then we wouldn't need to deal with mentioning those fields at all.

(Rant complete)

I created a booleanListBinding function in ViewModel so you can now say

customer.valid(customer.name, customer.zip, customer.city)

to get a

BooleanExpression

which will update as the validators for the mentioned fields are updated.