[cgiapp] Re lease CGI::Application::Plugin::Header

[穴 澤 亮]

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