|
From: <bc...@wo...> - 2001-02-14 10:12:11
|
[Robert] >On an unrelated note, module global variables are common in the Jython >world. Is there an advantage to PyServlet if each servlet has it's own >namespace to accomodate this? [Finn] > Well, is there an advantage? I considered it when I added PyServlet to > the repository, but for smallish apps, the application namespace is an > advantage IMHO. For larger apps, the application probably have to deal > with more controlled namespaces anyway. [Robert] >Very true about the namespaces. I'm not sure about >advantages, but currently module globals work- until another PyServlet >tramples them. This seemed in need of a fix. Each deployed PyServlet class have each own namespace (stored in PythonInterpreter.locals). It is the .py files stored under the same <context> that share the same globals namespace. >The choices looked like >disallowing globals, or adding individual namespaces, In addition to the shared globals, each .py servlet already have its own namespace available from within the doXXX() and service() methods as self.__dict__. >... >This depends on whether adding the unique namespaces was thought to be a >good thing to begin with. If not, it doesn't matter. If so, >implementing them looked like one of three options: > >1. an interpreter instance per PyServlet- overkill? Done already. >2. extract and insert servlet and namespace into and from the interpreter >for each request- messy? The implementation wouldn't be messy. The interp.execfile() call in loadServlet should instead be done as a PyObject ns = new PyStringMap() __builtin__.execfile(path, ns, ns) The request handling will then automaticly use this namespace when the py service method is called from PyServlet.service(). >3. execute the file, class, and servlet methods with Py.exec methods- >visually appealing, but not common practice, maybe for a >reason I thought :) Each Py.exec (and execfile) cause a classload. That should be avoided unless absolutely necessary. regards, finn |