[Web-SIG] Python Web Modules - Version 0.4.1
James Gardner
james at pythonweb.org
Tue Oct 5 01:07:04 CEST 2004
Thanks for the comments, much appreciated. I'm afraid I've got some more
questions though :-)
> Now with WSGI, have you thought about refactoring some of these with
> that in mind? Some of these are really WSGI-neutral libraries, but
> others aren't.
>
> The obvious place to start would be a WSGI backend. It doesn't seem
> like Python Web Modules model will work well in a non-CGI environment.
> Not only does it seem to put everything in the global space (e.g.,
> web.cgi), making it difficult to run in threaded environments, but all
> the examples run the request at the top level of the module, so that
> you have to reload the module to serve a second request. This will
> paint you into a corner, as the API will be resistent to any other
> environments.
Agreed, the modules are fairly CGI-orientated.. and none of the examples
show anything clever going on.. but I am keen to refactor them and think
they could be easily modified.. even thought I might need some advice! I
also think the web modules and the WSGI might make a good fit and there
would be no harm in writing the necessary glue so that they could be
used in both environments. I am also going to look into how hard it
would be getting them working with jython.
I'm just trying to get my head around the best way of doing things.. My
understanding is this: the server is constantly running and calls both
the application and any encompassing middleware every time a request is
made. This means that for each request the middleware and the
application are executed for the request. Consequently there is no speed
advantage in moving code from the application to the middleware. The
only advantage is that it makes certain bits of code more reusable for
other applications.
I can see how the web.database structure or cursor can be moved to the
server and passed as environ['web.database.cursor'] and
environ['web.database.structure'] objects. (btw it is legal to put
objects in the environ dictionary isn't it or are the values expected to
be strings?) but surely there would be no advantage to moving things
like the web.cgi object away from the application global namespace
because it would have to be reloaded on each request anyway so it might
as well exist in the application's global space mightn't it? I guess
what I'm asking is: for items that have to be refreshed every request is
there a lot to be gained by moving them away from the application's
global namespcae?
Could you possibly be more specific about which areas of the modules you
think wouldn't work well with threading and why they wouldn't? I don't
expect you've studied the modules too closely but I'm not sure I
understand where the difficulties might lie?
>> Key features include:
>>
>> * web.auth - Identity and identification handling. Users may have
>> multiple access levels to multiple applications. Sign in and
>> password reminder handling is built in.
>
>
>
> This could be middleware, though obviously it requires a lot of user
> configuration. If it's middleware you could share a single
> authentication system with different WSGI applications. Some
> standardization in this case would be good -- starting with things as
> simple as environ['auth.username'] holding the string username. But
> for now there's no standard, so you should use a custom prefix.
Yes, I guess the auth and session modules could be middleware and I am
writing an application to handle the sign in and sign out so that
wouldn't need to be included in the middleware, just the current auth
status of the user and the access levels making the middleware thinner.
>> * web.session - Persistence using cookie or URL based session IDs
>> allowing any object which can be pickled to be stored using a
>> dictionary- like interface. Can be used with file or database drivers..
>
>
> This would be good as a WSGI middleware. I have such a middleware at
> svn://colorstudy.com/trunk/WSGI/session.py , but the actual
> persistence and configuration is minimal. But it might be helpful for
> thinking about how it might look as middleware.
I downloaded and ran your code earlier today and had a look.. certainly
helpful.. thank you.
>> * web.error - Enhanced error handling based on the principles of
>> the cgitb module. Plain text or HTML output to a file or browser.
>> Custom extension mechanism for email notifications and more.
>
>
> This could also be a piece of middleware. I feel like it's one of the
> more complicated kinds of middleware, but useful. It could also be a
> bit of library code that applications can use, but I'd prefer it as
> middleware because you could configure it for multiple applications.
I quite like this as middleware too, but again it could go in the
server.. how do you decide? I also find that all pages have similar
regions like title, breadcrumbs, navigation bar, content.. I was
planning on having some sort of templating middleware so that
applications didn't have to worry so much about the broad page structure
allowing easy theming of sites.
At the moment I'm think of refactoring as follows:
WSGI - Server: web.database
web.database.object
any global config options
- Middleware: web.auth
web.session
web.error
theming engine
- Application: Sign in, sign out, change password,
password reminder, change access levels etc
- Library: web.mail
web.image.graph
web.template
Does this sound like a sensible architecture to go with?
Again any thoughts would be appreciated.
Cheers then,
James
--
James Gardner
james 'at' pythonweb.org
http://www.pythonweb.org
More information about the Web-SIG
mailing list