[Zope-PTK] wizards.mvc

[Jeffrey P Shell]

Wizards *REALLY* want to have a good model/view/controller(presenter)
architecture beneath them.  They should be bolt-ons (at least at the class
level), maybe accessed via some sort of delegate machinery that knows to
intercept an "add object" or some other event (although that is taking
things a bit far).  In any case, a wizard should be an
at-the-highest-level-possible view of an object or process.


Or it can be a bunch of web pages stuck together that does something at the
end, but that just hurts.  :)  (Especially without session support for the
web/html side of things).


A danger that can happen with wizards is that the wizard takes over a
certain process too tightly which makes that object or process hard to reuse
due to its dependency on the wizard.  Which is again why a good MVC
architecture (or at least -- guidelines) is critical.  A wizard is a
human-interactive way of stepping through a process (and not always the best
way, but I'll leave my biases aside to keep Paul happy :), but you don't
want that to get in the way of performing the same process automatically or
through a more advanced interface that may only have one or two screens
instead of six or seven.


Another issue is for Wizards that are really intelligent (or are trying to
be intelligent) and need to change state in their environment.  An old
Principia product had a Wizard interface bolted on to it, and part of the
process involved uploading a potentially very large file.  The rest of the
process needed the information garnered from that upload (after it was
turned into a Zope/Principia object) some optional parts of the process.
The danger here was that the Object needed to be created at some point in
the process, and therefor couldn't be backed out of easily (canceled) due to
the ZPublisher notion that every REQUEST-RESPONSE cycle is a transaction in
the ZODB/TransactionManager sense.  A really smart "wizard" could (and
should) find a way to recover gracefully by not making the object "public"
(in a Portal sense I suppose) and reminding the user that they didn't
complete an action and letting them resume where they left off.

An example of that is the major MP3 sites such as MP3.com.  MP3c has the
scenario of a member uploading files up to 20 megabytes in size (their
maximum allowed size), and some browsers time out on smaller connections, or
during such a potentially long upload process something happens on the
Members machine and the browser quits or they (accidentally or purposefully)
cancel out of the process by hitting the stop button or going to another URL
in the same window.  Or they might do that after they have uploaded the file
successfully and it meets the minimum MP3.com requirements about
format/size/bitrate/etc.  The member can see that one of their mp3 objects
wasn't created successfully with a "click here to continue" option (there
may be a "start over" function as well, I can't remember.  I think the
object can always be deleted).  The MP3 file won't go through their review
process until the process has been successfully completed.


[ In regards to sessions, WebObjects is king. ]


-- 
Jeffrey P Shell, jeffrey@Digicool.com
http://www.zope.org/