I looked into the URL parsing, and I think I've got something
implemented that will work and be flexible. I'm interested in feedback
on the interface, and any novel ideas of what people would like to do
with URL parsing (so we can make sure this system can facilitate that).
At its core, the URL parsing is done with a URLParser object, mainly
with the method:
parse(self, transaction, requestPath)
requestPath is the portion of the path that still needs to be handled.
It returns the servlet, and may modify the request. Typically there
will be a chain of calls to parse the URL. The built-in ContextParser
and FileParser mimic the current behavior.
So a request for /MyContext/Article/100 might result in:
aContextParser.parser(trans, '/MyContext/Article/100')
calls: FileParser(path_of_MyContext).parse(trans, '/Article/100')
FileParser finds path_of_MyContext/Article.py, and returns the servlet,
setting the request's extraURLPath to /100. If it found a directory
Article/, then it would pass the buck like:
FileParser('path_of_MyContext/Article').parse(trans, '/100')
The way you hook into the system is through special variables in
__init__.py, where you can define your own parser. A parser that strips
out positional arguments might look like:
# in __init__.py
from URLParser import URLParser, FileParser
import os
class ParsePath(URLParser):
def parse(self, trans, requestPath):
newPath = []
for part in requestPath.split('/'):
if part.find('='):
name, value = part.split('=', 2)
trans.request().setField(name, value)
else:
newPath.append(part)
return FileParser(os.path.dirname(__file__)).parse(trans,
'/'.join(newPath), ignoreInit=1)
parsePath = ParsePath()
(you may notice the ignoreInit argument, which avoids an infinite loop
where FileParser keeps looking in __init__ for hooks -- that optional
argument is specific to FileParser)
I also plan to add other hooks to FileParser that make it easier to deal
with certain situations. Like for URL named arguments, maybe there'd
just be a special variable you'd set -- but those would just be
shortcuts for this same behavior.
Redirects and File Not Found are done strictly with exceptions.
Anyway, I think this will make possible nearly everything I described in
http://webware.colorstudy.com/twiki/bin/view/Webware/UrlDecoding ,
though any settings that would be modified through the URL would have to
be in the request (which means for instance that to have some URLs email
exceptions while others display them would require a change to the
exception handler to check the setting in the request, not from
Application's settings).
This also doesn't do any caching, though it could be extended to do so.
Some URL transformations *can't* be cached, so there'd have to be
something in the interface to indicate whether the return value was
cachable -- not to mention something to indicate how to deal with the
cache, since the URL parser doesn't produce a file path, it produces an
actual servlet.
Ian
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
