[mod_python] Re: Photo Album Viewer and req.path_into.

Shawn Harrison wrote ..
> > Not knowing for sure what you are wanting to do, I am going to assume
> that
> > you want to wrap image files in a HTML page automatically.
> 
> Yes, that's the idea, although I only gave photos as an example: What I
> really mean is this:
> * If my document root is /web/examplecom/www/, and
> * I have a request handler at /web/example/www/photos/index.py, and
> * the photos are in /web/example/www/photos/
> * Vampire is the PythonHandler, and
> * req.uri is /photos/2004/10/01/137, then
> ? will the handler in /photos/index.py pick up the request?

If you expect the files/paths/URLs to be named exactly as you state,
then for the currently available version of Vampire, the short answer
is "No".

Long ramble follows about it. This may or may not be of interest but
is helpful for me to do so as to explore the issues myself. The
information may be useful to someone, so why not on the mailing
list. :-)

Vampire supports virtual directories, but not a virtual directory which
completely and transparently overlays a physical directory. Ie., where
a request for a resource gets bumped through the virtual directory
handler if there isn't a physical resource which corresponds to the
request.

As described in my previous email, the closest you will get is to have
the virtual directory which overlays the physical directory be a 
distinct sub node of the physical directory (or as a distinct path in
itself).

That is:

  /photos/browse.py #virtual directory handler in file system

  /photos/2004/10/01/137.jpg # physical file access URL
  /photos/browse/2004/10/01/137 # virtual resource access

Having said this, it doesn't mean that Vampire couldn't support what
you want, as I can see how it could be enhanced to allow exactly what
you want. Some explanations of how Vampire does some things are
in order here. Its assumed that Apache 2.0 being used, as Apache 1.3
screws up things because it does some things wrongly, but they were
fixed in Apache 2.0.

First off if you have "/photos/index.py" and it contains "handler_html()",
the URL "/photos/index.html" will resolve to that handler. By default
though, accessing "/photos" will yield "Not Found".

This is because the Apache DirectoryIndex directive doesn't extend
into the URL namespace where Vampire is used. To support this though,
Vampire supports saying:

  PythonOption VampireDirectoryIndex index.html

Now if you access "/photos" it will resolve as if the request had been
for "/photos/index.html".

Next thing to explain is virtual directories. These are implemented by
having a code file, for example "/photos/browse.py", which contains a
"handler()" method.

If a request such as "/photos/browse/2004/10/01/137" occurs, the
handler is called, with "req.path_info" set to "/2004/10/01/137".
The handler can then decide as to what to do with it.

For this to work though, there cannot also be a subdirectory in existance
called "browse" as Apache will give precedence to a search of the physical
subdirectory and will ignore the existance of "/photos/browse.py" and
as such will not trigger Vampire appropriately.

The reason that the two don't come together if the "handler()" method of
"/photos/browse.py" was actually in "/photos/index.py" is that Vampire
has an explicit check and disallows mapping to a directory index file if
the "req.path_info" field is not empty.

The thinking behind this is that the "index.py" file in that directory is mean't
to be an index file for that directory alone and shouldn't apply to a subdirectory
be it physical or virtual.

This doesn't mean that the two couldn't meet and thus "handler()" within
"/photos/index.py" be executed, but I believe it would be wrong to make
use of the "VampireDirectoryIndex" directive as the trigger for it.

Thus, what I see that could be done is for Vampire to support a new Python
option setting:

  PythonOption VampireVirtualDirectory index

What this would mean is that for the specific case where a virtual resource
within a directory is accessed, ie., there was no physical resource and there
was no other resource specific handler defined which could be matched, it
would fallback to executing the "handler()" method defined in the code file
"/photo/index.py".

In theory, this would provide you with the ability to preserve the structure
you have now. I do need to investigate though how this interacts with another
feature of Vampire whereby there can be default fallback handlers for
specific resource types. I would need to decide which should take precedence.
My initial guess is that the virtual directory handler should override the other
but it may need to be more flexible than that.

> Based on the rest of your reply, I am inferring that Vampire can handle
> dynamic object publishing from a database or filesystem, but that the 
> set up would have to be different from what I've been using.

As Vampire is now, "Yes" and "Yes".

> > Firstly, Vampire is structured so as to avoid altogether use of sys.path
> > and all the complications that can arise because of it. Thus, you would
> > not add "/web" to sys.path. 
> 
> Having '/web' in sys.path is fairly basic to the architecture that I've
> been developing. Every "web service" is a folder under /web, and each 
> includes both request handlers and regular Python modules, including 
> database access modules. I also want to be able to use Apache as one 
> front end among many, not as the only one; so I need to be able to 
> import modules in a more-or-less Python-native fashion.

Using the native "import" statement of Python has lots of issues though
in the context of mod_python, many of which have been covered in
discussions on the mailing list previously.

One can still mix handlers and Python modules in the same directory with
Vampire, but instead of using "import" you use "vampire.importModule()"
to load a module from the specific directory it resides in.

Thus, you could still do exactly what you do know, but by not using
"sys.path" and "import", and instead using Vampire's import mechanism,
you would get some additional benefits because the issues that come
up with using "import" don't arise. The Vampire importing mechanism
also solves lots of problems that exist in "apache.import_module()".

> Yes, it's an interesting example, and it provides a lot of information
> about how Vampire would deal with various usage scenarios. You should 
> add some of these details to your documentation.

Am slowly progressing towards being able to update the documentation.

Am currently in the middle of a rehosting of my web site from an Apache 1.3
to an Apache 2.0 site and moving from using PHP to mod_python/Vampire
for page composition. Also have heavy duty project at work, plus have 
been involved in dealing with some security issues with some Open Source
packages. Would love to be able to just sit down for a couple of weeks and
catch up with all my web site and Vampire stuff, but no such like right now.
Thus, everying in slow motion right now.

Graham