> I'd like to have CP handle the situation of all the different instances of the
> application going to one CP instance. This change proposal has to do with
> static directories, essentially.
> Say I have a directory structure:
> If a person requests /js/file.js, I want to have it look in the /instance1/js
> subdirectory (if it's there). If it's not there or the file is not in it, I
> want it to look in the /www/js directory for it. So I'm looking for a "fall
> forward" mechanism that's completely transparent to the web developer in use.
> I'd like it to be a application level global setting such as
> tools.staticdir.fallforward: True which would take care of it for all static
> directory declarations in the application space. This would be combined with
> an application global config (see further proposal below) of
> tools.staticdir.root:"/www/instance1" so it would know where to fall forward to.
You should be able to achieve what you're looking for by simply adding
a new tool to the toolbox:
This would be an additional tool that the developer would turn on and
configure in config. The cherrypy.lib.static.staticdir function returns
True or False depending on whether or not it has handled the request,
and having two tools means it can be called twice. If one of them
returns True, then cherrypy.request.handler is set to None (inside
HandlerTool._wrapper). You could explicitly set
staticglobaldir._priority > 50 (to have it run after staticdir) and
then have it immediately return "if cherrypy.request.handler is None".
That is, you *should* be able to, and if you had picked any tool other
than staticdir to duplicate, this would work. But the default
dispatcher does some special-casing of the "tools.staticdir.dir" config
option that won't be duplicated if you change the name (to
"staticglobaldir", for example). That should be fixed in the core, and
I'll see what I can do about making that behavior fire based on an
attribute of the tool, or a naming convention, or some other re-usable
Another way to do it is for your app to simply replace
cherrypy.toolbox.staticdir with a wrapper of your own which handles the
extra "fallforward" argument, calls cherrypy.lib.static.staticdir
normally, and then tries the fallforward dir if that returns False. It
should be easy to subclass HandlerTool and override the _wrapper
> I'd appreciate your thoughts on this. I'd like to put these in as a proposed
> change in the Trac if anyone thinks it's a decent idea. This is application
> specific to my situation but seems like it would be very beneficial as a
> general purpose functionality as well.
That sounds like a great idea for your application, but I don't think
it's common enough to warrant building the "fallforward" config option
into CP, since for every tool (except the one you chose to extend ;)
you can run multiple distinct copies of the tool, with their own
config, via one line of code as I described above. I'd appreciate a
ticket, though, on making the special-casing of "tools.staticdir.dir" a
more generic mechanism.
> I also find (correct me if I'm wrong) that static directories config currently
> go like this:
> or tools.staticdir.root can be put in each subdir spec:
> tools.staticdir.on: True
> tools.staticdir.dir: "css"
> In the current situation, you can put the tools.staticdir.root line in the
> GlobalFile[global] section or in the ApplicationFile in each directory
> section. If I have multiple applications (or just one as in the example
> above), I'd like to be able to put the tools.staticdir.root in the [global]
> section of the application conf file, only ONE time. It appears that this is
> not possible currently.
The trick is that application configs don't have a [global] section,
but they do have a [/] section, which I think does what you want. Note
that any config section header in an app that is a path will be
compared against the PATH_INFO segment of the URL only, so any base
(including virtual hosts) or SCRIPT_NAME won't be included when
matching. This allows a config file or dict for an application to be
more modular, and blissfully unaware of where it's mounted.
You received this message because you are subscribed to the Google Groups "cherrypy-users" group.
To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups-beta.google.com/group/cherrypy-users -~----------~----~----~----~------~----~------~--~---