Re: [boost] [GSoC][cgi] Status update.

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-08-25 09:02:05

Hi Darren,

Darren Garvey wrote:
> On 20/08/07, Phil Endecott <spam_from_boost_dev_at_[hidden]> wrote:
>>
>> <!-- snip -->
>> > cgi::request req;
>> > cgi::map& form_map = req.meta_form();
>>
>> Good.  If I were you, I would advertise this as the primary way to
>> access the data, i.e.
>>
>>    string frob = req.form ["frob"];
>>
>> <!-- snip -->
>>
>> ...we all know how to do this with a std::map:
>>
>>    cgi::map::const_iterator i = req.form.find("frob");
>>    if (i==req.form.end()) {
>>      ....not set....
>>    } else {
>>      string frob = i->second;
>>      .......
>>    }
>>
>> (OK, you might think that's ugly too, but it's "standard ugly".  The
>> main point is that a user already knows how to do this, and doesn't
>> need to refer to your docs to discover your is_unset() function or
>> whatever.)
>
>
> I agree that the 'standard' way should be encouraged more. At the same time,
> the member function version has the advantage that there is no requirement
> to parse all of the variables unless it's needed, which is a bonus in the
> cast of POST data.

I think you could implement a map-like interface that parses the input 
lazily.  Presumably you have a parser for each form-data format that 
provides some sort of iterator-adapter, which takes a forward iterator 
over the character data and returns an iterator over name-value string 
pairs.  I think I've already suggested that these parsers should be 
accessible independent of the rest of the library.

> Plus, I'm not too keen on allowing direct access to the variables.

Why?

> What I
> put in for now seems (to me) like a reasonable compromise:
>
> request req;
> cgi::map& form_map = req.form_(); // returns the map of the form variables
> std::string name = req.form_()["name"]; // direct access like this
> name = req.form_()["name"]->first; // or even like this!
> BOOST_ASSERT( name == req.form_("name")); // shortcut to the above
> (obviously)
>
> The reasoning behind the trailing underscore, is to avoid req.get() and
> req.post(), which I think are misleading (as is req.get_var()). This is
> about the fifth iteration for these functions' names, but I quite like this
> one. Any better suggestions?

req.form_data

>> Note that [the data map] can't currently be used for environment
>> variables: this will
>> > probably change, but with the warning that it's going to be much slower
>> for standard CGI.
>>
>> Why?  I don't think getenv is particularly slow.
>> Actually a small library that implements a std::map-like interface to
>> the environment variables would be useful in itself.  I encourage you
>> to take every opportunity to make components that can be used
>> independently, as this could.
>
>
> I finally discovered `extern char ** environ;`. Exactly what's needed; I've
> added this so now access is uniform across variable types. :) (if you're
> interested: *http://tinyurl.com/2delnd* - it's not a 'map-like interface'
> though, it just copies the environment data into a map<string,string>. It
> probably needs profiling and tweaking too).

Well a const map<string,const char*> would probably be about as good as 
you can get, i.e. don't copy the values of the environment variables.

Regards,

Phil.