The contract of the callback is this: - it is either executed -or- the entire gadget is reloaded
so, if you stay on the same page when sharing the app (ie with a pop up or something) then you have to call the callback. if you go through an different page flow entirely then its fine for the gadget to just have its onload handler called. which means, that as far as the spec goes your implementation is good. it does seem like we may want to give developers a way to know what happened though... or the ability to request a view to navigate to like you said. perhaps propose something on the spec mailing list if you figure out a good way to do it. I hope that helps. - cassie On Fri, Mar 21, 2008 at 9:24 AM, Lou Moore <[EMAIL PROTECTED]> wrote: > Has anyone else implemented requestShareApp yet? Just got started on our > implementation, and we have it all working except the callback. We register > requestShareApp as an rpc method which sends the user to our invite page, > passing along the reason and callback, and on completion we send them back > to the view they came from. What was the thinking on how containers are > expected to invoke the specified callback at that point? Also, it seems like > it might actually be more useful to just pass along view-params similar to > requestNavigateTo, as the desired behavior for developers is really just to > show a specific post-invite page to the user, but the spec calls for a > callback function instead. > > Or, are we going about this in a totally unexpected way? > > Thanks, > Lou > > _______________________________________________ > Hi5-opensocial mailing list > [EMAIL PROTECTED] > https://mailman.corp.google.com/mailman/listinfo/hi5-opensocial > >
