[Twisted-web] Formless, custom form layout

Ian Bicking ianb at colorstudy.com
Thu Jun 30 12:55:55 MDT 2005


Valentino Volonghi aka Dialtone wrote:
> Rendering:
> - form object is remembered in the context as iforms.IForm
> - thanks to the adapter for the form object to IRenderer the form object    
>   is directly passed in a stan tag. The Form renderer will take care of 
>   rendering.
> - A new context is created. and the data from the old context is 
>   remembered on it (errors, data inserted and such).
> - The form is rendered in this way:
>   - the form object is iterated through for each field.
>   - each field is rendered, if there are errors they are looked up in 
>     iforms.IFormErrors (which was remembered at the beginning).
>   - the render method of the widget is called and it does the following  
>     thing:
>     - One of the converters is gathered from the adaptators and the 
>       python type is converted into a string.
>     - the result is set as value, the stan representing the widget is 
>       returned and sent to the client browser.

I don't understand all the aspects -- I don't know much about Nevow 
rendering -- but I think what you are describing is the traditional way 
form toolkits work, except perhaps that validation is better separated 
than in some cases.

I'm proposing that validation and form generation be *completely* 
seperate.  So you get several real data structures.  The validation 
produces something like this:

   {'field_name': 'field_value', ...}
   {'field_name': 'error_string', ...}

You can package that in an object or whatever, but that's the basic 
data.  Then the form generation produces:

   <input type="text" name="field_name">

Then a third component (like htmlfill) puts these two items together, 
but does so with no knowledge of how the data came into being.  And the 
actual logic for redisplaying forms and whatnot should be entirely 
seperate, because

Traditionally form toolkits generate HTML widgets with values and errors 
  already filled in.  This binds HTML generation to the validation 
process, which almost always falls apart eventually, because no one HTML 
generator is general enough (and the most general HTML generator -- an 
actual person writing HTML by hand -- should always be allowed for).

Maybe form is doing this, but at least it doesn't sound like it is.  But 
it does sound like it uses two-way conversion/validation, which I think 
is also a very important feature.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org



More information about the Twisted-web mailing list