Hi Mark, Thanks for your reply. Your suggestion meant a lot to me :)
I think CGI::Header::Props is not the replacement for CGI.pm, but complements CGI.pm. Though I agree CGI.pm is dated, the query class can't be replaced with another module like Plack::Request or Plack::Response in some cases (Unfortunately, I met those cases). That's why I need CGI.pm-compatible header props. handlers. I'm not interested in rewriting CGI.pm. My goal is to *deconstruct* CGI.pm itself. > - The docs open by comparing it to CGI::Header, but I think most people > will be coming from CGI.pm instead. I can understand why you would > thinking of the comparison the author, but I wouldn't assume it's > something readers would be familiar with. I agree with you. > - I think the most important thing is to say more right up front about > why the module exists. If you are are already using CGI.pm, why would > use this? I agree with you. CGI::Header::Props helps you handle header props. *consistently*. > - It still references a "query object", which is defaults to CGI.pm. > Again, if the goal is to be a substitute for CGI.pm, why CGI.pm is being > used here could be better explained. CGI::Header::Props is not a substitute for CGI.pm, but complements CGI.pm. > - In the docs for rehash(), I see that the canonical form of args is > made to be with the leading dashes. Instead, could be it /without/ the > dashes, unless they are required for particular attributes? I don't think so. The rehashed header props. might be flattened into a list of the key-value pairs and then passed to CGI.pm's header() method directly: use CGI qw/header/; my $rehashed_header_props = { -type => 'text/plain' }; print header( %{$rehashed_header_props} ); If keys of rehashed header props. don't start with a dash, CGI#header will behave unexpectedly: print header( type => 'text/plain' ); # doesn't work as you expect CGI::Application generates CGI response headers in the above way. See CGI::Application#_send_headers. CGI::Application#header_props returns a list of header props. Therefore, the current solution (with dashes) is most conservative. It's ugly, but it works. > - I realize CGI::App still refers to a "query object", but it is a dated > concept, and one that the next major version of CGI::App will address. I > suggest instead refering to a "response" or "request", depending on > which part of the HTTP cycle you are referring to. Of course, if you > referencing CGI::App's current "query" method, there's not much choice > then to call it that for now. That's true. I'm waiting for CGI::Application/PSGI::Application which implements response() or request() method :) > - My feedback about improving the opening description applies to the > CGI::App plugin as well. Those docs currently say: > > "This plugin provides a way to handle CGI.pm-compatible HTTP header > properties." > > The framework already does that. Spell otu right up front how this > plugin is different and/or better than the built-in methods. That's true. My docs lacks "why" ;) Thanks for your suggestion :) Sincerely, Ryo ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################