Scott Chapman wrote:
> 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:
> /www
> /www/js
> /www/images
> /www/css
>
> /www/instance1
> /www/instance1/js
> /www/instance1/images
> /www/instance1/css
>
> 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:
cherrypy.toolbox.staticglobaldir =
HandlerTool(cherrypy.lib.static.staticdir,
name='staticglobaldir')
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
mechanism.
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
method.
> 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:
>
> GlobalFile.conf
> [global]
> tools.staticdir.root:"/path/to/files"
>
> or tools.staticdir.root can be put in each subdir spec:
>
> ApplicationFile.conf
> [/css]
> tools.staticdir.root:"/path/to/files"
> 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.
Hope that helps! 
Robert Brewer
System Architect
Amor Ministries
fumanchu amor.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups-beta.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---
|