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

Re: [soaplite] Adding methods on the client side?

Expand Messages
  • 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 1 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 2 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 3 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.