Darren Garvey wrote:
On 19/08/07, Phil Endecott <spam_from_boost_dev@chezphil.org > 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.