[mod_python] Re: best practices; was "is mod_python borked?"

Graham Dumpleton grahamd at dscpl.com.au
Sun Nov 5 00:43:54 EST 2006

Yes, forgot that '.' can be used in URL in place of '/' which can make
it even more interesting. I am guessing though that for this to work,
you would need to have been using SetHandler rather than AddHandler,
as imagine that using AddHandler would cause issues with Apache's
own attempt to match extensions against files. I'll have to try playing
with it some time to remind myself.


On 05/11/2006, at 6:44 AM, Jorey Bump wrote:

> Graham Dumpleton wrote:
>> So whereas one should be able to use fixed relative links in a  
>> page generated from a __call__() method called by publisher, one is
>> instead forced to either make them absolute path links, or
>> dynamically determine what the relative link should be by looking at
>> the URL and what is determinable about where the point sits in the  
>> object hierarchy.
>> This issue is further complicated by how publisher automatically maps
>> a request against a physical directory when SetHandler is used to the
>> index.py file, and when it maps a request against a physical file,
>> whether SetHandler or AddHandler is used, against the index() method
>> contained within it.
>> Not only does one have to deal with the fact that publisher will
>> accept a URL with out without a trailing slash and doesn't force a
>> trailing slash to be added in appropriate contexts, you end up, as
>> explained in the referenced email, with multiple URLs that can map to
>> the same resource. If all these URLs were at the same context level
>> that wouldn't really matter, but they aren't and have differing  
>> numbers of slashes within the URL, further making the process of
>> working with relative URLs a mess.
>> In summary, the problems I see are publisher not doing the  
>> trailing slash redirect where appropriate and how automatic  
>> mapping to the
>> index file and index function are done resulting in different URLs
>> working with different base URL contexts.
> I think you've overlooked another case: Instance attributes or  
> methods can be accessed with either slashes or dots as separators:
> class Dummy:
>     def html(self):
>         return """<html>
> <head><title>What Am I?</title></head>
> <body><h1>Hello! What am I?</h1></body>
> </html>
> """
> instance = Dummy()
> Now we can access the method in multiple ways:
>  http://host/dir/module/instance.html
>  http://host/dir/module/instance/html
>  http://host/dir/module/instance.html/
>  http://host/dir/module/instance/html/
> Determining the appropriate context to force a slash suddenly  
> becomes a lot trickier. Clearly, there's a use for the dotted  
> notation, not only as a way to obscure the technology used, but to  
> replace static content without disturbing existing links, provide  
> dynamically generated files with appropriate extensions for mime- 
> handicapped browsers, and other clever uses best left to the  
> programmer.
> I like the flexibility, and I'm happy to handle the details of URL  
> creation within my own code. I mostly construct absolute path  
> links, and it doesn't seem like that much of a burden. When I do  
> use relative links, I determine what resources they are relative  
> to, and try to protect the user from ever needing to edit the URL  
> in the browser. If someone does, and things break, how is that  
> different from any other mistyped URL?
> I understand the desire to include better support for relative and  
> incorrect links, but it seems the only way to accomplish this  
> automatically within Publisher is to introduce a limitation that is  
> sure to break existing code (as Graham points out). Some developers  
> really *like* to have URLs that never end in slashes, regardless of  
> the resource's place in the heirarchy. I wouldn't be happy if  
> Publisher suddenly started forcing slashes to appear where I didn't  
> want them.
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python

More information about the Mod_python mailing list