Coerce and messages

[Bill Moseley]

I'm going to build a request with HTTP::Request::Common and want to use its existing methods (POST, PUT, GET, etc.) 

I'm curious how to control the error message better when coercing.

My class gets an HTTP method name as an attribute, and I wanted to validate it for how it will get used:

subtype HttpMethod =>

    as 'Str',

    where { HTTP::Request::Common->can( $_ ) },

    message { "The method provided [$_] does not appear to be a valid HTTP method" };

has http_method => (

    is => 'ro',

    isa => 'HTTPMethod',

    required => 1,

);

So, that generates a nice error message.

This is ugly, but to build the request I was then doing:

my $sub = HTTP::Request::Common->can( $self->http_method );

my $http_request = $sub->( $url, @args );

I thought I'd coerce the method name to that code reference and I would then use just:

my $http_request = $self->http_method->( $url, @args );

Not sure I have this correct, but the code to coerce is now:

subtype HttpRequestCode => as 'CodeRef';

subtype HttpMethod =>

    as 'Str',

    where { HTTP::Request::Common->can( $_ ) },

    message { "The method provided [$_] does not appear to be a valid HTTP method" };

coerce HttpRequestCode =>

    from 'HttpMethod' => via { HTTP::Request::Common->can( $_ ) };

has http_method => (

    is => 'ro',

    isa => 'HttpRequestCode',

    coerce => 1,

    required => 1,

);

I get an OK message:

Attribute (http_method) does not pass the type constraint because: Validation failed for 'HttpRequestCode' with value "PSOT"

but is there a way I can use my "message" while still coercing?

--
Bill Moseley
mos...@hank.org

[Karen Etheridge]

On Sun, Sep 28, 2014 at 01:27:53PM -0700, Bill Moseley wrote:
> I'm going to build a request with HTTP::Request::Common and want to use its
> existing methods (POST, PUT, GET, etc.)
>
> I'm curious how to control the error message better when coercing.

I'm lost - what is the advantage to storing the HTTP request method as a
subref, vs. as a string?

this may be of use for your validation check:
https://metacpan.org/pod/MooseX::Types::HTTPMethod

[Bill Moseley]

On Sun, Sep 28, 2014 at 4:52 PM, Karen Etheridge <pe...@froods.org> wrote:

On Sun, Sep 28, 2014 at 01:27:53PM -0700, Bill Moseley wrote:
> I'm going to build a request with HTTP::Request::Common and want to use its
> existing methods (POST, PUT, GET, etc.)
>
> I'm curious how to control the error message better when coercing.

I'm lost - what is the advantage to storing the HTTP request method as a
subref, vs. as a string?

No advantage, really.    It was more of a learning exercise with Moose, not so much solving the specific problem.

The code came from a non-Moose script that did this:

    my $sub = HTTP::Request::Common->can( $method )

        || die qq'Could not figure out how to process method "$method"';

   my $req = $sub->( @args );

So, moving it over to Moose I wanted to provide some validation, so I created the HttpMethod subtype.

subtype HttpMethod =>

    as 'Str',

    where { HTTP::Request::Common->can( $_ ) },

    message { "The method provided [$_] does not appear to be a valid HTTP method" };

That makes sense to validate it that way because that's how $method is going to get used, plus it provides a nice error message.

Since I needed that code ref anyway I thought I'd coerce it and then call ->can only once.   But, once I did that I didn't have my nice error message any more.

So, I was wondering if I could coerce yet still use my validation.

Thanks,

--
Bill Moseley
mos...@hank.org