D'oh. Just re-read your comment, and realized I responded to something different. Consider my response simply excess documentation ;)
Injecting into <head> rather than document.write might indeed be a possibility.. the API already supports the callback param so ordering could be maintained as well. I like it. Will implement. Thanks! John On Mon, Jun 21, 2010 at 5:10 PM, John Hjelmstad <[email protected]> wrote: > Actually, this is for use of JS outside the context of a direct gadget > load. The canonical example are containers using gadgets.rpc, though this > technique will likely be used by other containers and container-like pages > on an ongoing basis. > > It's somewhat akin to the Google AJAX APIs, eg: > http://www.google.com/uds/?file=ads&v=1&packages=searchiframe; a "JS > loader" for Shindig-supplied JS if you will. > > With it, statically or dynamically a page can do: > <script src=" > http://www.shindigserver.com/gadgets/js/lib1:lib2:lib3.js&jsload=1[&refresh=...]<http://www.shindigserver.com/gadgets/js/lib1:lib2:lib3.js&jsload=1%5B&refresh=...%5D> > "></script> > > ...and will get a tiny piece of JS that in turn loads a much larger cached > JS. > > The extension of this will allow dynamically-generated pages to > incrementally add JS support. > > Use case where gadget container loads gadget X, which requires > container-side JS A, B, and C. It does: <script src=" > http://www.shindigserver.com/gadgets/js/A:B:C.js&?jsload=1";> > > Later, gadget Y is installed, which (per metadata service) requires > features B and E, where E depends on A. A wrapper script (also in a later > follow-up) adds: > <script src=" > http://www.shindigserver.com/gadgets/js/B:E.js?jsload=1&alreadyhas=A:B:C";> > > With this, JsServlet just omits A:B:C's JS from the output and spits out > the rest. > > So goes the idea anyway. This is the first step, and IMO reasonably useful > on its own. > > --j > > On Mon, Jun 21, 2010 at 4:23 PM, <[email protected]> wrote: > >> interesting.. I wonder if it would be better to inject the script node >> into the head instead of using document.write? This would then result >> in async/deferred js loading which may help page load performance. >> >> >> http://codereview.appspot.com/1687043/show >> > >
