[Web-SIG] Form field dictionaries

[Ian Bicking]

On Wednesday, October 29, 2003, at 09:11 AM, Steve Holden wrote:
> In which case, let _me_ repeat _myself_ :-)
>
> If an argument has multiple values, this should only be handled if the
> processing element (page code) has indicated that multiple values are
> acceptable for that argument. When an argument is possibly  
> multi-valued,
> form['fieldname'] should *always* be a list, even if it has only one
> element [and I don't see why it shouldn't be legal to see an empty list
> if the argument doesn't appear in the URL or POST input at all]. If no
> indication has been given that multiple occurrences are acceptable then
> an exception should be raised which, if not trapped by the web app,
> should eventually result in (say) a 422 (unprocessable entity) or a 406
> (not acceptable) server response.
>
> When an argument is *not* allowed to be multi-valued then
> form['fieldname'] should return a string, and an error should be raised
> if the argument has multiple occurrences. If the argument doesn't  
> appear
> in the URL or POST data at all then it's arguable that a KeyError  
> should
> be raised, again resulting in a server error if untrapped.

We can also handle this through the particulars of the method calls we  
use.  E.g.:

     def getone(self, field, default=NoDefault):
         try:
             value = self._rawfields[field]
             if isinstance(value, list):
                 raise BadRequestError, "Multiple values were not  
expected for the field %s" % field
             return value
         except KeyError:
             if default is NoDefault: raise
             return default

This doesn't require any declaration, and follows the typical implicit  
type checking that's usually done in Python code.  Of course, that  
BadRequestError is another (important) point of discussion.

> I'd be prepared to allow a "sloppy" option to have form['fieldname']
> return an empty string under those circumstances, a la ASP, and to
> return the first of multiple occurrences. But I *do* think that  
> "sloppy"
> would be an apposite name for such tactics.
>
> if we're building a new API then for heaven's sake let's not repeat the
> mistakes of earlier generations. And let's try not to have each of  
> these
> discussions more that two or three times a month :-)

I'm not sure if people will ever really be happy with one decision.   
Which makes me feel like we should just expose the status quo -- you  
get a dictionary that might contain lists -- and let people process  
that as they want.  If we provide multiple options, then we do so  
explicitly and without strong bias.

http://cvs.sourceforge.net/viewcvs.py/*checkout*/webware-sandbox/ 
Sandbox/ianbicking/FormEncode/DictCall.txt?content- 
type=text%2Fplain&rev=1.1
http://cvs.sourceforge.net/viewcvs.py/*checkout*/webware-sandbox/ 
Sandbox/ianbicking/FormEncode/DictCall.py?content- 
type=text%2Fplain&rev=1.1

This uses a method signature to handle list conversion and a bunch of  
other conversions as well, like ints, ordered lists, and dictionaries.   
But it's not complete, and I doubt it could be made into something  
complete (and I've already moved on).  OTOH, something that was  
complete would be burdensome in some situations.  And other possible  
features, like Zope's :action or Webware's _action_ fields, are  
naturally tied to a specific environment.  List vs. string fields are  
just the tip of an iceberg of general validation, and validation is not  
something we can tackle right now (at least not for the standard  
library).

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org