Jeff Hinrichs - DM&T wrote ..
> On 11/19/06, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
> > I know that we are very close to getting mod_python 3.3 out the door,
> > and I know that it is me holding it up purely through the documentation
> > not yet being updated to at least give some basic details on new bits
> > in the rewritten module importer, but even at this late stage I have
> > been
> > thinking if we aren't with 3.3 missing a great opportunity to add a new
> > basic mod_python dispatch handler. After all, it may well be some time
> > before we get around to releasing the next version.
> >
> > On that basis, I have quickly thrown together a new dispatch handler
> > which I think could be included with mod_python. After seeing so many
> > people going off and writing their own dispatchers with varied success
> I
> > could see that including this would save a lot of mucking around for
> > people.
> >
> > I have attached the actual code for the handler module, but I'll explain
> > a few things about it as well.
> ...
> Is this based on your Vampire work?

The only thing it shares with Vampire at this point is the idea of using
resource based views and farming the handler requests off to distinct function
based on extension. For this bit at least, the dispatcher code is a lot lot
simpler than what is in Vampire, works in better with how Apache is supposed to
work and isn't reliant on some unique configuration mechanism. Although the
dispatcher code is much much simpler, it already does some things that Vampire
didn't allow, such as per resource versions of handlers for earlier phases such
a fixup handlers etc.

In other words, it draws on what I learnt from Vampire and from using Apache
since I wrote Vampire, but doesn't use any of the code from Vampire.

> If so,  does it handle extra path info like vampire?

That was what part of the examples I posted was about. By default the dispatcher
will reject requests where additional path information is provided beyond that
needed to identify the resource. This can be overridden for a whole directory
by using:

  AcceptPathInfo On

for selected resources by extension:

  <Files *.shtml>
  AcceptPathInfo On

or for specific resources using either configuration:

  <Files blog>
  AcceptPathInfo On

or by a fixup handler associated with the resource code file. Thus in
you would have:

  def fixuphandler(req):
    req.used_path_info = apache.AP_REQ_ACCEPT_PATH_INFO
    return apache.OK

  def handler(req):
    # process path info

In other words, it is using the standard facility within Apache for controlling
this, rather than coming up with some unique scheme of its own.

> Also, does it handle web services like vampire too?

No. If you look at the code you will see that there is hardly anything to it at
all. All it is intended to do is the dispatcher to a handler and nothing else.
Provided that people don't reject the idea, see this dispatcher though as a
first step of a plan down the track to get some generic handler components
incorporated into mod_python.

There could for example be presupplied handler components for such stuff
like publisher functionality and XML-RPC services. For example for a specific
resource where you want publisher like traversal of objects, you would use:

from mod_python.handlers import *

  class _Object:

    def __init__(self):
      self.value1 = "value1"

    def method1(self):
      return "method1()"

    def method2(self,req):
      req.content_type = "text/plain"

    def __call__(self):
      return "__call__()"

  _object = _Object()

  def fixuphandler(req):
    req.used_path_info = apache.AP_REQ_ACCEPT_PATH_INFO
    return apache.OK

  handler = MapPathToObject(_object)

I have a whole bunch of such handler components I have been working on
just waiting for mod_python to catch up and provide a basic dispatcher
which they could be used with. These components range from ones
mapping the path info to objects in the style of both publisher and basic
handlers, web services, plus mappers for Cheetah templates, plus stuff for
handling forms based login and session authentication and much more.

Anyway, looks like it will have to wait a bit longer. :-)


Reply via email to