durusmail: quixote-users: form2: troubles from a get
form2: troubles from a get
2004-02-24
2004-03-10
2004-03-10
2004-03-10
2004-03-10
form2: troubles from a get
Neil Schemenauer
2004-03-10
On Wed, Mar 10, 2004 at 04:14:05PM -0500, Daniel Chudnov wrote:
> I'm rather partial to form2 so I've developed a fair amount of
> code based on its current incarnation. ;)  Understanding, of
> course, that it's alpha, and being prepared to rewrite as
> needed...  it would be helpful to know which deficiencies you are
> particularly concerned about.

I'll try.

  * form2 is trying to be flexible and allow users of the library
    to have some control over how forms are rendered.  However, it
    doesn't work very well with the current design.  I think is
    should be possible to override formating in a consistent way by
    subclassing Form, overriding some methods, and using that
    subclass in your application.

  * The Component class adds a fair about of complexity and I don't
    think it's actually necessary.  Widget could have both render()
    and render_row() methods.  The form would call render_row().  If
    you wanted to build a multi-row widget you could subclass from
    Widget, create subwidgets, override render_row() to make it call
    subwidget render() methods.

  * Sometimes it's really convenient to raise FormValueError when
    parsing widget data.  Widget should catch FormValueError and set
    self.error.

  * You should be able to control the behavior of is_submitted().  I
    think the best way is if Widgets can have a reference to the
    form and call the Form.is_submitted() method.

That's all I can think of right now.  If you don't mess with
Component objects then perhaps the visible changes will not be
extensive.  Hopefully. :-)

  Neil


reply