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. > > ------------------------------------- > > David Pollak<feeder.of.the.be...@gmail.com> wrote: > > On Tue, Nov 10, 2009 at 9:52 AM, Peter Robinett > <pe...@bubblefoundry.com>wrote: > > > > > > > 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? > > 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 frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Surf the harmonics --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---