Graham Dumpleton wrote:
On 12/02/2006, at 2:40 PM, Jim Gallacher wrote:
Graham Dumpleton wrote:
get_directories could have several meanings in the context of a
request. Would req.get_module_directories() be a better alternative?
Does that capture the concept that you are trying to achieve?
Except that it isn't really specific to just module importing. I gave
the example
of using it to work out a relative URL to a base URL.
Yes, I did see that example, but just as I tend to automatically
s/~/$HOME/g, I also tend to see any long exposition from Graham as
being part of the Grand Unified Importing theory, even when there is
evidence to the contrary. Other than that I'm perfectly all right. :)
You might also
use it to
work out a base directory for where to load a non module file such as a
ConfigParser compatible config file.
My other option was:
PythonSetBaseDirectory
PythonAddBaseDirectory
req.get_base_directories()
or:
PythonBaseDirectory
PythonSetDirectory
req.get_directories()
or:
PythonSetContext
PythonAddContent
req.get_contexts()
4. Lastly, if you think the idea is good, but how it is done is
not, how do you
think it should be done and how do you think the Python*Handler in
FIles
directive should be solved, if at all?
I'll need to read your proposal a more few times before commenting
further.
My one minor quibble is the special meaning given to the '~'
character. My brain automatically reads this as $HOME. I suspect that
other people casually looking at an apache config file may do the
same, which could lead to some confusion.
Yeah, I know and I was going to put on my list of questions as to an
alternative
to using "~/". The other option was whether to use something like:
PythonHandler ${__handler_root__}/handlers/mymodule.py
PythonHandler ${myapproot}/handlers/mymodule.py
If you start going down arbitrary variable replacement though, do you
start
to allow variable references anywhere and allow stuff like:
<Files *.html>
PythonHandler ${myapproot}/handlers/mymodule.py::${__phase__}_html
</Files>
PythonOption myapp.variant production
PythonHandler ${myapproot}/handlers/${myapp.variant}/mymodule.py::$
{__phase__}_html
Ie., introduce other magic variables which refer to other attributes
associated
with the request, such as the phase, or even the value of variables
specified
using PythonOption.
Also, what variable interpolation scheme do you use, something like above
which would need a special parser, or something like builtin system
used with
mod operator for strings.
PythonHandler %(myapproot)s/handlers/%(myapp.variant)s/
mymodule.py::%(__phase__)s_html
Need to see what conventions other parts of Apache use as should be the
same
if one went this far.
I think this might take some experimentation for the substitution,
directive and function naming schemes. What seems like a good idea now
may be cumbersome with a little experience, in the same way that using a
namespace for PythonOption keys seems blazingly obvious now.
I like the "%(key)s" idiom for it's pythonic nature. You can look at an
apache directive that starts with Python and say to yourself "python
rules apply from here to the end of the line". (Except when they don't,
as in the case of module::function. Oh well, it's an imperfect world).
It would also be a good idea to scan JIRA and the mailing list archive
for other places these functions and substitution rules may be useful so
we don't end up with duplicate, but incompatible solutions in different
places. For example, in 3.2 you can use "PythonOption session" to set
the session class, but only for one of the builtin sessions. I'd like to
extend that functionality to user defined session classes and the ideas
you've outlined would be useful there as well.
Jim
