Webware for Python

On Sep 18, 2006, at 1:43 PM, Dan Milstein wrote:

> So: I was having problems with large file uploads in my dev
> environment (OS X 10.4, Apache 2), and not in my production
> environment (Linux something, Apache 2).
>
> I have a bit more story, and I've resolved the problem.  Here's the
> scoop, if you're interested:
>
>   - I upgraded my apache install from 2.0.52 to 2.0.55 (using fink),
> and the problem went away
>
> No idea what random bug was fixed in apache which made this so, but
> things are working now.

Even with the remaining mystery, that makes for a happy Monday, eh?

  - Mark

Dan Milstein wrote:
> I've added java servlet-style filters to Webware, and would like to 
> contribute the code to the project, if people are interested.
> ...
> If people are interested, I can write up some documentation.

That's surely interesting, thanks.

I'll have a look at it and I'd also like to hear feedback from others; 
maybe we can include it with 0.9.3.  For 0.9.2 it's unfortunately too 
late, I don't want to defer it again.

Instead of only documentation, it would be nice to have some usage 
examples too, maybe a tutorial on building a small application using 
these and other Webware features.

-- Chris

Chris,

Thanks for the quick response -- I didn't expect to go in 0.9.2 -- no  
worries about that.

Two things:

  1) I *did* screw up the tabs/spaces in one of the files -  
FilterChain.py.

I've attached a fixed version.  Sorry.  I've got Emacs set up to use  
spaces by default, and going back and forth is, um, tricky.  Here's  
hoping (but not expecting) that this is the last such mistake.


  2) Attached is the start of a tutorial/how-to style doc on using  
filters

I'm attaching it in rough form to a) give a teaser for folks on this  
list who want to try filters out, and b) get feedback on whether or  
not this is a useful kind of doc.  I'll keep working on this one, but  
if people are feeling like it's too simple, or would work better as  
part of a general Webware tutorial, let me know.

-Dan

I like the idea of these filters, and I can definitely see how they 
could be useful. Having only looked at your examples and the doc you 
provided, though, I do have a couple of questions/suggestions.

One, according to the documentation, you set up filters in 
Application.config. Would it be possible to use them in a per-servlet 
way? In other words, instead of setting the filters per instance in the 
config file, could I define a filter chain in the __init__ or awake() of 
an application's base class (some SitePage)?

Two, although I'm sure I could figure it out by actually using the 
filters, you documentation does not quite tie all of the pieces together 
for me. For example, the first thing I though of when reading "The Code" 
section is "Where does the import go?" Where do I import the 
AuthorizerFilter that you set up in the config? I'd like to see a 
complete (but simple) example. I know that the docs are only 
preliminary, but that's my $.02USD.

All-in-all, though, good job. It looks like a really handy tool to have.

--John
>
>
>  2) Attached is the start of a tutorial/how-to style doc on using filters
>
> I'm attaching it in rough form to a) give a teaser for folks on this 
> list who want to try filters out, and b) get feedback on whether or 
> not this is a useful kind of doc.  I'll keep working on this one, but 
> if people are feeling like it's too simple, or would work better as 
> part of a general Webware tutorial, let me know.
>
> -Dan

Thanks much for the response.  Questions:

> One, according to the documentation, you set up filters in
> Application.config. Would it be possible to use them in a per-servlet
> way? In other words, instead of setting the filters per instance in  
> the
> config file, could I define a filter chain in the __init__ or awake 
> () of
> an application's base class (some SitePage)?

I'm not sure if I fully understand this (and I'd like to).  What  
would it mean for them to be per-servlet?  Would that mean that the  
chain could depend on which servlet was actually called, rather than  
on which filters matched the URL?

One of the strengths of the way it works now is it's actually  
important/useful to define behavior on the pattern of the URL.   
That's sort of the big win.

Or am I misunderstanding?  Could you talk out how you'd imagine using  
it in a per-servlet manner?


> Two, although I'm sure I could figure it out by actually using the
> filters, you documentation does not quite tie all of the pieces  
> together
> for me. For example, the first thing I though of when reading "The  
> Code"
> section is "Where does the import go?" Where do I import the
> AuthorizerFilter that you set up in the config? I'd like to see a
> complete (but simple) example. I know that the docs are only
> preliminary, but that's my $.02USD.

Very helpful.  Thanks.  I'll take a pass at writing a small, complete  
application.

In answer to your question: you don't ever have to import  
AuthorizerFilter -- Webware does so for you (so to speak) when it  
builds a chain which needs it.  Your servlet code doesn't import or  
interact with the filter code directly.  A filter can communicate  
with/influence servlet code, but only via the web data: a filter can  
modify the data in the request, or change the path, or store things  
in the session, or, if it wanted to do something really devious,  
could replace response/request objects in the transaction  
altogether.  You could look at it as -- the filter can help set up  
the environment in which the servlet then executes.

I'll try to make this all clearer in the docs.

Thanks again -- very useful feedback.

-Dan

In my initial excitement of the idea, I got a little ahead of myself. I 
see where you are coming from now, and why you define the filters in the 
config file. The big problem with putting a filter in a sevlet is that 
that same servlet might not have been accessed based on it's own filter. 
But the filter wouldn't have been called if you never loaded the 
servlet. Catch-22.

However, I do think that there is value in being able to define a filter 
per-servlet. By this I mean that each sevlet could define behavior on 
it's own based on the path so far, with filters defined in 
Application.config serving as a default. Also, the filters could be 
processed down through the inheritance hierarchy. So the SitePage's 
filters would fire, then the MiddlePage's, and finally, assuming the 
filters allowed the request to get this far, the ChildPage's filter 
would be processed. But if I want that, maybe I should just use CherryPy 
;-). They have (IMHO) a nice URL parsing system that seems very similar 
to this (at least functionally).

I still like the idea of these filters in Webware (even if it's not 
"per-servlet").

--John
> I'm not sure if I fully understand this (and I'd like to).  What  
> would it mean for them to be per-servlet?  Would that mean that the  
> chain could depend on which servlet was actually called, rather than  
> on which filters matched the URL?
>
> One of the strengths of the way it works now is it's actually  
> important/useful to define behavior on the pattern of the URL.   
> That's sort of the big win.
>
> Or am I misunderstanding?  Could you talk out how you'd imagine using  
> it in a per-servlet manner?
>

Thanks for wanting to share your contributions, Dan.

 > Got the trunk checked out of svn, but when I then ran install.py, it
 > modified all the docs and configs, which is confusing the heck out of
 > svn (svn status gives a host of !'s and M's).

The installer creates html files from phtml files by adding headers, 
footers etc. and then deletes the phtml files which is the cause of the 
!'s. If you want to keep the templates, then run install.py with the 
--keep-templates option.

Besides that, the installer also adds header and footer to a few html 
files created from ReST documents and modifies the Application.config 
files. When doing development, you should revert these changes after 
running install.py if you find that confusing.

The ReleaseProcedures document explains how to create the html files 
from the ReST documents.

You may also want to have a look at the StyleGuidelines document.

In the long run, it would probably a good idea to support easy_install 
instead of the Webware installer, but that is a bit of work because if 
you want to do it right, you must probably replace the whole Webware 
specific plug-in mechanism by conventional package installation (Chuck, 
what do you think about that?).

By the way, this leads me to a general question: What is the standard 
way and location for installing documentation for Python packages? I 
have the impression that installing documentation is a neglected issue 
in DistUtils and EasyInstall, or am I missing something?

-- Christoph