Re: [Fastcgipp-users] Question about multi selections

[Volker Schreiner]

Imagine you are creating a user element that can be added to one or more
groups. I would prefer to
give the creator the option to select one or more groups from a <select
name="group" size="6" multiple>
instead of selecting one group and adding the remaining groups
afterwards with multiple calls and clicks.
In PHP you have the ability to give the select a name like
name="groups[]" and the selected items get
inserted into an array with the name groups. There you get all selected
itmes.

The current way fastcgi++ library handles the parameter parsing is a
subset of the functionality you can
use with PHP. It does not support the whole spectrum that html or http
gives you.

I think it is not neccessary to break everything to implement this
feature. Just implement a third type of post data
(file, form, and formmulti or something like that) and in case a
parameter is already set with this parameter you
create a std::list<std::string> that contains the multiple values for
this parameter. This list can be accessed by a
second data() method that returns a pointer to the std::list and not to
a const char pointer.

I think the amount of work that is needed to implement this feature is
not that high as the acceptance of the fastcgi++
library will grow.

best regards

Volker Schreiner

Am 06.01.2012 18:49, schrieb Eddie Carle:
> On Sat, 2011-12-31 at 15:48 +0100, Volker Schreiner wrote:
>> Is it possible to read the selections of a html selection element
>> which is defined as multiple? In my test application the
>> environment.findPost method returns an element whose value is the last
>> selected element of the HTML selection. I think this behavior is
>> caused by the initialization of the post parameters where the entry
>> for a parameter name is overwritten without any handling for already
>> initialized parameter name/value pairs.
>>
>> Is the handling of multi selections already implemented and i do not
>> get it work yet? Or is it not yet implemented and if so is there any
>> plan to implement this feature?
> This is an interesting point. When I first starting coding that part I
> couldn't imagine in my mind any scenario where someone would want to
> have to POST/GET values with the same name. I guess it is something
> should get consideration but it makes things a little complicated. Right
> now it is all just implemented as a map. Changing it to a multi-map
> would actually break everything as then you are being returned data sets
> instead of actual values.
>
> Just out of curiosity, what grand purposes would warrant such a
> functionality? You must have a good reason to have brought it up to
> begin with.