Hi All

I am doing some work on a Quixote 2 application that we have running
internally.

I am writing some extra pages making use of the "Form" object. In terms
of handling the data, errors, submissions etc this seems to work quite
nicely but I don't like the look of pages I get when I use the
"render()" method.

So I have created a custom sub-class of Form and written my own methods
for _render_widgets and _render_submit_widgets. So far so good.

Next I have sub-classed the "add" method as it classifies a "reset"
widget as a normal widget and not a "submit widget". Which means it gets
put with the input fields at the top of the form and not with the
buttons at the bottom. Perhaps this could be regarded as a bug.

But now I don't like the way that "widget.render()" displays the
buttons. So the next step is to subclass "ButtonWidget" and write my own
customized version of "render()" for these widgets. SubmitWidget and
ResetWidget are subclasses of ButtonWidget, so I have to write custom
class definitions for those two using my custom ButtonWidget as their
base class.

But this is when things start to get ugly. The code in "form.py"
contains direct imports for ResetWidget and SubmitWidget which picks up
the original versions of these classes. So now it looks like I have to
create my own customized copy of "form.py".

I am not too sure how far to go down this road. It maybe easier to
create a local copy of the whole "quixote/form" subdirectory and
customize it as required. This would break the whole concept of classes
and sub-classes as if there is ever any change in the upstream code it
will pass this application by.


What is the most elegant "pythonic" way out of this dilemma?

Is there any active development being done on Quixote which might result
in future changes to the Form object?

Has anybody used the "Form" object from quixote2 for anything except the
basic pages, if so how did you go about it?

What other techniques have readers used for generating pretty forms with
lots of input fields?


Thanks


Ian