[jifty-devel] Web wizards

[Alex Vandiver]

On Mon, 2006-10-09 at 15:43 +0200, Gaal Yahas wrote:
> A common pattern in web applications is emulating a native UI wizard.
> Typically, this means populating one model over a series of web pages,
> with "Next" and "Previous" navigation options, validation happening
> before leaving each page, and some action on the assembled data taking
> place only on the final page.

We hacked on this at some point in the past, but it never got baked
enough to actually use, so it got taken out in r1416, as part of other
refactorings.  Attached is a patch which puts it back in, as well as a
sample app which uses it.

  Note that the syntax is absolutely horrid at the moment.  But the
theory is as follows:

  Each page checks that it has a continuation which contains a specific
action.  If the continuation doesn't have such an action, it throws you
to the first page, with a carefully-constructed continuation set which
contains a return to the enclosing frame.
  At each page in the process, the user submits part of an action, with
J:WIZARD set to a continuation id.  This signals the request to pull out
and merge together the request stored in the continuation with the
incoming request -- this is what allows state to be preserved across
page boundaries.
  After validation, it checks if all actions validated.  If not, it
remains at the current page.  If they *did* validate, then it saves the
current continuation, but with the slight modification that the request
is set to be a call to the enclosing continuation.  This means that if
the wizard's continuation is ever *called* (as it is on the last page)
then all actions in the wizard's continuation get run.

  Since this is all done using continuations, which are immutable, this
means that the wizard is fully back-button compatible, and also
reentrant.  The "back" button on the page is implemented by looking at
the parent continuation of this one, and returning to its stored page,
with the current continuation adjusted appropriately.

  Anyways, take this as a proof-of-concept.  There are probably several
variations on this that may be slightly cleaner.  I suspect all of them
involve implementing a J:WIZARD equivalent which merges the current
request with a request in a continuation, though.

 - Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multipage.patch
Type: text/x-patch
Size: 10122 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20061020/a6c5afee/multipage-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Wizard.tar.gz
Type: application/x-compressed-tar
Size: 57866 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20061020/a6c5afee/Wizard.tar-0001.bin