Mailing List Archive

Andrew Wilcox writes:
>removing duplicatation. Take a look, and update!
> http://www.zope.org/Products/PTK/ZWiki/WizardDesignContest

Pretty good, though many of the issues are portal-specific ones. For
example, the first one is "A user should be able to use a wizard to
edit an object, as well as add one." But there can be wizard
applications that don't create anything; imagine wizards that help you
debug a problem by stepping through a bunch of screens, and doing a
combination of automated tests and querying the user ("Did you receive
an e-mail?"). I'd drop goals #1, #6, #7 and the final two goals. #4
and #5 would belong in a Wizard Style Guide, but aren't really
software enforceable.

Goal #3 is a more general transactional problem; a wizard may be doing
arbitrary things (creating ZODB objects, SQL database tables, etc.)
but you don't want to leave half-created things lying around,
particularly if the user says "to hell with this" and just goes away,
leaving a dangling wizard session. I think this isn't practically
fixable until there's a canonical session tracking mechanism within
Zope. (Even then it may be impossible, but the session problem needs
to be fixed.)

--
A.M. Kuchling http://starship.python.net/crew/amk/
A pig can learn more tricks than a dog, but has too much sense to want to do
it.
-- Robertson Davies, _The Table Talk of Samuel Marchbanks_

At 06:05 PM 3/27/00 -0500, Andrew M. Kuchling wrote:
>Pretty good, though many of the issues are portal-specific ones. For
>example, the first one is "A user should be able to use a wizard to
>edit an object, as well as add one." But there can be wizard
>applications that don't create anything; imagine wizards that help you
>debug a problem by stepping through a bunch of screens, and doing a
>combination of automated tests and querying the user ("Did you receive
>an e-mail?").

The goals should be read to indicate what features the wizard
infrastructure should support: it would be up to the wizard author to
decide whether it's useful for their particular wizard to create and/or
edit zero or more objects...

Would it be useful for me to reword the summary to clarify this point?

>I'd drop goals #1, #6, #7 and the final two goals. #4
>and #5 would belong in a Wizard Style Guide, but aren't really
>software enforceable.

Let's see, "#4" for example is "The user should be able to enter things
like the title last". Again, the goal is that the infrastructure would
support entering core properties late in the process, if the wizard author
desired to do so. I believe this came out of noting that if, for example,
an Image object was to be created "in place" in order to receive a file
upload, the id would need to be specified first.

>Goal #3 is a more general transactional problem; a wizard may be doing
>arbitrary things (creating ZODB objects, SQL database tables, etc.)
>but you don't want to leave half-created things lying around,
>particularly if the user says "to hell with this" and just goes away,
>leaving a dangling wizard session. I think this isn't practically
>fixable until there's a canonical session tracking mechanism within
>Zope. (Even then it may be impossible, but the session problem needs
>to be fixed.)

My "Buildable" interface was one suggestion for a way to manage
half-created objects.

I suggest the wizard infrastructure be focused on additions and changes to
Zope objects and the ZODB: my sense this is hard enough, while being of
real value. Which is not to prevent a wizard author from dipping into the
full power of DTML, SQL methods, Zope products, XML-RPC, and Python to do
whatever they want, beyond the functionality provided by the wizard
infrastructure! :-)