[albatross-users] New feature discussion - browser request merging

[Dave Cole]

We have been bitten by a subtle bug in one of our applications and
have decided that it is not unreasonable to expect Albatross to lend a
hand in preventing the problem from happening.

The problem revolves around the way that browser requests can contain
multiple instances of the same input field.  The cgi module handles
this by attaching a list of field values to a single input field in
the cgi.FieldStorage object.  Albatross then merges those values into
the execution context local variables.  So a request like this:

        blah?a=1&b=2

will create ctx.locals values which are the same as these assignments:

        ctx.locals.a = '1'
        ctx.locals.b = '2'

When processing a request like this:

        blah?a=1&a=2&b=3

the values will end up like this:

        ctx.locals.a = ['1', '2']
        ctx.locals.b = '3'

This can lead to some obscure problems in your application when you
are expecting a list of values to be supplied by the browser and only
one value is submitted.  Typically you have to write code which looks
like this:

        if type(ctx.locals.a) is type([]):
            for v in ctx.locals.a:
                somefunc(v)
        elif ctx.locals.a is not None:
            somefunc(ctx.locals.a)

If you forget the type test and assume a list of values you are going
to end up calling somefunc() for each letter in the single value for
the a field.  Oops.

We are thinking about requiring a new attribute on the <al-input> tag
when you expect multiple values for the associated field name.  This
will tell Albatross to always provide a list of values for that input
field regardless of how many are seen in the browser request.  It will
also allow you to write code without the type test, i.e.:

        for v in ctx.locals.a:
            somefunc(v)

What is more, if you do not include the attribute on the <al-input>
tag, and your program tries to send a form with multiple fields with
the same name, then Albatross will raise an exception.

The upshot will be that the hard to find obscure error will be almost
impossible to trigger.  I can't think of any way around the scheme,
but I am sure that there is one...

I suggest we introduce the attribute MULTIPLE:

        <al-input type="checkbox" name="extras" value="cheese" multiple>
        <al-input type="checkbox" name="extras" value="onion" multiple>

For a browser request like this:

        blah?extras=cheese&extras=onions

the locals will be set like the following:

        ctx.locals.extras = ['cheese', 'onions']

For a browser request like this:

        blah?extras=cheese

the locals will be set like the following:

        ctx.locals.extras = ['cheese']

For a browser request like this:

        blah?type=spam

the locals will be set like the following:

        ctx.locals.type = 'spam'
        ctx.locals.extras = []


It almost goes without saying that if you send a form containing input
fields with inconsistent multiple settings that an exception will be
raised.

Comments or questions?

- Dave

-- 
http://www.object-craft.com.au