Re: [cgiapp] Re lease CGI::Application::Plugin::Header
Hi,
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 wrote a patch to solve this problem:
https://github.com/markstos/CGI--Application/pull/9
# 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/ ##
####
Re: [cgiapp] Re lease CGI::Application::Plugin::Header
On 03/25/2013 02:55 PM, Ryo Anazawa wrote: Hi all, Thanks for maintaining CGI::Application. I'll release yet another CGI::Application plugin, CGI::Application::Plugin::Header, on CPAN soon. I've taken a second look at this, and have some more feedback on it. - 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 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? It's my understanding that it could be part of a solution of depending on less on CGI.pm, but I think it could be spelled out better. - 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? - 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. - 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. - 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. Mark # 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/ ## ####
Re: [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
# 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/ ##
####
Re: [cgiapp] Re lease CGI::Application::Plugin::Header
Hi Ryo
Why on earth do you use a '-' prefix on parameters?
That is user-hostile code, like the '--' required on the command line
for (some) apps.
Yes, I know that many, many years ago '--' was used to distinguish
between command line parsers, where the original used '-', but that's a
red herring these days.
On 26/03/13 05:55, Ryo Anazawa wrote:
Hi all,
Thanks for maintaining CGI::Application.
I'll release yet another CGI::Application plugin,
CGI::Application::Plugin::Header, on CPAN soon.
This plugin adds the header() method to your CGI app which helps you handle
CGI.pm-comptible HTTP header properties.
Since header() is compatible with the existing handlers such as header_type,
header_props, header_add,
it will not break your application.
You can use header() as follows:
package MyApp;
use parent 'CGI::Application';
use CGI::Application::Plugin::Header 'header';
sub do_something {
my $self = shift;
my $type = $self-header('-type'); # getter
# setter
$self-header(
-charset = 'utf-8',
-type = 'text/plain,
);
my $header = $self-header; # returns CGI::Header::Props object
}
FEATURE
- You can pass key-value pairs of header props. to header().
Unlike header_props(), header() *merges* the pairs into the existing
header props.
- CGI::Header::Props implements push_cookie() and push_p3p() methods. These
methods behave like CGI::Application#header_add.
- Normalizes property names automatically (-Content_Type - -type), and
so you can specify them consistently.
CAP::Header is still in development. You can download the latest code in the
following repository:
https://github.com/anazawa/p5-CGI-Header-Props
I'm waiting for your suggestions. Patches are welcome :)
Thanks,
Ryo
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# 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/ ##
####
Re: [cgiapp] Re lease CGI::Application::Plugin::Header
On 03/25/2013 05:04 PM, Ron Savage wrote:
Hi Ryo
Why on earth do you use a '-' prefix on parameters?
While I wouldn't use the - prefix in documentation or otherwise
promote it, I could see silently or quietly *supporting* it, if one one
of your objectives is to be CGI.pm-compatible.
He stated that one of his goals is CGI.pm-comptible HTTP header
properties.
I'll take a look at the code. Thanks for the contribution, Ryo.
Mark
That is user-hostile code, like the '--' required on the command line
for (some) apps.
Yes, I know that many, many years ago '--' was used to distinguish
between command line parsers, where the original used '-', but that's a
red herring these days.
On 26/03/13 05:55, Ryo Anazawa wrote:
Hi all,
Thanks for maintaining CGI::Application.
I'll release yet another CGI::Application plugin,
CGI::Application::Plugin::Header, on CPAN soon.
This plugin adds the header() method to your CGI app which helps you handle
CGI.pm-comptible HTTP header properties.
Since header() is compatible with the existing handlers such as header_type,
header_props, header_add,
it will not break your application.
You can use header() as follows:
package MyApp;
use parent 'CGI::Application';
use CGI::Application::Plugin::Header 'header';
sub do_something {
my $self = shift;
my $type = $self-header('-type'); # getter
# setter
$self-header(
-charset = 'utf-8',
-type = 'text/plain,
);
my $header = $self-header; # returns CGI::Header::Props object
}
FEATURE
- You can pass key-value pairs of header props. to header().
Unlike header_props(), header() *merges* the pairs into the existing
header props.
- CGI::Header::Props implements push_cookie() and push_p3p() methods. These
methods behave like CGI::Application#header_add.
- Normalizes property names automatically (-Content_Type - -type), and
so you can specify them consistently.
CAP::Header is still in development. You can download the latest code in the
following repository:
https://github.com/anazawa/p5-CGI-Header-Props
I'm waiting for your suggestions. Patches are welcome :)
Thanks,
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/ ##
####
Re: [cgiapp] Re lease CGI::Application::Plugin::Header
Hi Mark But supporting it adds complexity for no gain :-(. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # 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/ ## ####
Re: [cgiapp] Re lease CGI::Application::Plugin::Header
Hi
On 26/03/13 14:31, Ryo Anazawa wrote:
Thanks for your reply.
I wouldn't use a '-' prefix, too, and so I'll remove the prefix from
SYNOPSIS.
Excellent!
I agree we shouldn't promote it. SYNOPSIS should be as follows:
Excellent!
sub do_something {
my $self = shift;
my $type = $self-header('type'); # getter
# setter
$self-header(
charset = 'utf-8',
type = 'text/plain,
);
}
However, CGI.pm' header() method requires the prefix in some cases:
Yes, that's where the problem starts.
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# 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/ ##
####
Re: [cgiapp] Re lease CGI::Application::Plugin::Header
Thanks for your reply. Yes, that's one of my goals. Mark Stosberg wrote: He stated that one of his goals is CGI.pm-comptible HTTP header properties. Thanks for your suggestion :) Best regards, Ryo -- View this message in context: http://old.nabble.com/Release-CGI%3A%3AApplication%3A%3APlugin%3A%3AHeader-tp35216388p35217976.html Sent from the cgiapp@lists.erlbaum.net mailing list archive at Nabble.com. # 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/ ## ####
