The one-time bulk preloaded of gadget metadata and security tokens are for server-side inlined data, avoiding XHR. 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 >
