[Web-SIG] Random thoughts

Thijs van der Vossen t.vandervossen at fngtps.com
Mon Nov 3 07:50:43 EST 2003


On Monday 03 November 2003 13:31, Steve Holden wrote:
> > Before asking _how_ we might first want to decide if we
> > _should_. What's wrong
> > with having both a 'parameters' (query params) and a
> > 'form-data' (posted form
> > data) dictionary as attributes of the request object?
> >
> > In your code you could merge these two with a single line of code:
> >
> >   merged = request.parameters.update(request.form-data)
> >
> > Where the posted form data will overwrite the query
> > parameters with the same
> > name. You can also do this the other way round ofcourse.
>
> Of course, you *could*. But you will find that whatever you choose to
> do, there will be users whose use cases don't fit your choices. And, of
> course, if you choose to offer all possible alternatives then some
> people will complain that it's too complicated.

I agree. The best choice in cases like these IMHO is indeed not to add all 
possible alternatives to an api, but to write solid and comprehensive 
documentation explaining the easiest way to get to those alternatives in the 
calling code.

Adding an additional attribute to the request object containing the merged 
data is useless if you can do this yourself in one line of code.

> On balance, your suggestion seems the most practical except for the
> naming (form-data is not a valid name). Maybe formargs and queryargs, or
> formdata and querydata, or some such, leaving the user to merge the two
> sets as (and only when) required.

Naming was just an example following the earlier posts. I suggest 'post' (the 
only way to post form data is using a HTTP POST request) and either 
'arguments', 'parameters' 'queryargs' or 'queryparams' for the query 
parameters.

Regards,
Thijs

-- 
Fingertips __ www.fngtps.com __ +31.(0)20.4896540




More information about the Web-SIG mailing list