Ian Clarke <I.Clarke@strs.co.uk> wrote:
:> : Can anyone explain what the point of the FieldStorage and
:> : MiniFieldStorage objects are?
:> Ian, please read my reply in the previous thread:
:> http://www.dejanews.com/getdoc.xp/AN=502365247
: Well, unfortunately that link didn't work, but I managed to find the
: comment I believe you are referring to, in which case I assume you were
: indicating that the FieldStorage and MiniFieldStorage objects were used
: for the case where a file upload is taking place.
Nasty, dejanews changed the article number on me (I tested this with
lynx before I posted my article). But yes, that is the article.
The _exact_ URL that I have this morning (8-11-99 11:52EDT) is:
http://x21.deja.com/getdoc.xp?AN=511078528&CONTEXT=934386589.945881145&hitnum=0 : I can't help but feel that this is not the best way. How about go with
: the method I described in my first post (where cgi fields are returned
: as the types that they actually are, rather than being encased in
: MiniFieldStorage objects). Were more than one item is selected for a
: given field a list could be returned, and for a file upload a tuple
: could be returned containing the filename and the contents of the file -
: or if that is not considered extendable enough, a CGIFileUpload object
: could be returned containing the necessary fields.
I wondered why myself at first too, especially since a list is returned
instead of an object that looks like a list (with a value attribute),
when there are multiple fields returned (checkbuttons for example).
I usually have my own routine that converts the objects to a UserDict
(or a real dict) after I run them, unless I expect a file-upload in the
form. It's nothing major, but it helps. It's better to leave the
interface as it is (all fields return the same interface), I think it
works a little better in a HTML 4.0 view of the world.
: This would mean that for the vast majority of CGI fields which are just
: normal text, retrieval is very straight-forward and intuitive, just like
: accessing strings stored in a dictionary. More complexity is only
: introduced when the user wants to do more complicated stuff (and even
: then, it is pretty simple). As mentioned in my previous post, it would
: also allow the fields to be used as the substitutions for a
: TemplateDocument directly, which can be quite a useful trick.
There is a lot of information kept in the FieldStorage object which may
be desirable (like Content-Type parameters, Content-Length, etc.).
When using multipart/mixed instead of x-www-form-urlencoded, each field
(including non file-upload fields) can have these attributes. The
existing interface does not require a _lot_ of special coded to handle
the different cases in the CGI protocol.
: If I get some spare time today I will create a small module which will
: provide this interface to CGI (although if anyone else wants to do it,
: feel free!). It would obviously be better if (assuming I can convince
: others that this is a better way) this was integrated into the built-in
: cgi module.
I think the existing interface is fine, but a "simple" translater
around things might be good; something like:
def FieldStorage2Dict(form):
d = {}
def decode_field(field):
if isinstance(field, type([])):
return map(decode_field, field)
elif hasattr(field, "file") and field.file:
return (field.filename, field.file)
else:
return field.value
for key in form.keys():
d[key] = decode_field(form[key])
return d
What would be _really_ good (IMO) is to have a "toDict" method that
does this.
-Arcege