Kevin,
> For TurboGears 0.8, I wanted to be able to easily deploy a couple of
> TurboGears apps on a single site using CherryPy idioms. (Actually, the
> *main* goal is to be able to deploy an app as an egg... it's a
> secondary goal to deploy multiple apps.) Note that moving to Paste
> Deploy may be a good solution for some issues, but TurboGears 0.8 will
> not use Paste Deploy due to timing, if for no other reason.
That makes sense to me. There are (small) things for many parts of the
tool chain and it will take a little while to pull it all together.
> What do I mean by "CherryPy idioms"?
>
> class UserStuff:
> blog1 = Blog()
> blog2 = Blog()
>
> class Root:
> users = UserStuff()
Yes, that I what I realised I could do.
> This gives you two blogs at "/users/blog1" and "/users/blog2". This
> example is complicated by the fact that these are not two *different*
> apps, but rather two instances of the same app. Keep in mind, too,
> that while these two blogs are just statically created with those
> names, you could conceivably have any number of them with any names,
> given Python's dynamic nature.
Yes, a database table of clients so I create an application instance for
each.
> 1) URLs within an app
>
> If the blog application tries to go to "/" to get to the top of the
> blog, it's actually going to go to the top of the server. TurboGears
> 0.8 already has a way to deal with this: str(URL("/")) will give you a
> link to the "application root". In other words, something like
> /users/blog1. If the whole thing is being proxied behind an Apache
> site at /foo, you can also configure it so that the URL would be
> /foo/users/blog1.
Agreed, providing we are careful with all links within the app should be
quite workable.
> 2) Static files and other filter configuration
I understand the issue but have no suggestions. Like you I hope that
paste can help given its focus on deploying multiple applications.
> 3) Database configuration per webapp
>
> Dave Warnock just brought this up: each application instance may want
> its own database. This has some of the same configuration issues as
> the static filter problem above, plus the added bonus of wanting to be
> able to use tg-admin sql create to get your database(s) set up.
> Assuming you're not dynamically creating Blog instances, it is
> reasonable to have your site configuration file include database URLs
> for each path that requires a different one.
It would be a pity to support only fully dynamic or only from
configuration files.
For example I may want to call an api (directly in SQLObject?) from the
blog manager to create new databases on the fly for new blogs (mind you
that will raise other issues to do with creating postgresql databases).
> There is the added complexity here that maybe you want to have
> multiple blogs, but you want them to share a database. If the blogging
> app itself wasn't designed for this, then you'd need to do something
> like adding a table prefix... which is actually plausible, using
> SQLObject.
Table prefixes are a good idea, that would save a lot of resources (eg
open database connections). Does anything make it easy to have a model
and use it with different prefixes? (will need to work for all
relationships too).
> The tools available in TurboGears 0.8 make it possible to hook up
> multiple *different* TurboGears apps in a single site pretty easily.
> Even the database stuff is dealt with, because your site's model.py
> can just do "from blog.model import *", so that a standard tg-admin
> sql create works just fine.
>
> Given that, I think I'll likely punt on the hard questions for a
> moment to get TurboGears 0.8 out.
Happy with that.
> I love working with CherryPy, but we do need to answer these questions
> so that everyone isn't forced to write their own blog :)
Good call.
Dave
