[
http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12445123
]
Graham Dumpleton commented on MODPYTHON-93:
---
I have committed some changes into repository now which
fixes the issue with add_field() but also does
[
http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12444850
]
Mike Looijmans commented on MODPYTHON-93:
-
A very simple approach would be to delete the dictionary attribute when
any change is made.
The add_field
[
http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12433818
]
Graham Dumpleton commented on MODPYTHON-93:
---
Have we decided that we will not try and be compatible with Trac and expect
people using mod_python 3.3
As I recall, dropping the current Trac version for 3.3 is what we wanted to do.
In addition, there was talk about implementing a __setitem__ method as well to support manual
insertion of fields, so that FieldStorage becomes a real dictionary-like object. The add_field
method was to be reworked
[
http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12417405
]
Jim Gallacher commented on MODPYTHON-93:
As part of the improvments to FieldStorage, the Field class __init__ method was
changed in trunk (3.3-dev) and backported
I was checking the documentation with respect to this patch and I noticed a
couple of things.
The FieldStorage constructor has 2 undocumented parameters, file_callback=None,
field_callback=None. These were added in r160259 as part of Barry Pearce's fix
for MODPYTHON-40. In the same patch,
[
http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12370996
]
Jim Gallacher commented on MODPYTHON-93:
I was checking the documentation with respect to this patch and I noticed a
couple of things.
The FieldStorage
On Tue, 29 Nov 2005, Jim Gallacher wrote:
I still think the correct place to create the index dictionary is in the
__init__ phase. Using the dictionary-on-demand idea only improves performance
on the second access to a form field. For the first access you are still
iterating through the
Jim Gallacher wrote:
Nick wrote:
Just one comment. It seems like it would be better just to make
add_method inline, since everything else in __init__ is, and it never
gets called from anywhere else.
add_method?
Haha, thanks, I haven't had coffee yet. The add_item method, that is. :)
I
Just one comment. It seems like it would be better just to make
add_method inline, since everything else in __init__ is, and it
never gets called from anywhere else.
s/_method/_field/g
The thing I had in mind when I built the add_field method was that I
could subclass FieldStorage and give
Gregory (Grisha) Trubetskoy wrote:
Having looked at the FieldStorage code, I'm guessing the idea was that
you parse fields as they come in and append them to a list. This
preserves the original order of fields, in case it is needed.
I'm not sure that maintaining a dictionary alongside the
Gregory (Grisha) Trubetskoy wrote:
Having looked at the FieldStorage code, I'm guessing the idea was that
you parse fields as they come in and append them to a list. This
preserves the original order of fields, in case it is needed.
I assumed that as well, but I'm not sure getting the
If you provide say FieldStorage.make_dict that returns a dictionary, then I
don't see why the order of the keys is important when the original list is
still available.
Nick
Nicolas Lehuen wrote:
Hi,
Speaking of ordered dictionary :
Gregory (Grisha) Trubetskoy wrote:
On Mon, 28 Nov 2005, Nicolas Lehuen wrote:
Why is the ordering so important ? I do understand we need to support
multiple values per field name, but I don't see why ordering is
needed.
I think that it may be dictated by some RFC (the stdlib does it this
2005/11/29, Nicolas Lehuen [EMAIL PROTECTED]:
2005/11/29, Mike Looijmans [EMAIL PROTECTED]:
Nicolas Lehuen wrote:
Why is the ordering so important ? I do understand we need to support
multiple values per field name, but I don't see why ordering is
needed.
Because there are
Nicolas Lehuen wrote:
One proposal was to use an OrderedHashtable. As you can see, the reply
was quite definite :
No. There is nothing in the spec that says that these parameters should be
in any sort of order. CGI scripts that expect them to be in order are coded
incorrectly IMHO.
Standing
[
http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12358568
]
Jim Gallacher commented on MODPYTHON-93:
The FieldStorage methods get, getitems, has_key, __len__, getfirst and getlist
*all* iterate over the complete list of
17 matches
Mail list logo
