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

Reply via email to