Adding to FieldStorage

[Mike Looijmans <nl...@natlab.research.philips.com>]

>>>* How are applications supposed to perform write operations on a
>>>FieldStorage, in 3.3 and the future?
>>
>>Since we claim that FieldStorage behaves like a dictionary, the obvious
>>syntax would be:
>>
>>form['mykey'] = 'value'
>>
>>This would require a __setitem__ method which should look something like
>>this (with some extra code to handle lists):
>>
>>    def __setitem__(self, key, value):
>>        if self.dictionary is None:
>>        # Create self.dictionary as in __getitem__
>>        self.dictionary[key] = StringField(value)
> 
> 
> 
> Trac also appends to the FieldStorage list attribute, which complicates
> things a little further.
> 
> The '93' code also adds the add_field() method. Although this is not
> documented, there is nothing to indicate that it is a private method
> either. Calling add_field on a FieldStorage instance will not likely
> give the results a user expects, so we need to give some attention to
> that as well.

I initially intended add_field as a callback routine, which was later on replaced with the callback. 
The method is not really neccesary, but quite convenient when subclassing. All the processing takes 
place in __init__ which makes it impossible to just replace the method at runtime, which I had in 
mind at first.

I think we should support the dictionary syntax, e.g.

form['key']='value'
assert form['key'] == 'value'

The dict syntax will replace all 'key' fields with the new value. The add_field method can be 
reworked to act as one would expect, e.g.:

assert form['key'] == 'value'
form.add_field('key', 'value2')
assert form['key'] == ['value','value2']
form.add_field('key', 'value1')
assert form['key'] == ['value','value2','value1']

Maybe we can come up with a better name than add_field (append?) as well.

Re: Adding to FieldStorage

[Jim Gallacher <jp...@jgassociates.ca>]

Mike Looijmans wrote:
>>>> * How are applications supposed to perform write operations on a
>>>> FieldStorage, in 3.3 and the future?
>>>
>>> Since we claim that FieldStorage behaves like a dictionary, the obvious
>>> syntax would be:
>>>
>>> form['mykey'] = 'value'
>>>
>>> This would require a __setitem__ method which should look something like
>>> this (with some extra code to handle lists):
>>>
>>>    def __setitem__(self, key, value):
>>>        if self.dictionary is None:
>>>        # Create self.dictionary as in __getitem__
>>>        self.dictionary[key] = StringField(value)
>>
>>
>>
>> Trac also appends to the FieldStorage list attribute, which complicates
>> things a little further.
>>
>> The '93' code also adds the add_field() method. Although this is not
>> documented, there is nothing to indicate that it is a private method
>> either. Calling add_field on a FieldStorage instance will not likely
>> give the results a user expects, so we need to give some attention to
>> that as well.
> 
> I initially intended add_field as a callback routine, which was later on
> replaced with the callback. The method is not really neccesary, but
> quite convenient when subclassing. All the processing takes place in
> __init__ which makes it impossible to just replace the method at
> runtime, which I had in mind at first.
> 
> I think we should support the dictionary syntax, e.g.
> 
> form['key']='value'
> assert form['key'] == 'value'
> 
> The dict syntax will replace all 'key' fields with the new value. The
> add_field method can be reworked to act as one would expect, e.g.:
> 
> assert form['key'] == 'value'
> form.add_field('key', 'value2')
> assert form['key'] == ['value','value2']
> form.add_field('key', 'value1')
> assert form['key'] == ['value','value2','value1']
> 
> Maybe we can come up with a better name than add_field (append?) as well.

It seems to me that FieldStorage is a kind of ordered dictionary