At 02:39 PM 12/20/01 -0800, Luke Opperman wrote:
>Hey, sorry for all the silly questions...
>
>Say I've got two very different sites on my server, held in
>two contexts. I write a SitePage for each. Where do you put
>these sitepages, how do you subclass them if you have
>various directory structures under each context? I've
>thought about this a bit, and have a few conflicting
>thoughts. Wondering what you all do.
>
>1. Have a server-wide Lib directory, as suggested in the
>DirectoryStructure. Then I would import Lib.SiteA.SitePage,
>assuming that root directory is in my sys.path. I guess I'd
>prefer not to do this in order to keep all files associated
>with a site together.
>
>2. Assuming the contexts are all in a directory on my
>sys.path, I could have separate Lib directories in each
>context. Importing would be SiteA.Lib.SitePage. My concerns
>here are that it makes all those imports dependent on the
>directory structure and name of the context.
>
>3. So what I'd prefer is to be able to set sys.path to
>include the current context's directory. Then each
>context/site could have its own Lib directory, importing as
>Lib.SitePage. But there seem to be a lot of issues with
>locking and cleaning up sys.path before and after import...
>
>Unless I'm missing something simple, like AppServer already
>creates little sandboxes for each context or something...
If the applications are truly separate, you could run them in totally
separate appservers, using MakeAppWorkDir.py to create a separate working
directory for each application. Just choose different port numbers for the
two appservers. There are some advantages -- you can restart one app
without restarting the other app, the session stores are totally separate, etc.
If you're going to run them in the same appserver, I can't think of a good
way to avoid having to hard-code the name of the context into the imports.
--
- Geoff Talvola
gtalvola@...
|