Boost logo

Boost :

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-08-20 06:54:28

Darren Garvey wrote:
> On 19/08/07, Phil Endecott <spam_from_boost_dev_at_[hidden] > wrote:
>> - I think it's important, especially for a Boost library, that you
>> supply standard-library-like interfaces where possible. For example, I
>> would like to see the form variables having a std::map-like interface.
>> (This would be most easily achieved by actually making them a std::map,
>> but if you choose some other implementation structure then you can use
>> Boost.Iterator to help with the interface). This would allow me to
>> iterate through them. At present, I don't think you have a way to get
>> the names of all the form variables.
> Oops, forgot to document this! There is a way to do this actually:
> 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"];

rather than

   string frob = req.meta_form("frob");


>> - In the '10 minute intro', you have:
>> std::string user_name( req.meta_cookie("user_name") );
>> if (!user_name.empty()) { ....
>> So is it impossible to distinguish between an empty string and a form
>> or cookie value not being set?
> Not really... I was thinking about this earlier and it could be done easily
> enough (I won't go into it, if you don't mind), but it would be a bit ugly,

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

> 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'm not sure about the idea of sending the response to the request
>> object. I would think of the request object as a const thing. When I see
>> req << "something..."
>> I thing that that's something that should only happen when the
>> request object is being created e.g. to set the POST data. In my apps
>> I have always had a handler function that returns a response:
>> HTTP::Response handle ( const HTTP::Request& req ) { ... }
>> but this doesn't fit as well into your arrangement.
> I'm not sure I follow. The request object doesn't support operator<<.

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"



Boost list run by bdawes at, gregod at, cpdaniel at, john at