>The one-time bulk preloaded of gadget metadata and security tokens are for >server-side inlined data, avoiding XHR.
Right -- and that's exactly what we're looking to do (avoiding those XHR calls) however at the time we construct our common container instance we don't already have all of the metadata/tokens all gathered up to pass to the constructor. In our use case we have a JavaScript array of mixed "widget" objects on the client side (OpenSocial gadgets, W3C widgets, ...) which we enumerate through at render time, and for any OpenSocial gadgets we end up delegating off to common container for rendering services. We could of course just enumerate that array twice -- once to build up the preload data to pass to the common container constructor and then again to do the actual rendering of gadgets -- but with the ability to incrementally preload metadata/tokens we wouldn't have to. >We also have incremental (xhr-style) >gadget preloading -- osapi.container.preloadGadget() -- and it will cache >metadata on top of what has been preloaded (via both one-time/server-side >or >incrementals before hand). Not sure why you'd need to incrementally preload >tokens, CC keeps track of security-token-requiring gadgets that have been >navigated (displayed on page) and preloaded (cached, not displayed) and >update their security tokens accordingly. > > >On Tue, Aug 16, 2011 at 12:05 PM, Paul Lindner <[email protected]> wrote: > >> This sounds like a good idea. Michael, John wdyt? >> >> On Tue, Aug 16, 2011 at 11:45 AM, Ciancetta, Jesse E. ><[email protected]>wrote: >> >>> Hi All, >>> >>> Common container currently supports a one-time bulk preload of gadget >>> metadata and security tokens via the opt_config parameter passed to the >>> Container constructor, however it would also be useful to have a way to >>> incrementally preload this data as well. >>> >>> We're currently doing this in Apache Rave by calling the private >>> container.preloadFromConfig_ function for each of our gadgets before >calling >>> container.navigateGadget which seems to work just fine, but we obviously >>> don't want to continue to rely on a private function. >>> >>> Would anyone be opposed to a patch to making the preloadFromConfig_ >>> function public and adding it as part of the formal common container >>> specification? >>> >>> Thanks, >>> >>> --Jesse >>> >>> -- >>> You received this message because you are subscribed to the Google >Groups >>> "OpenSocial and Gadgets Specification Discussion" group. >>> To post to this group, send email to >>> [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en. >>> >>> >> >> >> -- >> Paul Lindner -- [email protected] -- linkedin.com/in/plindner >>
