[TransWarp] peak.web and forms

[Phillip J. Eby]

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
>something like:
>
>     <table domlet="browserview:foo">
>     <tr define="widget">
>     <th domlet="text:title">widget title</th>
>     <td domlet="render">rendered widget</td>
>     </tr>
>     </table>

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.:

class ContactView(web.Decorator):

     protocols.advise(
         instancesProvide=[IWebTraversable],
         asAdapterForTypes=[MyContactClass],
         factoryMethod='asTraversableFor'
     )

     asLineItem = WidgetSet(...blah...)
     asEditForm = WidgetSet(...blah...)
     security.allow(asLineItem = [security.Anybody], 
asEditForm=[contacts.Manage])

Then a template could refer to a particular widget set, e.g.:

<table domlet="recordView:asEditForm">
...etc.

(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
>bounded to.

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 
you want to use JavaScript to pop-up help windows or perform validation, 
and how to get that into the overall page layout...  :)