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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
