Wizard at BASE

[Peter Robinett]

Hi David,

Thanks for presenting your latest work on Wizard last night at the Bay
Area Scala Enthusiasts meetup. I enjoyed hearing about Wizard and have
a few comments that I wanted to share with you and the rest of the
Lift community. I know Wizard is very new and I'm only going by what I
learned last night, so please bear with me if I misunderstood
anything!

As I understand it a Wizard instance is composed of screens
('questions'? I forget the exact terminology), each of which can have
multiple inputs, each input having a prompt ('Name', 'Your mother or
father's name', etc) and multiple validation rules. User input is
saved each time the user hits the Submit (or Next, in your example)
button. User state is stored from screen to screen and can be rolled
backwards but not forward. This is analogous to checking out an older
revision in a version control system, with each submitted screen being
a revision, but then loosing all revisions since the checkout
(rebasing the HEAD I believe it's called in Git).

What I expected, and what I think many other people would expect, is
that going back and forward among screens does not change the Wizard
state but simply changes what portion of the questions and responses
the user sees. In this case each screen is a simple, reduced view of
the current state, rather than a state in itself.

To use an analogy, think of a Wizard instance as an (annoying)
adventure game and each screen as a dungeon room. Let's say I fight my
way through several rooms full of grues, only to reach a locked door.
I'm told that the switch to unlock the door is 2 rooms back. I go back
(ie the previous screen method is fired twice) and I throw the switch.
Unfortunately, Wizard has also rolled back the dungeon state two
revisions and the intermediate room and room with the door now have
fearsome grues in them again! (In fact, I think Wizard could be used
quite easily for adventure games like that. Cool! I'm reminded of my
time making games in HyperCard. =)

To give another example, let's say I have a Wizard representing an e-
commerce site and have the following screens: shopping cart -> name
and shipping address -> credit card and billing address ->
confirmation. If I get to the confirmation screen and see that I added
2 Widgets and only want to buy 1, I want to be able to go back to the
shopping cart screen to make my change without losing the addresses
and payment details I entered in the intermediate screens.

Am I describing Wizard correctly, and if so, why did you chose the
first method of operation over the second? Can the second mode be
added?

Thanks for all the great work and I'm really looking forward to using
Wizard!

Peter Robinett

[David Pollak]

Not easily.  Snapshotting at a point in time and rolling back to that point is easy with immutability.  Merging different branches of a given snapshot is non-trivial and is not likely a feature that will make it into Wizard in the near term.  Put another way, 3 way merges on text is non-trivial.  3 way merges on non-text is not a solved problem that I know of.  Further, once you merge text in Git, you have the compiler test to make sure that code makes sense, but doing logic testing would be difficult during a merge phase.

 

Thanks for all the great work and I'm really looking forward to using
Wizard!

Peter Robinett

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

[Naftoli Gugenheim]

Sounds like Wizard is very complex!
Peter, if all you want is to split a form among several screens with one continuous state, see BindPlus.bindSwitch. All you need to do is put the separate screens in sibling elements in the template, and tell bindSwitch which xml to output and it will leave out the others. Use a StatefulSnippet or RequestVars and use links or buttons to update the input to bindSwitch, such as a page number.


-------------------------------------

[Randinn]

Its sounds like your presentation went well, congrats. now we need to
talk you into a Melbourne trip. :)

On Nov 11, 5:15 am, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[Peter Robinett]

Thanks, Naftoli, it sounds like the solution you describe is what I
thought Wizard would (or could) be.

Peter

On Nov 10, 11:33 am, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
> Sounds like Wizard is very complex!
> Peter, if all you want is to split a form among several screens with one continuous state, see BindPlus.bindSwitch. All you need to do is put the separate screens in sibling elements in the template, and tell bindSwitch which xml to output and it will leave out the others. Use a StatefulSnippet or RequestVars and use links or buttons to update the input to bindSwitch, such as a page number.
>
> -------------------------------------
>

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[David Pollak]

On Tue, Nov 10, 2009 at 1:12 PM, Peter Robinett <pe...@bubblefoundry.com> wrote:

Thanks, Naftoli, it sounds like the solution you describe is what I
thought Wizard would (or could) be.

Wizard is a conceptual descendant of SmartMode Wizard (see http://tunaforcats.com/wizard.wmv)  In SmartMode we tried to do what you suggested and it was a source of a huge number of bugs and tremendous code complexity.  You may think you want the feature, but from experience, what you think is easy is tremendously difficult when you actually try to make it work in anything but the most trivial circumstances.
 

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890

[Jeppe Nejsum Madsen]

David Pollak <feeder.of...@gmail.com> writes:

> On Tue, Nov 10, 2009 at 1:12 PM, Peter Robinett <pe...@bubblefoundry.com>wrote:
>
>>
>> Thanks, Naftoli, it sounds like the solution you describe is what I
>> thought Wizard would (or could) be.
>>
>
> Wizard is a conceptual descendant of SmartMode Wizard (see
> http://tunaforcats.com/wizard.wmv) In SmartMode we tried to do what you
> suggested and it was a source of a huge number of bugs and tremendous code
> complexity. You may think you want the feature, but from experience, what
> you think is easy is tremendously difficult when you actually try to make it
> work in anything but the most trivial circumstances.

Having worked with implementation of constraint engines for many years,
I can attest to the complexity of the general case. Imagine what should
happen with state on page 3 if it depends on state on page 2 in
non-trivial ways and you go back and change page 2 :-)

On the other hand, it would seem that some of the trivial circumstances
(where state on each page is independent) actually arise often in
practice. E.g where a wizard is merely dividing a process into
independent steps (as in the shopping basket example)

/Jeppe

[Naftoli Gugenheim]

So it sounds like lift-wizard is designed for the nontrivial case. :)
That said, I use bindSwitch in a scenario where page 2 depends on page 1 (showing a varying number of combo boxes with varying contents, to become MappedOneToMany children, to oversimplify), and it's not very complicated.
My impression is that Lift Wizard is much more, but I'm not clear what.
By the way, I couldn't play the wmv -- it said it needed a codec.


-------------------------------------

[Askia]

Will there be always be a lost even if there was not an actual change or
maybe the change does actually have a logical impact on future pages?

--
View this message in context: http://old.nabble.com/Wizard-at-BASE-tp26288138p26293186.html
Sent from the liftweb mailing list archive at Nabble.com.

[David Pollak]

On Tue, Nov 10, 2009 at 3:16 PM, Askia <askiade...@gmail.com> wrote:

Will there be always be a lost even if there was not an actual change or
maybe the change does actually have a logical impact on future pages?

If the "prev" button is pressed, the state of the world will return to what it was before the screen was entered.
 

[Jonathan Ferguson]

Surely you mean Sydney :)

2009/11/11 Randinn <ran...@gmail.com>