| 1. Prior to seeing your examples, I expected the extra values
| to come after the context as I see that as being the "entry point"
| of a site. Now that you've done it the other way around, the
| question arises, should they go before, after or both?
A. Heiko's session code was "before" and this code
worked well, thus I had much greater certainty of
it actually working well.
B. From my understanding of the code, if you put the
parameters after the context, you would require
N+1 cashes, one for each context plus the default.
Where if the parameters go before the context,
you can share that cashe, as it currently stands.
C. From the user's perspective it matters little.
| 2. Also, if I did a multi-lingual site, I wouldn't want
| ".../lang=en/...", but instead just ".../en/...". e.g.,
| args by position rather than name.
A. Positional arguments are mandatory (or difficult),
but arguments by name can be optional; I'm already
using this side effect, 'en' is the default for lang.
B. Arguments by name can be merged in with cookie
and request values in the case where the user
doesn't care where the value comes from. Also,
it allows a query argument to override a
variable defined from the path.
C. The equal sign (=) makes for a nice delimiter;
it is rare (non-existant?) that a path or servlet
has an equal sign in it. Thus, the code for this
can be completely generic and does not require
any sort of "registration" system.
D. All I care is that I get the value... how nice
the URL looks is rather secondary. Although I
must say that a URL by key=value pair is probably
easier to debug...
| 3. Finally, before we apply URL dissecting patches left and right, have you
| reviewed Terrel Schumway's URLDecoder? I never had time to fully digest it,
| but from what I followed he seemed to be reaching for something very
| general. Would this take care of you, or at least provide an easy hook to
| _add_ URL processing to your application, without having to modify the
| WebKit sources? http://www.ics.uci.edu/~tshumway/webware/urldecode.html
That is kinda interesting. A bit too flexible if you ask me.
There is a time for strategy pattern, I'm not sure we need
so much flexibility here. Here are my requirements...
A. Satisfies a real "need".
This mechanism allows for a set of parameters
that are implicitly included with any relative
URL reference. This enables a context to be
enabled independent of sessions and query
parameters without a complicated URL construction
and inclusion mechanism.
B. Is "out-of-the-way" if you don't use it.
Since this code only comes into action if it
discovers a path segment with an equal sign
immediately following the adapter name, it
stays up and out of the way.
C. Is "easy-to-use" if you do want to use it.
With this method, adding paramters is easy, just
put the key=value items on the line immediately
following the adapter. Accessing them is also
easy, a simple modifification to request().value()
and request().hasValue() makes them accessable
without further API complexity.
D. Is "testable".
I can test this code with a pretty serious set of
urls and be very confident that it will operate
as expected. To make it rock solid, one can forbid
the equal sign in context names. I think that
the equal sign is already forbidden in module names.
E. Is "general".
This patch is analogous to the query parameter
mechanism, which is very general. And fits in
seamlessly with most read-only cookie support.
There is a need to give "transaction specific"
parameters and "context specific" parameters.
Query parameters solves the latter, this solves
the former. Sessions can be used to solve almost
everything else.
I hope this better describes my rationale.
;) Clark
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel
