[mod_python] mod_python.publisher and PythonHandler

On Tue, May 14, 2002 at 10:13:13PM -0700, Jason Morgan wrote:
> Hello:
> 
> Ok, please excuse my ignorance, but I'm trying to move three sites 
> over to mod_python from php and I'm having some trouble figuring what 
> is the 'proper' way to proceed. I have mod_python installed and 
> working, however, I'm not familiar with the handler concept (yes, I 
> RTFM) and am trying to decide what to do with it. Should I have 
> handler dealing with everything in my dirs, while passing off content 
> generation to methods within personal modules? What is the role of 
> mod_python.publisher. I would appreciate any help I can get - URLs 
> are welcome. I've done the google searches, though, and haven't come 
> across anytrhing about how people actually structure their sites. I 
> dont' just want to hack something together - as I plan to leave most 
> site maintenance to a new employee
> :-).

Well, I'm not sure how closely my experiences mirror those of other 
mod_python developers, but I can try to give you some insight. (I spent 
about two years writing almost exclusively in PHP, and am now adjusting 
to mod_python)

The handler concept is by far the biggest difference between the two 
environments. A PHP script typically resides 'at' a specific URL, and 
only services requests for that URL. A mod_python handler, in contrast, 
becomes part of the web server, and handles requests whenever Apache 
gives them to it.

To be a little clearer, the way I will usually install a handler is to 
include it within an Apache <Location> directive. For example, I am 
writing a user-management module, and I want it to be mounted at 
http://mysite.com/users, so I set up Apache like this:

  <Location /users>
    SetHandler python-program
    PythonPath "sys.path+['/usr/local/lib/site_apps']"
    PythonHandler userinfo
  </Location>

This means that now my python module (at 
/usr/local/lib/site_apps/userinfo.py) is responsible for *every* 
request to a URL which begins with "/users". 

The first thing that userinfo.py does is analyse the URL of the request 
to see exactly what was requested. If it is just "/users/", it displays 
a list of users. If it is "/users/showuser/ian", then it looks up the 
user record for 'ian' and displays that record. If it is 
"/users/no-such-page" then it returns apache.DECLINED, and Apache 
handles the 404 error.

I can also distinguish between GET and POST requests by examining the 
req.method variable. If the request is a GET to 
"/users/deleteuser/ian", then userinfo.py will display a confirmation 
page. If it is a POST to that same URL, it will read the POST data, 
look for a confirmation, and delete the user.

Most of my handlers are designed in this fashion, as one main python 
module installed under a base URL, which defines a "URL-space". The 
main module uses import statements to access all of the libraries it 
needs (database access, user record class, string, cgi, etc.) to do its
work.


If you want to look for other resources on application design with 
mod_python, try searching for information on mod_perl. It's the closest 
thing I have found to mod_python, as they both act as scripting-
language interfaces to the Apache C API. O'Reilly's book "Writing 
Apache Modules with Perl and C" has been an invaluable resource for me. 
Also, once you understand how the Apache API works, the mod_python 
documentation becomes a much more useful tool.


If your goal is just to convert your applications from PHP to the 
Python language, then you may want to look at the Publisher handler 
which Grisha has supplied with mod_python. It allows you to use Python 
scripts in a very similar fashion to PHP or CGI scripts, and a lot of 
people on this list seem to be using it exclusively. In that case, the 
publisher handler becomes the default handler for your entire site. It 
deals with every request that comes in by looking for a Python module 
with the appropriate name in the right directory, and passing it 
parameters based on the request. (This is actually completely backwards 
to the way PHP works, but the effect is the same -- you believe that 
you are calling the Python script directly from the URL.)


I hope this answers at least some of your questions; feel free to ask 
more if I've just made things more confusing :)


Ian
<ian at veryfresh.com>