On Wed, Aug 22, 2001 at 09:34:20AM -0700, Mike Orr wrote:
|
| > I think the "values" method would be a better place to
| > make them visible, as I think keeping "fields" with
| > just query parameters is cleaner. The "values"
| > also contains cookie values... which IMHO, makes
| > much more sense, especially considering _SID_ is
| > currently a cookie value. Thus, values can use
| > search order: query-parameters, cookie-values, path-values
|
| 'fields' won't be so pure once we start parsing both GET and POST values
| rather than just one or the other. And the same situation will arise:
| whether to offer only merged values (and which to override), or only
| separate values, or both. I say we should offer both, so that those who
| want to be lazy can be lazy, and those who want to recognize a value
| only from a certain source can.
|
My take... (off the top of my head):
field is used for query parmeters ("GET") and
for post fields ("POST"); but not query
parameters duing a post.
value is the proverbial dumping ground... for
us "lazy" types. With the following
search order...
Post Params
Get Params
Cookie Values
Path Values
Then... for the non-lazy types, field stays pure
(with it's current meaning). And we introduce
postFields, getFields, pathValues and cookieValues
or sommtin along these lines.
If Post and Get parms are mixed in "field", I assume
that post parameters would shadow get parameters?
Just thoughts...
Clark
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel
