durusmail: quixote-users: Customization of Quixote2 "Form" appearence
Customization of Quixote2 "Form" appearence
2008-04-04
2008-04-04
2008-04-06
2008-04-06
Re: Customization of Quixote2 "Form" appearence
2008-04-05
2008-04-05
2008-04-07
Customization of Quixote2 "Form" appearence
Binger David
2008-04-04
On Apr 4, 2008, at 8:29 AM, Ian Forbes wrote:
>
> 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.

I see what you mean.

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

Here are some possibilities.

Is there something preventing your Form subclass from overriding the
Form methods that use these direct imports?

If you are feeling violent, you could just assign your substitute
Widget classes into the form and widget modules.

Alternatively, you could change your custom "add()" method to
change the class of any SubmitWidget to MySubmitWidget (and similarly
for ResetWidget) as it is added to the Form instance.

>
> 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?

I think I should point out that the QP package uses Forms with
code derived from Quixote.  Big changes to Form rendering in QP
are unlikely, though, since we've had a long time to make sure
that it meets our needs.  We use it for a large number and variety
of Forms.  When we need special rendering, we usually manage to
do it with css changes.

>
> 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?
>
reply