TG and multiple apps

[Robin Haswell]

Hey there

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

[Kevin Dangoor]

Hi 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

[Rob Haswell]

Thanks, I think I'll follow these steps for new apps and see how it
goes. Cheers :-)

[Keith R. Fieldhouse]

Kevin Dangoor wrote:
> In the meantime, I have these suggestions:
>
> 1) use CherryPy 2.2's tree.mount() feature.

The tree.mount() stuff does seem like just the ticket. What's not clear
to me is how to handle the differing configs. The
turbogears.update_config stuff deals with the global cherrypy config
object. If, for example, I want to use a different database for each
app is there an approach that would work?

Best,

Keith

[Kevin Dangoor]

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

[Keith R. Fieldhouse]

Kevin Dangoor wrote:
> 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).
>
>

I'm sorry, I should have been more clear. I knew that mount takes a
config object, my question really relates to where I can get the config
object. I suppose I could roll my own but it'd be rather nice if I
could some how leverage the [dev|prod].cfg files that are associated
with my apps, somehow.

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