Kevin Dangoor wrote:
[composit:main]
use = egg:Paste#urlmap
/app1 = config:app1.ini
/app2 = config:app2.ini
/login = egg:LoginManager
I've seen the discussions on web-sig (and Phillip's article about SCALE).
When using CherryPy, it's quite natural to compose things through
standard Python means. As in this contrived example:
from logins import LoginManager
class Root(controllers.Root):
login = LoginManager()
This is really a question of where one prefers to keep configuration:
in config files, or in Python.
Well, phrased that way, I'd rather keep my configuration in
configuration files ;)
paste.deploy doesn't take the place of all the ways you'd want to
compose an application -- if you *always* want one app to hang off
another, then it's best done in Python. However, if I have to edit
someone else's code just to add an app that will make me most unhappy.
Of course, I could create a site-local dummy CherryPy app that just
forwarded to other apps (assuming they are all CherryPy apps to), but
that's quite a big heavier than the configuration file.
The goal of paste.deploy isn't to take over everything. But it does
allow a separation where appropriate. Simply from a software
development point of view that separation usually becomes apparent -- if
you are making modifications to an app that you don't want to commit,
because they aren't universable applicable, then it's probably
"configuration", and paste.deploy addresses a certain class of
configuration well.
My hope is that paste.deploy will allow a little of what PHP allows --
that someone who isn't a programmer and maybe knows nothing about Python
can install and configure an application, and that hosting companies can
provide good support for this process.
Anyway, regardless of features this makes it easy to keep those concerns
separate from the application itself.
This is true. For a large portion of people, though, I'm not sure that
this separation of concerns is needed. Luckily, it's entirely possible
to offer both ways of composing an app: through pastedeploy and
standard cherrypy/python means...
Sure -- the only thing paste.deploy needs is an entry point, which isn't
exclusive of any other means of deployment or configuration. Well...
AFAIK CherryPy still has limited WSGI support (only one CherryPy WSGI
app per process), but I hope and assume that will be resolved. But
that's a separate issue... paste.deploy requires good WSGI support, and
good WSGI support is useful irregardless of paste.deploy.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
