I was wondering what the situation with multiple applications is?
For example, my work is gaining a suite of TG-powered in-house apps,
which look a bit like this (from memory so won't be perfect):
# /myapp/controllers.py
import app1
class Root(controller):
app1 = app1.Root()
# /myapp/app1/controllers.py
class Root(controller):
""" etc... """
You get what I mean. However, each app (should) have its own database
(and therefore a different DB URI), as well as its own models and such.
The upshot of all this is tg-admin just doesn't work at all, and it's a
pain having to symlink model.py all the time so the tg-admin sql
commands work. Am I going about this the wrong way, and is there another
way I should so it? Or does TG not support this?
Thanks :-)
-Rob
On 4/11/06, Robin Haswell <r...@digital-crocus.com> wrote:
> I was wondering what the situation with multiple applications is?
Aspects of multiple application support (particularly configuration)
are not where I'd like them to be. Beyond configuration, I also want
to see a mechanism for template overrides. This is the primary subject
of the next major release of TurboGears (codename First Class, if you
see us mentioning that).
In the meantime, I have these suggestions:
1) use CherryPy 2.2's tree.mount() feature. (I don't have a doc link
handy, but it's one of the main new features in CP 2.2). This will
ensure that your configuration is sane between apps. Using
tree.mount() is something you'd do externally to your main tree (ie
you don't just instantiate your subapp and attach it to your Root).
You can do this in your start script. First Class should allow you to
just instantiate and attach to your Root in normal CherryPy style.
2) Put each app in its own quickstarted project, rather than just a
separate package in one project. Each app will get its own egg, and
one app can easily depend on another (even a specific version of
another). Again, configuration will become saner in First Class. Note
that the tg-admin sql command takes an -egg parameter so that you can
specify that you want to create the database that goes along with a
specific app.
If you don't put each app in a quickstarted project, its Root should
at least extend controllers.Root, so that URL generation works
correctly.
HTH,
Kevin
Best,
Keith
mount() can take a config:
mount(self, app_root, baseurl=None, conf=None) method of cherrypy._cptree.Tree i
nstance
Mount the given app_root at the given baseurl (relative to root).
Kevin
My plan is to unwind what start-myapp.py is actually doing and see if I
can reconstruct the appropriate config objects that way (with the
holiday this past weekend I didn't get much of chance to look into
this). In a *very* shallow look, it appeared that there was a global
config object that the app set up which would be awkward but I'm pretty
sure I was looking at things incorrectly.
One other question: Do you imagine that someone trying this would
create some sort of meta-app that mounts both "real" apps or would they
just treat one of the apps as the "master"?
I know some (all?) of this is much easier in "FirstClass" but if there's
a way to pull this off without too much ugly hackery in .9a4 it'd help
me with some things I'd like to get done relatively soon...
Best regards and thanks,
Keith