The Webware portion of this remains fairly minimal, mostly some simple classes that translate the WSGI environment and general system to the Webware API.
In the process, I've made some reusable middleware that is Webware-neutral, but implements some of Webware's functionality (and I layer them in roughly this order):
* httpexceptions; catches particular exceptions and turns them into HTTP responses (e.g., HTTPMovedPermanently, HTTPNotFound, etc). In a way I wish this was standard. However, the other middleware doesn't use this (though some of my Webware code does).
* recursive; allows applications to forward to other URLs and to make recursive calls to include other URLs. These URLs have to be under the location where recursive is used.
* session; implements sessions. The persistence is simple and doesn't take concurrency into account (yet), but the basic structure seems correct to me.
* urlparser; this takes a URL and finds an application based on it. Currently it looks in a single directory, parses out the next part, and finds the application associated. Subdirectories turn into other urlparser instances. Finds .py modules, and looks for "application" (which is a ready-made application), or module.module_name, where the object must be called before it is ready to act as an application (in Webware's case, this is a class, instances of which are WSGI applications). Also serves up static files, like .css, .html, etc.
* wsgilib; a number of generic functions for use with WSGI. Right now this includes:
* Cookie parser: get_cookies
* Something to add a finalizing function to an iterator: add_close
* A way to run a request in a fake environment, for interactive
debugging and testing: interactive* An error response creator (for 404 messages, etc): error_response
* An application-builder for on-disk files: send_file
I still need to do more testing, and write some unit tests for these middleware. But progress has gone well, and implementing a real-world framework on WSGI seems very doable. This is a more aggressive use of WSGI than many framework ports may make; a simpler porting technique would be to take the whole framework and find a single entry point, letting the framework keep all its URL parsing and other code. I'm doing this refactoring in part because I think it's the right direction for Webware, moreso than it's the best or easiest way to port a framework.
Comments and suggestions welcome. The code is located at svn://colorstudy.com/trunk/WSGI
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
