Hey Eiji,
Now that i got the last bug ironed out with the php support for this
feature (were one or two inclusion and dependency orderings that
needed some tweaking), i got a nice practical example for you that i
think will help explain what this does.
If you go to :
http://shindig.chabotc.com/gadgets/ifr?url=http://www.labpixies.com/campaigns/todo/todo.xml
You'll see that it includes the (server configured) forced JS libs
with an external script tag:
<script src="/gadgets/js/opensocial-0.7:dynamic-
height:setprefs:settitle.js?
v=f0251708822c9d83d5f1d245f95a0660&container=default"></script>
And you'll notice as well there is no inlined javascript in the
gadget, because all the features the gadget requires are already
included in that external javascript.
Now if i would remove the forcedJsLibs param from the shindig config,
all the javascript (some 50-60k depending on features required) would
be inlined inside of the html document.
If i would change it to something that only partially satisfies the
dependencies you would see a <script src="..some features"..>, and the
other features that are not included in the forced js libs, would be
inlined in the page.
Now the trick is to pick the features that are most commonly used, and
make those external, on partuza i have: 'focedJsLibs' =>
'opensocial-0.7:dynamic-height:setprefs:settitle', so that the
features that every gadget uses are already present in the browser
cache (the external <script..> reference has a expires header of 1
year, so cached indefinitely) and that saves tons on the page size per
gadget.
However you don't want to put every feature in there either, since
parsing the javascript takes time too, so if you put all the complete
features list at some 150k of JS in there, every gadget would end up
being a lot slower in the end.
So the trick is to find what works best for you and is used most
often, force those features to be external ... and presto you have a
lot lighter gadgets, with very good browser caching behavior :-)
Hope that helps to explain a bit!
-- Chris
On Jun 27, 2008, at 5:29 AM, Eiji Kitamura wrote:
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.
