[Web-SIG] Python Web Modules - Version 0.4.1

[James Gardner]

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