durusmail: quixote-users: So what _does_ the Quixote Form mechanics buy you?
So what _does_ the Quixote Form mechanics buy you?
So what _does_ the Quixote Form mechanics buy you?
2003-11-24
So what _does_ the Quixote Form mechanics buy you?
2003-11-24
So what _does_ the Quixote Form mechanics buy you?
2003-11-24
2003-11-24
So what _does_ the Quixote Form mechanics buy you?
2003-11-25
2003-12-05
So what _does_ the Quixote Form mechanics buy you?
Skip Montanaro
2003-11-24
    >> What are the benefits of me diving into the Quixote form handling
    >> stuff, in a nutshell?

    Nicola> The obvious ones: not having to do the same old validating and
    Nicola> rendering over and over. In a word, modularization.

In addition, you can subclass widgets to fairly easily provide alternate
behavior.  For example, on the Musi-Cal website, when submitting gigs, users
enter musicians in a StringWidget, but are supposed to enter multiple
musicians separated by forward slashes, e.g.:

    Andrew Kuchling/Neil Schemenauer/Greg Ward

This StringWidget subclass does the appropriate split to return them to me
as a list:

    class PerformersWidget(StringWidget):
        def parse(self, request):
            val = StringWidget.parse(self, request)
            if val is not None:
                # should try other secondary separators people use
                val = val.split("/")
            return val

I also use a mixin to allow me to easily specify different default values
(though I could probably just subclass StringWidget directly for each text
input type):

    class DefaultMixin:
        def __init__(self, name, default, *args, **kwds):
            self._base.__init__(self, name, *args, **kwds)
            self.set_default(default)

        def set_default(self, val):
            self.default = val

        def parse(self, request):
            val = self._base.parse(self, request)
            if val is None:
                return self.default
            else:
                return val

and then mix things together like so:

    class PerformersW(DefaultMixin, PerformersWidget):
        _base = PerformersWidget

(though I'd like to know a better way to convey the main base class to the
mixin than setting _base) and instantiate them like so:

    widgets['performers'] = PerformersW('performers', [], size=18)

For cities, I could (but don't yet) subclass StringWidget to define a parse
method that knows how to validate entered values with lat/longs and
associate common cities (e.g., "New York") with their state even if the user
didn't enter them.

What *I* would like to know how to do is to spit the form back to the user
if some validation step fails.  That is, I'd like to render the form again
with the values filled in, a message displayed identifying the problem, and
perhaps highlight erroneous values.

Skip

reply