Chris can verify that this has all been implemented in the PHP implementation as well, but that is definitely how it works on the Java side. This is all just an optimization technique, though, and isn't required for rendering.
What I recommend is passing the same value for "libs" (made up of either all features that you support, or of the most common features) to every gadget that you render so that the file can be cached across page views, and gadgets that need different libraries can load them inline. This seems to be the best balance of http requests against file size. On Tue, Jun 24, 2008 at 7:53 PM, Eiji Kitamura <[EMAIL PROTECTED]> wrote: > Hi, > > > I'm trying to figure out what Shindig (PHP) doing on loading javascripts. > Can anyone tell me if my understanding is correct. > > 1. Container can specify javascript sets (features) which will be > loaded every time any of gadgets get rendered. This works like DEFAULT > feature sets, and is called "libs". > Libs can be specified by setting "focedJsLibs" (not forcedJsLibs :) ) > to feature strings concatenated with colon in /shindig/php/config.php. > Libs will be loaded on client side with script tag, so that browser > can cache it. > > * Gadget iframe will have source url as something like: > <iframe src=" > > gmodules.com/gadgets/ifr?url...&libs=opensocial-0.7:dynamic-height:setprefs& > .. > ."> > > * Rendered HTML will have following: > <script type="javascrip"> > http://sandbox.gmodules.com/gadgets/js/settitle:dynamic-height.js</script> > > > 2. Gadgets can specify features which will be loaded when only that > particular gadget gets rendered. > Features can be specified by setting "/ModulePrefs/[EMAIL PROTECTED]". > Features specified by gadgets will be loaded inline in > shindig-rendered HTML when it's type="html". > Features included in "lib" will be omitted. > > If there's any other tricks, I'd be glad to know. >
