[TransWarp] peak.web and forms
Phillip J. Eby
pje at telecommunity.com
Mon Aug 4 17:20:18 EDT 2003
At 09:49 PM 8/4/03 +0200, Roché Compaan wrote:
>Before I get to form generation it should be possible to build a
>BrowserView in pure python. A BrowserView is a collection of widgets
>with a binding to a model.Element. I don't want to call it a
>BrowserForm because it does not only render HTML forms - it can also
>render non-editable views
>A BrowserView introspects the element to supply its widgets with data.
>No layout or look and feel is set on a BrowserView - that is the
>responsibility of the template rendering the view. Templates will have
>access to a set of domlets that knows how to render a BrowserView, maybe
> <table domlet="browserview:foo">
> <tr define="widget">
> <th domlet="text:title">widget title</th>
> <td domlet="render">rendered widget</td>
Looks good so far. I presume that the BrowserView DOMlet will adapt its
subject to an IBrowserView interface, which will then supply an iterator
over a set of IWidgets? And each IWidget offers a title attribute, maybe a
help link, and some other attributes (e.g. validation messages)?
Of course, I can potentially see the need for alternate views of the same
record. It sounds like in such applications, one would want the UI
decorator to offer such views as attributes, e.g.:
asLineItem = WidgetSet(...blah...)
asEditForm = WidgetSet(...blah...)
security.allow(asLineItem = [security.Anybody],
Then a template could refer to a particular widget set, e.g.:
(Btw, I think BrowserView is too generic, and that RecordView might be a
more function-oriented description.)
If WidgetSets are implemented/implementable as Resources, the class above
could use 'bindResource()' instead of hardcoding the widget sets. This
would also make the widget sets overrideable in different skins.
>If a HTML form is submitted your app can call validate on the
>BrowserView with the request as parameter to validate all fields. The
>validated result can then be applied to the element the BrowserView is
Hm. I'd rather that the view simply assigned the fields to the underlying
object, one after the other, tracking any errors. After all fields were
set, calling an overall validate() method could be done on the object to
get any high-level issues.
>If there are validation errors your app can use them to
>re-render a template with appropriate error messages. At this point
>rendering a widget should show the input last provided by the user - ie.
>the form should be sticky.
>How does this sound?
Mostly good, but there are some pieces I'm having trouble wrapping my head
around, like where does the POST go to? What if there's more than one form
on the page? (These two questions overlap a bit, since if there's more
than one form, they can't both POST to the same place.) If you POST to the
widget set (a logical alternative), how do you get back to the template
that rendered the submitting page?
There are also some further-out-there issues stewing in my head, like if
and how to get that into the overall page layout... :)
More information about the PEAK