http://qs321.pair.com?node_id=624203


in reply to Re: SOAP Modules (OO or not?)
in thread SOAP Modules (OO or not?)

Maybe I didn't explain too well, consider this plain module I use for handling SOAP requests... 
package SOAPServer;

use strict;
use warnings;

sub myfunction
{
    my $class = shift;

    my $self = {};
    
    bless ($self, $class);
    
    my $one = shift;
    my $two = shift;
    
    $self->{one} = $one;
    $self->{two} = $two;
    
    return $self;
}

1;

[download]
Is that okay on it's own, or should I create a new() sub to do the bless'ing? I'm sure it's more a question of "best practice" than anything else.

I'm just thinking that I'll soon have lots of sub's in the one module, so it'd obviously make sense to move the bless'ing stuff into a seperate private sub.

In the future one sub may indeed call other local subs, so if nothing else, blessing it to the class would make my code nicer to read with $self->fun2(), and let me structure the object nicely, and pass the whole thing back to the calling SOAP client.

Thoughts?

Replies are listed 'Best First'.
Re^3: SOAP Modules (OO or not?)
by jhourcle (Prior) on Jun 30, 2007 at 19:51 UTC

    So, if someone wanted to call the same method twice on the same object, you've managed to completely remove that ability.

    I guess you could do something like:

    sub myfunction {
    my $self = get_object( shift );

    ... # whatever's function specific, and not related to
        # creation of the object
}

sub get_object {
    my $self = shift;
    if ( !ref $self ) { return $self->new() } # a string?
    if ( UNIVERSAL::isa( $self, __PACKAGE__ ) { return $self }
    return __PACKAGE__->new();
}

sub new {
   ...
}

    [download]

    But, it doesn't seem like a very clean interface to me ... I mean, how can we tell what arguments should've been part of the object initialization, and what were arguments to the method call?

    Personally, I'm a user of SOAP::Lite, but I have a feeling that its history, having been created when SOAP was basically just a thin wrapper around XML RPC, was a problem, as almost all of the examples you find are these sorts of calls. I don't know that there is a good 'best practice' in how to deal with passing objects using SOAP::Lite. (if there is, I'd love to know about it myself)

[reply]
[d/l]
      yes, you couldn't call that same method twice, but in this situation I wouldn't, the method is the entrance into doing all the processing.

      Think of the first method as being a new() sub which does the blessing then passes straight on to another method where the actual processing occurs.
[reply]
Re^3: SOAP Modules (OO or not?)
by ForgotPasswordAgain (Priest) on Jun 30, 2007 at 17:00 UTC

    Since nobody else is saying anything, I'll just give my thoughts, which are as follows: WTF?!? You're instantiating an object of this class when calling some random method, like a method of the SOAP-exposed API? No, that's not good at all.

    BTW, if you're looking for a role model distribution on how to do your classes, SOAP::Lite is not it at all. Wondered why its development ground to a halt, I don't think it's coincidental.

[reply]
      Okay, a bit of background, I need a web service that 'internal' people will use, but could be developing their own front-ends.

      So I thought, use SOAP, send me some valid XML and I'll do what you want, the Object will deal, for arguments sake, with customers details.

      So someone can call the Customer service and send me new details to store in a DB, or alter an existing one, etc.

      Hopefully I'll keep it as a nice object internally to make calling further subs nice and easy, and also call more external modules.

      Any suggestions in this situation? I'll have around 10 such modules dealing with different things, and several methods for each one.
[reply]

In Section Seekers of Perl Wisdom