Terrel Shumway wrote:
I haven't been following this thread closely, but here is my $.02 based
on my continuing experience in implementing a Cheetah framework over
WSGI and deploying it via CGI and mod_python.
Ian Bicking wrote:
Phillip J. Eby wrote:
Here's what I'm thinking: paths in the file should be allowed to be
relative to the directory containing the deployment file, and the
configuration passed to the application or its setup should include
the path to the deployment file. The combination of these two things
would suffice to allow distribution of an application in a largely
ready-to-deploy form. The application could always provide
facilities to edit its own configuration file(s) or the deployment
configuration.
This leads to the question: when would you edit the deployment file?
Besides just using a different directory prefix?
The "packager" edits the <deployment descriptor> and bundles the code,
templates, etc. that the app requires. This is often a different person
from the "programmer" who creates the components.
I expect the packager to have programming skills, even if they aren't
the same person as the application programmer.
The server administrator or "webmaster" is the person who edits the
<server configuration> file to assign a URL space to each app. The
webmaster might have his own middleware to add, e.g. for extra logging,
or performance monitoring.
The webmaster may not have programming skills (or at least not Python).
Though depending on the sophistication of the integration, I'd be okay
with some programming required. For instance, if you are integrating
your login method with the application's, it might be necessary to do
some programming -- simple login sharing should be easy, but sharing
user metadata and administrative operations (e.g., adding users and the
like) will probably require programming (unless the systems are
specifically meant to work with each other -- i.e., another standardized
interface).
A given application has a fixed set of requirements, why not just code
them up in Python? Well, I can imagine reasons, but I think we need to
start from use cases.
So here's a use case:
> that application can have more or less functionality (depending on
how much functionality I expect the parent to have -- e.g., session
support).
I'd like this to be automated. If, for instance, we can standardize the
session interface this should be doable. The application looks for,
say, session.api_1 (standard session API, version 1). If it finds it,
it uses it, knowing the interface. If not, it puts in its own piece of
middleware that provides the API.
Until we standardize that, we'll be doing this stuff ad hoc, but that's
okay -- this is an ongoing process.
Two core features that are "required" by a Java servlet container are
session support, and login support. And every existing container that I
know of also supports JSP.
JSP is funny, and not a model widely used for Python (I think). It
certainly doesn't seem as fundamental in a WSGI model, where URLs aren't
necessarily mapped to files.
That is, I don't think there's any kind of file you can just plop into a
WSGI container and it will display; not even Python source. There's no
file-like container, and there's no standard URL->object mapping or
configuration. I'm not entirely sure there should be a standard, at
least not one we expect most people to use... certainly several
frameworks could share implementations, to the degree they act
similarly. But object publishers (e.g., Quixote, Zope) and file-based
systems (e.g., Webware, Spyce) are going to remain fairly separate.
These three features -- session, login, templates -- are needed by
enough people that I think they should be standard. (e.g. how difficult
would it be to create a wiki if you could rely on the framework for
these? -- 80% of the work is done.)
Another kit that might have broad application is a formkit -- a
higher-level way to manage posted form data -- but that probably
doesn't belong in WSGI (PEP), because there are a lot of different ways
people want to do it.
I don't think this needs to be part of the request cycle at all -- the
application is always an intermediary there. It's simply a library.
Probably ditto for templates. But in python, "you really only have to do
it one way". There should be one (1) easy way to say how a container
interacts with a template engine. I'm not sure what that means yet, but
I'll think about it.
At first I thought templates should just be a library as well, though it
would be nice if applications could share templating configuration.
I.e., you could indicate a template search path, maybe adding more paths
on a per-application basis, or otherwise fiddling with that path (e.g.,
skinning an application based on URL). But we can handle that in a
neutral way, i.e., providing a generic configuration system that is
template users can use as they wish (though they'll want to form
conventions about key naming; or we can provide conventions about how to
adapt configurations to different naming schemes).
e.g. the framework I am building can get template files from different
places to easily support skinning. It would be nice to say "get template
X and fill it from these variables" without worrying about where X
resides in a filesystem or .zip archive. (along the lines of the java
ServletContext.getResource*() methods) If I deploy four applications
(Contexts), I want them to share template files
(/var/www/sitename/templates/) so the designer can change the look and
feel of the whole site at once. In my case, I also want a set of
templates shared among many sites on the same server (/var/www/templates/)
There should be a standard way for servlet authors to say "this is the
'content' piece that I care about, and here are some styles and <head>
content. Now you put it together inside the site-wide templates to
create the page." And it shouldn't matter to the developer whether that
sitewide template is implemented with Cheetah or CherryPy or Quixote or
ZTP or whatever.
This does make me think templating could participate in the request
cycle, as a filter of sorts. Right now we're trying to move to SSIs as
a shared templating scheme, at least when we move to Apache 2, because
all our scripts can output SSIs and Apache will evaluate them. Maybe
not everyone will want SSIs (obviously), but maybe this general pattern
can be used -- one of filtering text. I don't know what else we can
agree on, especially in environments where everything isn't Python.
This is akin to an XSLT-based templating approach, but of course there
are much better languages than XSLT that we can come up with ;)
If we do it as filtering, we don't have to agree nearly as much about
templating languages or even interfaces. We just have to agree on a
document format, which somehow seems easier. We wouldn't even have to
agree that much on document format; if we were using SSIs, we could make
something that transforms document type X into SSIs, and then Apache
does the next step. This is an N^2 problem, given N kinds of
data/template languages, but at least it offers some kind of solution.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
_______________________________________________
Web-SIG mailing list
[EMAIL PROTECTED]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
