quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <grah...@dscpl.com.au>
Subject Re: Regex based publisher proposal
Date Fri, 08 Sep 2006 05:42:23 GMT

On 08/09/2006, at 2:53 PM, S├ębastien Arnaud wrote:

> In short, Nicolas did read my mind correctly in regards to what I  
> am attempting to do here. I have searched and searched like many  
> python developers for a proper web framework and I have settled for  
> mod_python about 2 years ago. I tried afterwards the new "popular"  
> ones such as Ruby on Rails, TurboGears, Django, but not really  
> liked those because mostly with their integration with SQL Objects  
> type DB abstraction, which I never bought into, and their  
> dependence on specific templating systems. Nevertheless, they did  
> introduce some interesting concepts (such as regex url mapping),  
> which I am attempting here (poorly it seems) to implement directly  
> in mod_python.

I'd still appreciate an English description with examples as I  
haven't delved too
much into some of these other packages. Ie., what does the URL look  
like for
a concrete example, and how does that relate to what files Apache may  
match
in the file system and subsequently what may be interpreted within  
the handler
from the path info.

I know I could probably sit down and work it out, but my excuse is I  
am not well,
even had to take a couple days off work, so not thinking too  
straight. ;-)

> To put things back into context, the code I submitted was a simple  
> draft from a passion impulse over the labor day week-end and was  
> never (in my mind) a solid implementation but more something to  
> illustrate what could maybe done and open a discussion.

My feedback was intended to be constructive, not critical. :-)

> In regards to:
>
> path,module_name =  os.path.split(req.filename)
>
>     # Trimming the front part of req.uri
>     if module_name=='':
>         req_url = ''
>     else:
>         req_url = req.uri[req.uri.index(module_name):]
>
> It is bringing a question I have had for a long time in mod_python.  
> Is there a way to identify accurately the relative virtual path of  
> a request other than comparing to the physical path, especially  
> when using apache definition such as VirtualHost & Location?  For  
> example let's say you define something like:
> <Location /myapp/admin/>
> 	AddHandler mod_python .py .html
> 	PythonHandler mod_python.publisher
> </Location>
>
> And there comes a request such as http://myserver/myapp/admin/ 
> login.html
>
> How do you determine accurately that the part of the path /myapp/ 
> admin/ is in fact the virtual root of your application ?

If a Directory directive is used, or the handler directives appear in  
a .htaccess file,
the you can use req.hlist.directory.

Caveats to this are that prior to mod_python 3.3, if the handler  
directive appears
inside of a Files/FileMatch directive within those two contexts, the  
value was wrong
and could not be used. Further, prior to mod_python 3.3, the result  
would be wrong
if use wildcards in the Directory directive, or the DirectoryMatch  
variant was used.

When the Location directive is used, there is no physical directory  
which corresponds
to it and so req.hlist.directory wouldn't be valid as its purpose is  
to denote the physical
directory a directive was associated with. A caveat to this though,  
is that prior to
mod_python 3.3, req.hlist.directory would actually list the path  
specified in the
Location directive. This isn't the case though in mod_python 3.3 and  
it will instead
be None when used in the Location or LocationMatch directives as it  
causes problems
otherwise with a non existent path being used as a location to search  
for Python
modules.

With my brain being clouded at the moment, I cant remember off the  
top of my head
what the correct way is and I would have to check things, but when  
you use the
Location directive, isn't req.path_info the part of the URL which  
lies below where the
Location directive was specified for. If my memory is correct, this  
doesn't mean you
can simply take the length of req.path_info and drop off that much  
off req.uri though.
The problem is that req.uri isn't normalised in the way that  
req.path_info is, so it may
contain repeating slashes and other crud that can stuff things up.  
You need to address
that before you can use it.

> Also, a little bit trickier when you get something like: http:// 
> myserver/myapp/admin/display/asc/xxx
>
> 1) Is the only way to pass along all requests (not filtered by  
> extensions) to your mod_python handler is to use something like:
> 	SetHandler python-program
> 	PythonHandler myhandler

In mod_python 3.3, you will be able to specify a fixup handler which  
did:

   def fixuphandler(req):
     req.handler = 'mod_python'
     req.add_handler('PythonHandler', 'myhandler')
     return apache.OK

The bit that doesn't work before mod_python 3.3 is the assignment to  
the req.handler
attribute, with it being read only in older versions.

In mod_python 3.3, when using req.add_handler(), the handler need not  
even be a
string, but could be an actual callable object.

I still haven't quite finished the article, nor have I announced the  
new site yet, although
was close to doing so, but you might want to read:

   https://www.dscpl.com.au/wiki/ModPython/Articles/ 
SetHandlerVersusAddHandler

This document hasn't been thoroughly checked or reviewed yet, so  
feedback and/or
corrections are most appreciated.

Some of the stuff in mod_python 3.3 should make it much easier to  
create more
flexible systems. This is in part why I wanted you to describe in  
English what you were
trying to achieve rather how you thought you needed to do it. That  
way I can more
easily relate it to how it could be done in mod_python 3.3 where new  
features may be
able to be used.

> 2) In this situation determining the virtual root of your  
> application is crucial to be able to separate the regular path from  
> the potential parameters/actions so how would you go about it? I  
> have in the past used the cheap trick of passing along in a  
> PythonOption the virtual path of my app, but there must be a better  
> way. I have still failed though to find in the mod_python docs a  
> way to read the properties of an apache <location> or <virtual  
> host> directive in order to determine automatically the proper  
> virtual root of my handler

Provided things are done inside a Directory/DirectoryMatch  
or .htaccess file, then the
req.hlist.directory attribute can be used. As to the Location/ 
LocationMatch case, I'll
try and figure that out later.

> Finally, all I am really trying to build here is a drop-in  
> replacement for mod_python.publisher by providing by default the  
> same functionality, but to offer the flexibility found in newer web  
> frameworks via regex mapping and eventually implement a reverse url  
> mapping method, just like Nicolas described it.

I would really suggest you not base in on mod_python.publisher code  
as it is actually
flawed in some important ways that make working out relative URLs to  
resources
a problem. See:

   http://www.modpython.org/pipermail/mod_python/2006-March/020501.html

for a description of some of the problems, but in short,  
mod_python.publisher
doesn't deal with trailing slash redirection in the way it probably  
should. The result
is that the same resource can be accessed with different URLs at  
different
levels in the URL namespace. Depending on through which URL it is  
accessed
a relative URL to something in the same directory has to be different.

Anyway, time for me to go out and get some fresh air. Then I better  
try and finish up
some stuff on my new site so can make it officially public.

Graham



Mime
View raw message