Enable proper common container globals initialization when dynamically loading

JIRA: https://issues.apache.org/jira/browse/SHINDIG-1533

This is a fix/workaround for an issue I've encountered in init.js#initializeGlobalVars() when dynamically loading the container.js.  

The code as it exists today assumes that the <script> tag loading the container.js will be the last one encountered for the document.  This is not always the case, especially when loading the container.js by dynamically inserting the <script> tag in the page.

If the wrong script tag is used, the __API_URI and __CONTAINER_URI globals will not initialize properly.

My fix is to introduce another window global that can be set before dynamically loading the container.js.  This new global will unambiguously specify the proper script tag by providing the ID.

I'm also interested to hear of other solutions.  Until coming up with this solution I had just been overriding the improperly init'd globals before doing anything with the Common Container.  This seems fragile as more globals could be added in the future or used at unexpected times.

[Stanton, 2011-05-04 12:05:32]

I don't think putting it in the container config is viable.  The reason
being that on the JavaScript side we only get the config that resides in the
"gadgets.features" section and only for required features.  All of the
config above that is utilized server side for container operations.
Additionally, the current timing just doesn't work.  We initialize those
globals before we ever see the container config.

And even if we did have a place in a config file to specify an ID I think
that would limit our flexibility.  In my particular use case the ID of the
script is auto-generated by the loading mechanism and I want to be able to
use whatever ID it generates for me.

On Tue, May 3, 2011 at 8:31 PM, <rbaxter85@gmail.com> wrote:

> So this LGTM code wise.
>
> It feels a little odd to me but I am struggling to think of another way
> to denote which script tag we want.
>
> Could we pass an id into the container config which specifies the id of
> the script tag we want?
>
> On 2011/05/03 20:58:44, Stanton wrote:
>
>
>
> http://codereview.appspot.com/4439090/
>

[rbaxter85, 2011-05-04 13:18:21]

So when does initializeGlobalVars() get called?  Does it called when you
construct the osapi.container.Container object or does it get called when the JS
is loaded into the page?

On 2011/05/04 12:05:32, Stanton wrote:
> I don't think putting it in the container config is viable.  The reason
> being that on the JavaScript side we only get the config that resides in the
> "gadgets.features" section and only for required features.  All of the
> config above that is utilized server side for container operations.
> Additionally, the current timing just doesn't work.  We initialize those
> globals before we ever see the container config.
> 
> And even if we did have a place in a config file to specify an ID I think
> that would limit our flexibility.  In my particular use case the ID of the
> script is auto-generated by the loading mechanism and I want to be able to
> use whatever ID it generates for me.
> 
> On Tue, May 3, 2011 at 8:31 PM, <mailto:rbaxter85@gmail.com> wrote:
> 
> > So this LGTM code wise.
> >
> > It feels a little odd to me but I am struggling to think of another way
> > to denote which script tag we want.
> >
> > Could we pass an id into the container config which specifies the id of
> > the script tag we want?
> >
> > On 2011/05/03 20:58:44, Stanton wrote:
> >
> >
> >
> > http://codereview.appspot.com/4439090/
> >

[Stanton, 2011-05-04 14:12:07]

initializeGlobalVars gets called when we load init.js.  init.js is loaded
after all of the other container source files are loaded.

On Wed, May 4, 2011 at 9:18 AM, <rbaxter85@gmail.com> wrote:

> So when does initializeGlobalVars() get called?  Does it called when you
> construct the osapi.container.Container object or does it get called
> when the JS is loaded into the page?
>
>
> On 2011/05/04 12:05:32, Stanton wrote:
>
>> I don't think putting it in the container config is viable.  The
>>
> reason
>
>> being that on the JavaScript side we only get the config that resides
>>
> in the
>
>> "gadgets.features" section and only for required features.  All of the
>> config above that is utilized server side for container operations.
>> Additionally, the current timing just doesn't work.  We initialize
>>
> those
>
>> globals before we ever see the container config.
>>
>
>  And even if we did have a place in a config file to specify an ID I
>>
> think
>
>> that would limit our flexibility.  In my particular use case the ID of
>>
> the
>
>> script is auto-generated by the loading mechanism and I want to be
>>
> able to
>
>> use whatever ID it generates for me.
>>
>
>  On Tue, May 3, 2011 at 8:31 PM, <mailto:rbaxter85@gmail.com> wrote:
>>
>
>  > So this LGTM code wise.
>> >
>> > It feels a little odd to me but I am struggling to think of another
>>
> way
>
>> > to denote which script tag we want.
>> >
>> > Could we pass an id into the container config which specifies the id
>>
> of
>
>> > the script tag we want?
>> >
>> > On 2011/05/03 20:58:44, Stanton wrote:
>> >
>> >
>> >
>> > http://codereview.appspot.com/4439090/
>> >
>>
>
>
>
> http://codereview.appspot.com/4439090/
>

[Stanton, 2011-05-04 14:28:04]

Adding the common container specification authors as reviewers to get their
thoughts.

[mhermanto, 2011-05-04 17:18:50]

On 2011/05/04 14:28:04, Stanton wrote:
> Adding the common container specification authors as reviewers to get their
> thoughts.

LGTM

[mhermanto, 2011-05-16 20:24:31]

LGTM