[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fastcgipp-users] Question about multi selections

From: Volker Schreiner
Subject: Re: [Fastcgipp-users] Question about multi selections
Date: Sat, 7 Jan 2012 02:20:20 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16

I think the common way to send data from multi selections is the post
method but i am not sure.
It would also be possible to extend the GET data structures analogous to
the POST data structures
but i am not sure if its worth the time. For me it would be enought if
multi selections work for post data.
The std::list was the first thing that came into my mind for a
stringlist but the std::deque would also be a

Since there seems to be not enough c++ programmers available at the
moment you are right. There
would be no wide acceptance for c++ in the world wide web. I also like
things that are special but its
hard to find projects where you can use c++ in the web. Furhtermore if
your prefered library for c++
webdevelopment does not support such things like multi selection boxes
its much more harder to convince
some project leaders to use this technique.

Am 07.01.2012 01:35, schrieb Eddie Carle:
> On Sat, 2012-01-07 at 01:14 +0100, Volker Schreiner wrote:
>> 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.
> Well, you've convinced me. It does seem to have a purpose and would not
> be all that difficult to implement. I like your idea for using the POST
> type indicator to identify a multi, but what would be a similar solution
> for GET data in the query string? Moreover, I don't know if I would use
> an std::list. Why not just an std::deque? Do you have a specific
> motivation for suggesting an std::list?
> As far as fastcgi++ becoming more widely accepted, I think we all know
> that won't be happening any time soon. C++ is not a language that
> mainstream web developers will ever really embrace as the skills for its
> effective use do not exist widely enough within the community. It will
> always be relegated to the fringes of web applications and I couldn't be
> happier for it. It's what makes it special. I'd take badly written PHP
> over badly written C++ any day.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]