On Wed, Oct 24, 2001 at 01:57:52PM -0700, Chuck Esterbrook wrote:
| >It's Chuck's call, but my inclination is to shelve this until
| >after Webware 0.6 final is released.
|
| I concur. Part of it has to do with the fact that I want a
| more general URL solution ala Terrel's URLDecoder.
|
| For example, Clark's approach to URLs isn't exactly what
| I had in mind for my own site.
I'm interested in what your requirements may be.
My requirement is simple -- I need a way to encode
parameters, such as a company identifier, language,
or other settings that are shared across multiple
servlets without having to do anything special
in the HTML for those pages.
This can be accomplished nicely by a straight-forward
generalization of the path-based session mechanism
*already in place*. It's a clean, simple solution
to a straight-forward problem.
| 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.
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.
| We also discovered in the past that the effort in
| shaking out URL processing code is fairly large, so
| I'm not keen on writing or assimilating
| fresh code in that area for 0.6.
I can understand your reservation, but I've been using
this code for about 3 months now in numerous ways; and
very soon (next week?) a production setting. I'd much
rather not maintain a patch. The patch is small and
understandable. I've justified it many times and have
not had any significant challenge as to it's worth.
That being said -- I'll support what ever solution
you finally decide upon as long as it supports B1
(B2 is supported with query parameters).
Thanks!
Clark
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel