Hello, On May 26, 4:52 pm, Ivan Sagalaev <man...@softwaremaniacs.org> wrote: > Could you please give a concise technical overview, in high-level terms, > on what twod.wsgi actually does to Django code?
Sure. There are different components, so I'll elaborate on them individually: Paste Deploy application factory instead of `manage runserver' -------------------------------------------------------------- The problem with running the application in development mode is that there's no way to add WSGI middleware, it's like Django assumes that you'd only need WSGI middleware on deployment. Therefore I think we should either adopt Paste Script's development server (which makes your app behave like it'd do under mod_wsgi, for example; with no Django-specific magic) or implement a development server that serves the WSGI application you give it (which could be wrapped around WSGI middleware, or it could not even be a Django application). I'd prefer sticking to Paste Script's server because it's multi- threaded and we could *optionally* use Paste Deploy configuration files, instead of Python files for configuration: http://packages.python.org/twod.wsgi/manual/paste-factory.html (And one of the advantages of using INI files for configuration instead of Python code is that it's a lot easier to extend: http://packages.python.org/twod.wsgi/manual/paste-factory.html#multiple-configuration-files) Better request objects ---------------------- There are two problems with Django's request objects from a WSGI point of view: - It copies the WSGI environment variables. That makes interoperability with WSGI libraries harder or not possible at all, because the request can be changed but the WSGI environ wouldn't be modified, and vice versa, if the WSGI environ is modified the request wouldn't be updated. - It doesn't expose an API to handle most of the properties of a request -- only the most common ones. WebOb's request object is a better proxy of the WSGI environ from my point of view, which is why I think Django's request object should extend it. It doesn't have the problems above and it has more features: http://packages.python.org/twod.wsgi/manual/request-objects.html I've managed to sub-class both WebOb.Request and Django's HttpRequest without breaking backwards compatibility. Embedded WSGI applications -------------------------- At present there's no built-in mechanism to run WSGI applications from Django. Doing so could be extremely powerful and useful in some situations, because it gives you the ability to filter the request another application receives, and the response it returns -- Using request and response objects, respectively. And by "WSGI" application, I mean pretty much *any* Web application. Java applications, PHP applications, a Web site like www.google.com. Anything, thanks to 3rd party WSGI applications that can run CGI scripts and proxies, for example: http://pythonpaste.org/modules/cgiapp.html#paste.cgiapp.CGIApplication http://pythonpaste.org/modules/proxy.html#paste.proxy.Proxy So, if you have, say, a Trac instance running on your Web site, you can make it use Django's authentication data for the current user, and authenticate users with your own Django-powered login form, and log users out from Django, and many other things. Check this sample Django application that implements a Single Sign-On mechanism with Trac: http://bitbucket.org/Gustavo/weesgo/ URL routing arguments support ----------------------------- >From the manual <http://packages.python.org/twod.wsgi/manual/routing- args.html>: "routing_args is an extension to the WSGI standard which normalises the place to put the arguments found in the URL. This is particularly useful for 3rd party WSGI libraries and the dispatching components in Web frameworks are expected to set it, but Django does not: Therefore we created the RoutingArgsMiddleware Django middleware. If you requested the path /blog/posts/hello-world/comments/3, then the arguments hello-world and 3 will be available in the request object. Depending on how you defined your URL patterns, they’ll be a dictionary (if you used named groups) or a tuple (if you didn’t set names for the matching groups). The former are referred to as “named arguments” and the later as “positional arguments” in routing_args specification. RoutingArgsMiddleware simply puts the arguments found by the Django URL resolver in the request object. It’s such a simple thing, but it’s key for Django-independent libraries, which may not be run in the context of a Django middleware nor a Django view." Serving static files (aka "media") ---------------------------------- Letting a WSGI application serve static files on development servers is better because it's faster (given that Django won't get run) and more importantly, Django doesn't serve the media on deployment after all. See: http://packages.python.org/twod.wsgi/manual/media-apps.html That's it, AFAIR. Please let me know what you think. Cheers, PS: Trust me, that's just the tip of the iceberg ;-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
