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

From: Darren Garvey (lists.drrngrvy_at_[hidden])
Date: 2007-08-24 22:31:31

Hi Phil, sorry for the late response.

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.

Plus, I'm not too keen on allowing direct access to the variables. 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?

> 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).

<!-- snip -->
>
> Err OK.  I was probably confused by "rep" and "req" not differing by
> many pixels, and this line from the Quickstart:  "You can  write to the
> request object directly, but for now we're going to just use the reply,
> which is simpler. Writing to a reply is buffered - whereas writing to
> the request directly isn't"

No problem. I'll fix this, thanks.

Regards,
Darren