"Clark C . Evans" <cce@...> wrote:
> | In fact, what's apparent from previous discussions is
> | that URL-needs vary widely.
>
> This isn't clear to me at all. What other requirements
> would there be? I can see one other requirement -- one
> would like to use path based syntax instead of query
> parameters; much like Java Servlet path mechanism. This
> is a completely separable requirement from the one above.
> And a single solution will most likely not satisfy both.
Oh, there's much, much more that can be done with URLs.
For instance, I'd like to be able to join two directories -- one which
contains servlets, and one with contains static pages or perhaps
Cheetah templates. A nonprogrammer would then be insulated from
documents which would be dangerous to edit (Python code).
I'd like to properly represent abstract objects (like database
objects). I can do this with extraPathInfo now, but the caching
doesn't work as I'd want -- I have to recreate the servlet each time
on awake(), when if the servlets were cached according to that
extraPathInfo (or something like that), then I'd only have to set
things up in __init__.
I'd like to be able to modify settings based on the path of the URL.
For instance, .html files in some paths might need to go through a
processor that wraps them in a template -- in other paths they might
be presented verbatim. In some paths, errors should be emailed to me,
in other paths they should be displayed immediately.
I'd like to be able to better be able to resolve conflicts between
extensions. Specifically, I'd like to be able to say that .tmpl files
override .py files.
I'd like to do positional arguments before the servlet -- perhaps
fragile, but also traditional and a bit more compact.
Somewhat like mod_speling, I'd like to have case-insentive URLs and
I'd like to have spell checking in the URLs -- including spell
checking on non-filesystem arguments (positional URL arguments both
prefixing and following the servlet name).
I'd like to have enough introspection to create a sitemap directly,
as well as indexes and the like.
I'd like to be able to represent arbitrary URL mappings, ala
mod_rewrite.
That's just a few things I can think of, mostly things which I can
give specific situations where I'd use them. I bet other people will
have other ideas.
I *don't* think that Application should support all of these -- quite
the contrary. I'd like to see a system that gives all the *hooks*
necessary to do these sorts of things. I'd like a less centralized
algorithm -- much shorter than what is currently there.
The one things that I *don't* particularly want is fully dynamic URL
mapping -- I'm fine with indefinitely caching the results of a URL
decoding. Those results won't necessarily be a filename, but they'll
be something.
> In short, I only see two core permutations:
>
> 1. The query information comes *before* the servlet,
> and hence is shared across multiple servlets.
> This is my case, and the case of the path based
> session mechanism.
>
> 2. The query information comes *after* the servlet.
> And hence is specific to a specific servlet.
> This case is a simple rewrite of query parameters.
>
> There are two sub-permutations:
>
> A. The parameters are by position. This is much like
> The java servlet mechanism. And this exposes either
> an array for the parameters or a lookup table is
> needed to mix these parameters with the query parms.
>
> B. The parameters are named by a key. This is much
> like the http query parameter mechanism.
>
> What I need is B1. The built-in http query parameters
> give you B2. I don't think A1 or A2 are that useful
> since parameters by position is brittle and not self
> documenting. And I would put forth that perhaps
> given B1 and B2, A1 and A2 are not necessary.
Quite the contrary, I don't mind passing every URL through a function,
so B1 and B2 don't seem very useful to me, since query strings are
generally fine for that sort of thing.
Ian
|