[Web-SIG] Standalone WSGI form framework.

[Ben Bangert]

On Mar 16, 2006, at 9:33 AM, Alan Kennedy wrote:

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

I've also heard the term micro-framework used, though meta does seem  
more accurate in the sense that these parts can be used to build  
frameworks. However, not so accurate in that they aren't really used  
to build frameworks, as they're composed to actually "be" frameworks.

Regarding interfaces, as Ian mentioned, this was one desire in  
abstracting a fairly common Request wrapper on environ. To try and  
make it easier for hooks compatible with some of the interesting  
situations that occur with nested WSGI components, I made a piece of  
middleware I called the Registry:
http://svn.pythonpaste.org/Paste/trunk/paste/registry.py

I'm sure some people will hate it because it uses thread locals, but  
the usability it provides along with a way to expose points in a  
package make it easy to use for ad-hoc interfaces. For example, in  
the case of a Form component, one could say:
- Provide a session object that acts as a dict
- Provide a request object

The developer would merely drop into his code the Registry  
middleware, and register the session/request object with the Form  
library. All the form classes and functions would then have access to  
the proper objects during the request without the usability issues of  
having to try and pass those objects explicitly back and forth all  
over the place (in my experience, this becomes a huge hassle).

Some setuptools entry points that clearly indicate where the session/ 
request hooks to be plugged into could even automate the process  
entirely.

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

The next version of Pylons is going to have a bit more exposed WSGI  
path, which would make it easy to drop in other dispatch schemes if  
desired. As Ian mentioned, RhubarbTart is also doing something like  
this so that Routes can be dropped in. I won't be too surprised if  
the implementation end up using the same code and being rather  
identical. ;)

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

Yep, so if your WSGI app does its setup stuff as needed, then calls  
the dispatch and lets the flow go, a variety of mappings can be  
plugged in rather easily. However I'm sure there'll always be  
frameworks or setups incompatible with this flow so it might be  
better to just expose this section of logic to the web developer. If  
they want to plugin a different function to handle dispatch, they  
can, otherwise it goes with the frameworks default.

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

I think everything should work with the WSGI environ by default, and  
if it wants to wrap environ in a more convenient request object, it  
can do so easily enough. So in the case of this standalone WSGI form  
framework, hypothetically, I'd see it acting as middleware though I  
suppose stand-alone app would work as well. FormEncode does a pretty  
good job on several of these parts, and it'd be nice to have multi- 
page forms abstracted into middleware so I don't have to keep dealing  
with that myself.

I'd be interested in helping out on such a project if anyone wants to  
start one.

- Ben