>> > 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. >> >> Above applies only when gadget type="html". If type="url", libs >> includes not only "focedLibs" but also features gadget XML requires. >> >> Am I right? > > > Not quite -- if the gadget requires a feature not in the forced set, it'll > inline it into the html document. This allows for the best balance of total > http requests to overall cache performance.
Oh, OK. That's the part I forgot to copy as reference, but seems like my understanding was right. Thanks a lot taking your time to answer my silly questions. It was really helpful! >> 2008/6/27 Kevin Brown <[EMAIL PROTECTED]>: >> > On Thu, Jun 26, 2008 at 7:03 PM, Eiji Kitamura <[EMAIL PROTECTED]> >> wrote: >> > >> >> I guess I'm understanding what it does and how it works. >> >> The point was, why shindig needs to obtain libs as part of url >> >> parameter despite it's right there in config.php. >> >> >> >> Cache doesn't seem to matter because combination of javascripts (libs) >> >> should be cached anyway the first time shindig renders it, even if SNS >> >> have multiple gadgets in one page. >> >> >> >> >> >> if it's just the way it works, that's fine. >> >> I just wanna know if there's any particular reason. >> > >> > >> > libs is not static. It can vary depending on which gadgets are being >> > rendered. There's no way for an individual gadget to know what libraries >> > other gadgets rendered at the same time need, so the container has to >> tell >> > each gadget which libraries to use. If you didn't do this, shindig would >> > have to load a different library set for *every* gadget render, resulting >> in >> > really poor performance. >> > >> > >> >> >> >> 2008/6/26 Chris Chabot <[EMAIL PROTECTED]>: >> >> > Actually what shindig does is it looks at the gadget xml and distills >> a >> >> list >> >> > of required features (and their dependencies) >> >> > >> >> > loop through all required_and_optional_features: >> >> > if the lib is included in the libs=...:..:.. >> >> > append it to the $external_libs_string >> >> > else >> >> > append the javascript code to $inlined_javascript >> >> > >> >> > echo <script src="/gadgets/js/$external_libs.js"> >> >> > echo $inline_libs >> >> > >> >> > So it's not a 'if their not specified on the url things break' kind of >> >> thing >> >> > at all, why would we make something broken by design ? :-) >> >> > >> >> > It's just a way to specify which libs should be included through an >> >> external >> >> > reference, and which should be inlined into the document. >> >> > >> >> > When in doubt, you can always look at the source, in this case it's in >> >> > src/gadgets/http/GadgetRenderingServlet.php line 154. >> >> > >> >> > -- Chris >> >> > >> >> > On Jun 26, 2008, at 11:50 AM, Kevin Brown wrote: >> >> > >> >> >>> I meant, what if SNS does not provide "libs" param in gadget url >> inside >> >> >>> iframe. >> >> >>> Shindig still should be able to detect required "libs" since they >> are >> >> >>> in config.php and can ommit unnecessary features gadget XML requires >> >> >>> when rendering. >> >> >> >> >> >> >> >> >> If you don't provide it, shindig will automatically figure out what >> to >> >> use >> >> >> -- you'll just get fewer cache hits and overall worse performance. >> >> > >> >> > >> >> >> > >> >
