Loading ...
Sorry, an error occurred while loading the content.

Adding methods on the client side?

Expand Messages
  • quinn@fetter.org
    O.K., I don t know if this is considered Horribly Bad Practice, but... I m working on some classes where I want some of the methods (maybe just new) to run on
    Message 1 of 4 , Sep 23, 2002
    • 0 Attachment
      O.K., I don't know if this is considered Horribly Bad Practice, but...

      I'm working on some classes where I want some of the methods (maybe
      just new) to run on a server via SOAP, but I want others (say, the
      business logic) to be defined and run on the client side.

      One way to achieve this is to cram subroutine references into the
      object's namespace at run time:

      Class::method_name = sub { "..." };

      I'm wondering whether anyone else has felt this need, and whether
      they've come up with some more elegant way of doing it. I'd also be
      interested to hear overall critiques: Does this seem like a reasonable
      thing to do? Am I violating some design rule of SOAP in even thinking
      about it?

      If my approach is the best we can come up with, maybe I'll make a nice
      CPAN module to abstract over this functionality (so you can write up
      your client-side method definitions in a file, use a magic module, and
      have them loaded into the class's name space--maybe at compile time).

      Cheers,
      --Q

      PS: Now that I'm on the list, I'd like to thank Paul for making such
      a great package. For such a complex problem domain, it provides a
      wonderfully simple interface. Yay Paul!
    • Paul Kulchenko
      Hi Quinn, ... While it s possible to do the way you described there is no need to do that in most cases. SOAP::Lite supports direct (when you explicitly
      Message 2 of 4 , Sep 23, 2002
      • 0 Attachment
        Hi Quinn,

        > One way to achieve this is to cram subroutine references into the
        > object's namespace at run time:
        >
        > Class::method_name = sub { "..." };
        While it's possible to do the way you described there is no need to
        do that in most cases. SOAP::Lite supports direct (when you
        explicitly specify the method name) and indirect invocation (when
        autodispatch mode is used). In both cases only methods that don't
        exist locally will be called, but it's possible to override this
        behaviour using SOAP:: prefix (in which case remote methods will be
        accessed even if local twins are defined).

        Still I don't see why you can't do it your way ;)

        > CPAN module to abstract over this functionality (so you can write
        > up
        > your client-side method definitions in a file, use a magic module,
        > and
        > have them loaded into the class's name space--maybe at compile
        > time).
        I don't think I got this one, so I may be answering the wrong
        question ;). Could you elaborate?

        Best wishes, Paul.

        --- quinn@... wrote:
        > O.K., I don't know if this is considered Horribly Bad Practice,
        > but...
        >
        > I'm working on some classes where I want some of the methods (maybe
        > just new) to run on a server via SOAP, but I want others (say, the
        > business logic) to be defined and run on the client side.
        >
        > One way to achieve this is to cram subroutine references into the
        > object's namespace at run time:
        >
        > Class::method_name = sub { "..." };
        >
        > I'm wondering whether anyone else has felt this need, and whether
        > they've come up with some more elegant way of doing it. I'd also
        > be
        > interested to hear overall critiques: Does this seem like a
        > reasonable
        > thing to do? Am I violating some design rule of SOAP in even
        > thinking
        > about it?
        >
        > If my approach is the best we can come up with, maybe I'll make a
        > nice
        > CPAN module to abstract over this functionality (so you can write
        > up
        > your client-side method definitions in a file, use a magic module,
        > and
        > have them loaded into the class's name space--maybe at compile
        > time).
        >
        > Cheers,
        > --Q
        >
        > PS: Now that I'm on the list, I'd like to thank Paul for making
        > such
        > a great package. For such a complex problem domain, it provides a
        > wonderfully simple interface. Yay Paul!
        >
        >
        > ------------------------ Yahoo! Groups Sponsor
        >
        > To unsubscribe from this group, send an email to:
        > soaplite-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        >
        >


        __________________________________________________
        Do you Yahoo!?
        New DSL Internet Access from SBC & Yahoo!
        http://sbc.yahoo.com
      • Chris
        Well you can move this to compile time by wrapping it into a BEGIN block ... but I think traditionally you would use a wrapper object that dispatches some of
        Message 3 of 4 , Sep 24, 2002
        • 0 Attachment
          Well you can move this to compile time by wrapping it into a BEGIN
          block ...

          but I think traditionally you would use a wrapper object
          that dispatches some of it's methods to the SOAP handler and handles the
          business logic locally.

          > O.K., I don't know if this is considered Horribly Bad Practice, but...
          >
          > I'm working on some classes where I want some of the methods (maybe
          > just new) to run on a server via SOAP, but I want others (say, the
          > business logic) to be defined and run on the client side.
          >
          > One way to achieve this is to cram subroutine references into the
          > object's namespace at run time:
          >
          > Class::method_name = sub { "..." };
          >
          > I'm wondering whether anyone else has felt this need, and whether
          > they've come up with some more elegant way of doing it. I'd also be
          > interested to hear overall critiques: Does this seem like a reasonable
          > thing to do? Am I violating some design rule of SOAP in even thinking
          > about it?
          >

          -Chris
        • quinn@fetter.org
          ... OK, I get it now. All I do is define the client-side methods on the client (e.g. by writing and use ing a module whose package name is the name of the
          Message 4 of 4 , Sep 24, 2002
          • 0 Attachment
            On Mon, Sep 23, 2002 at 07:12:55PM -0700, Paul Kulchenko wrote:

            > Hi Quinn,
            >
            > > One way to achieve this is to cram subroutine references into the
            > > object's namespace at run time:
            > >
            > > Class::method_name = sub { "..." };
            > While it's possible to do the way you described there is no need to
            > do that in most cases. SOAP::Lite supports direct (when you
            > explicitly specify the method name) and indirect invocation (when
            > autodispatch mode is used). In both cases only methods that don't
            > exist locally will be called, but it's possible to override this
            > behaviour using SOAP:: prefix (in which case remote methods will be
            > accessed even if local twins are defined).

            OK, I get it now. All I do is define the client-side methods on the
            client (e.g. by writing and use'ing a module whose package name is the
            name of the class the SOAP service exposes). Then the local code will
            work just as I desired. Ah, much better. :)

            > Still I don't see why you can't do it your way ;)

            Nope, I like this one better... see below.

            > > CPAN module to abstract over this functionality (so you can write
            > > up
            > > your client-side method definitions in a file, use a magic module,
            > > and
            > > have them loaded into the class's name space--maybe at compile
            > > time).
            > I don't think I got this one, so I may be answering the wrong
            > question ;). Could you elaborate?

            Actually, I was just wishing for the functionality you described above,
            where all you have to do is define a module on the client side. I was
            thinking you'd have to do some kind of magic to make that work, but
            evidently you don't. Cool. :)

            I guess this is because autodispatch uses AUTOLOAD, so that SOAP never
            even gets involved unless the method is undefined.

            Thanks for clearing this up, and thanks again for SOAP::Lite. :)
          Your message has been successfully submitted and would be delivered to recipients shortly.