John Siracusa writes:
> The details have been heavily simplified above, but that's the general idea.
> I'm not sure how this all fits into MVC, but it works very well for my
> purposes.
I think it fits very well into MVC. The flow you described is similar
to what we do in "pure" MVC.
To my mind the controller's job is to translate parameter formats and
to control flow. For example, the controller in bOP abstracts
multipart/form-data and www-url-encoded forms with a class which
returns the raw key/value data. If the basic HTTP protocol is not
observed, an exception is raised. Otherwise, it is up to the form to
validate the data.
One of the things we've worked hard on is understanding the
HTTP form abstraction. The first thing we noticed is that a form can
be treated like any other model. It has fields, types, and values.
We've boiled FormModel execution down to four modes:
empty - the user visits the form for the first time. You may want
to fill in default values.
validate_and_execute - the validation and execution phases are
separate. The basic field validation is performed by the base
class (FormModel) which asks the field types to parse the
data. The form itself cross validates the fields, and has the
opportunity to clear any errors found by the field validation.
other button - this might be cancel or "symbol lookup" or any
other nonstandard button. You can call validate_and_execute
or any other method (clear button might call execute_empty).
unwind - allows the form to handle any data returned from a "call"
to another form. It's like using the value from a subroutine
return.
By default, the form falls through on empty, unwind, and invalid data.
It can "redirect" through the use of exceptions. If
validate_and_execute leaves "errors" on the form (invalid data state),
it falls through to the view so the errors can be rendered.
All errors are bound to a form field and have a value (TypeError)
which has a default rendering, e.g. NULL renders as "you must supply a
value". The presentation layer can override the default string with a
value which is looked up based on the tuple (from, field, error) with
varying degrees of qualification. Without a TypeError abstraction,
the model doesn't give enough data to the view.
Rob
