in reply to SOAP::Lite and Moose. Moose and SOAP::Lite

You have uncovered the ugly guts of MooseX::Declare here.

One of the biggest issues with MooseX::Declare (IMO at least) is that it exposes too much of it's internal workings with the error messages which makes them really difficult to read and understand (this will eventually get fixed, but it is still a relatively new module). As best I can tell it looks like your calling normalize as a class method and not as an instance method. You might want to try changing the method signature for normalize to 

method normalize(Str :$class, HashRef $address) { ... }

[download]
So you are being more specific about what you expect the invocant to be.

It should be noted that MooseX::Declare is still pretty cutting edge stuff, you might have more success starting with plain Moose first, then porting to MooseX::Declare once you have the details worked out.

-stvn

Replies are listed 'Best First'.
Re^2: SOAP::Lite and Moose. Moose and SOAP::Lite
by desoto (Novice) on Nov 13, 2009 at 17:20 UTC

    I wish my project wasn't on such a tight deadline, because I'd really like to get to know this MooseX::Declare. There's obviously a lot I don't know about it, but it seems like it's a tremendous simplification of the existing Moose object structure which is a tremendous simplification of the existing Perl object structure.

    I took your advice and backed off to Moose. What you said about class method vs. instance method is correct. Moving to Moose didn't eliminate that problem and honestly it took me several more hours to figure out that I wasn't going to solve that problem.

    I know that SOAP should allow initializing and calling objects as if the SOAP service were on the local machine. That was what I was attempting, however, I couldn't figure it out. So I devised a work around that I'm sure pure SOAP proponents would find appalling. But I reevaluated my requirements and determined that I could get by without this functionality.

    My SOAP::Lite server now calls a module that looks like this:

    package API;

use API::Translator;
use Moose;

sub normalize {
    my ($class, $address) = @_;
    my $service = API::Translator->new();
    return $service->normalize($address);
}

    [download]

    This pushes initialization of the API::Translator object behind the SOAP server allowing use to reference methods within that object without issue. It's not a solution I'm completely happy with, but it works.

    In retrospect, I'm sure there is a way I can bless the hashref of the object that gets passed through the SOAP server to avoid this middle man class, but like I said above, sometimes the timeline dictates the direction you go.

    I appreciate your direction. Thank you.

[reply]
[d/l]

In Section Seekers of Perl Wisdom