gadgets.rpc - determining which gadget an rpc call originates from

[Arne Roomann-Kurrik <ku...@google.com>]

I've been doing a little bit of work with a test container rendering
multiple gadgets and was trying to set up gadgets.rpc.  As far as I can
tell, if I set the "name" property of the gadget iframe, I can access this
property under "this.f" in the RPC callback.  I was wondering whether this
was the expected way to tie a given iframe with an RPC response, and will it
work on every transport mechanism? Or is there some extra iframe
registration step I'm missing?

Thanks,
~Arne

Using the sample container to test

["Wang, Jeff (CTSI)" <Je...@ucsf.edu>]

I'm using Shindig-Java, and wrote my own PersonService.  The attachment via GuiceModules was pretty standard, I took the sample module, swapped out the sample service for mine.  This means, of course, that I have the sample OAuth implementation.  Now, when I go to the sample container, and look at the apps, all the UserId requests come in as "viewer", and all the token.getViewerId() and token.getOwnerId() are null.
I've played around with various reloads, reset buttons, entering different values in the Viewer and the Owner fields, they all give the same result.  Played around with the state being used, same thing.  Tried logging in with login.jsp, still same thing.  How do I use the sample container to give me some more interesting values to test against?

thanks
Jeff Wang

Re: gadgets.rpc - determining which gadget an rpc call originates from

[Kevin Brown <et...@google.com>]

On Fri, Jul 31, 2009 at 5:00 AM, Arne Roomann-Kurrik <ku...@google.com>wrote:

> I've been doing a little bit of work with a test container rendering
> multiple gadgets and was trying to set up gadgets.rpc.  As far as I can
> tell, if I set the "name" property of the gadget iframe, I can access this
> property under "this.f" in the RPC callback.  I was wondering whether this
> was the expected way to tie a given iframe with an RPC response, and will
> it
> work on every transport mechanism? Or is there some extra iframe
> registration step I'm missing?


Yes, it is what's expected. Unfortunately this behavior is documented in the
middle of the rpc.js source, so it's not so obvious how this should work.

I'd vote for making it more obvious by passing the arguments that are
attached to the scope to the first argument of the RPCs, but it's hard to do
that and be compatible 2 years after the fact.

I'd recommend using this pattern in the container to make gadgets.rpc more
usable:

function wrapRpcCallback(func) {
  return function() {
    var args = [{from: this.f, .. other fields...}];
    for (var i = 0, j = arguments.length; i < j; ++i) {
      args.push(arguments[i]);
    }
    func.apply(null, args);
   }
}

gadgets.rpc.register("showGadgetDescription",
wrapRpcCallback(function(context, arg0, arg1, ...) {
  var dataForGadget = getDataForGadget(context.from);
  alert(dataForGadget.description);
}));


>
>
> Thanks,
> ~Arne
>