Why is CGI module so complicated?

[Michael P. Reilly]

Ian Clarke <I.Clarke at 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