[Zope3-dev] Schema, widget and form refactoring (was Re: [Zope3-checkins]CVS:Zope3/src/zope/schema- _bootstrapfields.py:1.19.2.1)

[Stuart Bishop]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Thursday, July 24, 2003, at 04:49  AM, Shane Hathaway wrote:

> Request 1: User starts the wizard
>   - Zope locates or creates the form for page 1
>   - Zope asks the form to render itself to HTTP
>   - The form renders its widgets, looking in the session for
>     previously entered values (which it won't find)
> Request 2: User submits page 1, clicking "Next"
>   - Zope locates or creates the form for page 1
>   - Zope asks the form to validate
>   - The form gets the schema
>   - The form looks over the HTTP request, validating only
>     the fields present on the form
>   - The form indicates success
>   - Zope asks the form to store the field values in the session
>   - The form stores the field values
>   - Zope asks the browser to visit page 2
> Request 3: Browser requests page 2
>   - Zope locates or creates the form for page 2
>   ... etc ...
>
> The wizard is a form containing forms.  Forms know a lot about HTML 
> and HTTP.  The forms might draw from GUI-agnostic WidgetLayout 
> objects.  At the end of the wizard, you can validate against the 
> entire schema.  Now, is that how it works, or am I a little off?

Pretty close. They have two modes to pass state (hidden fields and 
session).
Only the hidden fields method is implemented, as sessions don't yet 
exist
in Z3. Apart from extra network traffic, the drawback to using hidden 
fields
is that file upload widgets won't work. use_session is the default
(even though it currently raises a NotImplementedError).

I think of a wizard as a single form made up of multiple panes.
The wizard simply renders the next pane if the submitted pane is
valid (so no redirects required).

Rendering is done in the same way that addform/editform does it
(using Widget.row()).

The entire schema is actually being validated at every step - the
Submit button only appears if every pane except the current one
is fully valid (so a user can backtrack over the wizard panes to review
stuff, and don't have to navigate to the end again to commit).
This also means you also can get a submit button without traversing
the entire wizard if the fields on all later panes have valid default
values. This behavior is good, as it is a requirement for applications
I'm writing :-)

The default behavior should remain the default. There is a strong
argument for allowing the 'Previous' button to jump to the previous
pane even if the current pane is not valid, which could be done by
adding an option to the ZCML rather. Some people may insist that
the submit button should only appear once the end of the wizard has
been reached, which could also become an option.

It is also worth noting that the single page add and edit forms could
be tossed out and emulated with the wizard code, as a wizard with a 
single
pane behaves identically to the original schema generated forms. It
is just done with more confusing code :-)

- -- 
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE/H0uEh8iUz1x5geARArYmAKDwdNr8lk/99+TjTz+yvPoKhYl6oQCgv35W
D+we0j7uJr5ZJxNSavxzYfQ=
=tb4F
-----END PGP SIGNATURE-----