At 11:41 PM 8/3/2001 -0400, you wrote:
<snip>
>In the process of fixing the AbsolutePath directory index problem, I
>realized that AbsolutePath requests weren't going to work with our
>latest code because they don't have a context, and one cannot be created
>for them by creating a file named __init__.py next to them(due to
>permission issues). So I added some code to ServletFactory to create
>packages for these file in a new way that doesn't require creating an
>__init__.py file. It seems to work correctly, but Geoff, please take a
>look at it.
I should point out that I've never tried the AbsolutePath feature -- I
always use a regular Webware context.
I think this is the code you're talking about:
## There is no context, so create a package name that is the same
as the filesystem path
if fullname == None:
remainder = path
remainder = string.replace(remainder, '\\', '/')
remainder = string.split(remainder, '/')
moduleName = string.join(remainder,".")
if moduleName[0] == ".":
moduleName = moduleName[1:]
directory, contextDirName =
os.path.split(serverSidePathToImport)
if debug: print moduleName, contextDirName, directory
filename = contextDirName[:string.rfind(contextDirName, '.')]
module = self._importModuleFromDirectory(moduleName,
filename, directory)
return module
If I understand the code correctly, it's creating a "fake" package name
based on the filesystem path? So if the file is located at
/foo/bar/qux/mypage.py it'll import the module as foo.bar.qux.mypage? If
that's right, it sounds safe to me.
You're not really following the normal rules for importing a package, which
are listed in the documentation for the imp standard library module --
here's a snippet of the documentation for imp.find_module():
>This function does not handle hierarchical module names (names containing
>dots). In order to find P.M, i.e., submodule M of package P, use
>find_module() and load_module() to find and load package P, and then use
>find_module() with the path argument set to P.__path__. When P itself has
>a dotted name, apply this recipe recursively.
In other words, first import the package itself (i.e. the __init__.py) and
then the module within the package. These are the rules that the context
importing code follows, and that's why you need an __init__.py in each
context directory and subdirectory.
I wonder if we can relax the requirement for an __init__.py in each
subdirectory of a context? I'll do a bit of experimenting. I was
reluctant to deviate from the standard Python package importing rules but
if this is working for the absolute path case, maybe it'll work for context
imports also.
<snip>
>BTW, I need a go/no go on the Services architecture. If you haven't
>looked at it, please do. If you're waiting on more commentary, let me
>know.
I was hoping Chuck would comment on the design. I also wanted to see a
little bit better documentation so I could make sense of all the new
options in the Application.config. It really wasn't obvious to me how it
worked just from looking at it.
- Geoff
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel
