Issue 1687043: Support JS loader script in JsServlet; tweaks to JsUriManager et al.

Issue 1687043: Support JS loader script in JsServlet; tweaks to JsUriManager et al. (Closed)

Can't Edit
Can't Publish+Mail
Start Review

Created:
15 years, 9 months ago by johnfargo

Modified:
15 years, 5 months ago

Reviewers:
Paul Lindner, dev-remailer

Base URL:
http://svn.apache.org/repos/asf/shindig/trunk/

Visibility:
Public.

Description

Adds support for &jsload=1 argument to JsServlet, in which presence JS is emitted which in turn loads (versioned) JavaScript from Shindig. The benefits of doing so are: 1. Less JS on the wire, even for JS-triggered JS loads. The loader JS is very small and cacheable for 1 hr; the subsequent JS should be versioned and thus cacheable essentially indefinitely. 2. Sets up follow-up CL, which will support incremental JS loads using this mechanism. In supporting this, the JsUriManager API is slightly modified as well, as follows: 1. make(...) method takes GadgetContext rather than Gadget. 2. JsUri extends ProxyUriBase to support the usual raft of params.

Patch Set 1 #

Created: 15 years, 9 months ago

Download [raw] [tar.bz2]

Unified diffs	Side-by-side diffs	Stats (+128 lines, -93 lines)			Patch
java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java	View	2 chunks	+4 lines, -2 lines	0 comments	Download
java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/JsServlet.java	View	8 chunks	+90 lines, -51 lines	0 comments	Download
java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/DefaultJsUriManager.java	View	5 chunks	+10 lines, -10 lines	0 comments	Download
java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/JsUriManager.java	View	2 chunks	+7 lines, -11 lines	0 comments	Download
java/gadgets/src/test/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriterTest.java	View	2 chunks	+1 line, -2 lines	0 comments	Download
java/gadgets/src/test/java/org/apache/shindig/gadgets/uri/DefaultJsUriManagerTest.java	View	7 chunks	+16 lines, -17 lines	0 comments	Download

Messages

Total messages: 7

Expand All Messages | Collapse All Messages

Paul Lindner

interesting.. I wonder if it would be better to inject the script node into the ...

15 years, 9 months ago (2010-06-21 23:23:58 UTC) #2

fargo

Actually, this is for use of JS outside the context of a direct gadget load. ...

15 years, 9 months ago (2010-06-22 00:10:55 UTC) #3

johnfargo

D'oh. Just re-read your comment, and realized I responded to something different. Consider my response ...

15 years, 9 months ago (2010-06-22 00:40:18 UTC) #4

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 <fargo@google.com> 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, <lindner@inuus.com> 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
>>
>
>

kkasravi_yahoo-inc.com

A JS loader that has the capability to load other javascript and their transitive closures ...

15 years, 9 months ago (2010-06-22 02:12:16 UTC) #5

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, <lindner@inuus.com> 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
>>

fargo

Hi Kam: Thanks for the input - I agree wholeheartedly w/ you that we should ...

15 years, 9 months ago (2010-06-22 02:27:55 UTC) #6

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 <kkasravi@yahoo-inc.com> 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, <lindner@inuus.com> 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
> >>
>
>

kkasravi_yahoo-inc.com

15 years, 9 months ago (2010-06-22 02:46:28 UTC) #7

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 <kkasravi@yahoo-inc.com> 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, <lindner@inuus.com> 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
>>>> 
>> 
>>

Expand All Messages | Collapse All Messages