At 02:12 PM 7/24/2005 -0500, Ian Bicking wrote: >Phillip J. Eby wrote: >>However, after more thought, I think that the "next application" argument >>should be a keyword argument too, like 'wsgi_next' or some such. This >>would allow a factory to have required arguments in its signature, e.g.: >> def some_factory(required_arg_x, required_arg_y, optional_arg="foo", >> ....): >> ... >>The problem with my original idea to have the "next app" be a positional >>argument is that it would prevent non-middleware applications from having >>any required arguments. > >I think it's fine to declare the next_app keyword argument as special, and >promise (by convention) to always pass it in with that name.
Actually, now that we have the "entry points" capability in pkg_resources (I just checked it in), we could simply have middleware components looked up in 'wsgi.middleware_factories' and applications looked up in 'wsgi.application_factories'. If a factory can be used for both, you can always list it in both places. Entry points have 1001 uses... I can imagine applications defining entry point groups for URL namespaces. For example, Trac has URLs like /changesets and /roadmap, and these could be defined via a trac.navigation entry point group, e.g.: [trac.navigation] changesets = some.module:foo roadmap = other.module:bar And then people could easily create plugin projects that add additional navigation components. (Trac already has an internal extension point system to do things rather like this, but entry points are automatically discoverable without any prior knowledge of what modules to import.) There are other frameworks out there (e.g. PyBlosxom), both web and non-web, that could really do nicely with having a standard way to do this kind of thing, rather than having to roll their own. _______________________________________________ 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