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

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");

because.....

>> - 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"

Regards,

Phil.