[Web-SIG] Standalone WSGI form framework.

[Alan Kennedy]

[Alan Kennedy]
> I'm looking for a framework-independent form library. I'm using the
> Quixote forms library at the moment, inside my own framework, but
> would ideally like something more WSGI oriented, so that it is easier
> to mock and unittest.

[Daniel Miller]
> Have you looked at Ian Bicking's FormEncode? I'm not sure if it
> meets all your requirements, but it seems like a good base to start
> with (most of the hard stuff has already been done).

Thanks Daniel.

Indeed, it not only appears that FormEncode is the closest thing to
what I need, it also seems to be the only show in town, i.e. the only
framework-independent form library.

[Alan Kennedy]
> If anyone is familiar with the Java Spring Framework, it's got pretty
> much everything I need, but is overly complex, and is written in Java

[Daniel Miller]
> I wrote an app using Spring and I have to say it's the best web
> framework I've ever used in terms of completeness and flexibility,
> but it's written in Java...

Agreed. I find it's interface based design very simple and powerful.
But, IMHO, the actual implementations of the classes that implement
the interfaces are excessively complex and rigidly structured.

[Daniel Miller]
> I actually wrote a few simple classes on top of CherryPy that exposes
> the Spring webmvc Controller interface as well as the
> SimpleFormController class (those are the two main building blocks
> I found most useful in Spring's WebMVC). My SimpleFormController
> implementation uses FormEncode for validation. I'd be willing to
> share the code if you're interested.

I'd be very interested to see that, and potentially use it, if you're
willing ...

[Daniel Miller]
> I think "the one true web framework" could be made for Python if
> someone took the best ideas from Spring WebMVC and made a few
> component-ized building blocks on top of which complex and widely
> varied applications could be built.

Completely agreed. The term "meta-framework" is most appropriate, I
think. If we could agree on a set of interfaces, then everyone would
be free to contribute implementations of their own componments.

For example, I like the idea of Routes URL-mapping library: it's
precisely the kind of task that is simple enough in concept, but yet
complex enough to require a dedicated (and thoroughly tested) library.

Most of the popular web frameworks make the fundamental mistake of
picking a single URL->object mapping mechanism, and making you
shoehorn all your requirements into it. IIRC, Django, Turbogears,
Pylons, all make this mistake.

However, if URL->object mapping were controlled by an interface, then
we'd be free to choose from multiple implementations, e.g.
routes-style, quixote-style, zope-style, etc, etc.

> However, to make this possible we'd most likely need a standard
> request object (or at least an interface definition).

ISTM that WSGI eliminates the need for that. Is there any specific
thing you have in mind that WSGI doesn't cover?

Regards,

Alan.