Hi John I would look at two implementations of 'require'. RequireJS and Nodules both have support for client and server side dependency management.
http://requirejs.org/ http://github.com/kriszyp/nodules There are others, most can be found on github by searching for commonjs or javascript modules. Kris Zyp may be worth pinging about opensocial requirements for a module loader and what types of existing implementations best meet the requirements. I could post to the relevant discussion groups if there is a condensed set of requirements for loading js and/or other types of resources required by a gadget. Now is the time to influence the ecmascript body and commonjs committers. thanks kam On Jun 21, 2010, at 7:27 PM, John Hjelmstad wrote: > Hi Kam: > > Thanks for the input - I agree wholeheartedly w/ you that we should support > standards to the maximum extent possible. This being said, "eventually be > replaced" isn't equivalent to "available today," which is quite often a > requirement. > > CommonJS seems closest to a compromise at the moment. I'd be happy to > facilitate the use of its syntax. SM seems better but requires browser > support. > > What are your thoughts on what we might do now to fill the need during > transition? > > --j > > On Mon, Jun 21, 2010 at 7:12 PM, Kam Kasravi <[email protected]> wrote: > >> A JS loader that has the capability to load other javascript and their >> transitive closures shouldn't reinvent the wheel, >> or use a loader that is only specific to opensocial or a vendor's extension >> of opensocial, but rather use commonjs's require >> or ECMAScript's 'Simple Modules' which includes the concept of a dynamic >> loader. 'Require' can load js and dependencies >> on both the server and client side. 'Require' has significant buy-in from >> the community on both server and client side js engines. >> The best argument to forgo other types of loaders is they will eventually >> be replaced by those mentioned above. >> 'Simple Modules' will likely be adopted within the javascript language >> formally and become part of JS 'Harmony'. >> >> thanks >> kam >> >> On Jun 21, 2010, at 5:10 PM, John Hjelmstad 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=.. >> .] >>> "></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 >>>> >> >>
