gadgets.util.getContainer() helper method

In several instances, I've seen gadgets getting their container ID for one reason or another. Given this seems inevitable anyway, it seems prudent to offer a standard helper method for such functionality. Comments welcome.

[johnfargo, 2010-07-13 17:51:40]

Default to "default"

[zhoresh, 2010-07-13 18:01:53]

lgtm, (Do we have any tests for this?)
The new function is part of the "api", so it probably should be added to Shindig
documentation of how to use it.

[fargo, 2010-07-13 18:05:23]

Regrettably the utiltest.js harness still is pretty spare. Re: adding the
API, I'm a little hesitant since this isn't part of the spec... at the same
time, it accommodates a common use case.

On Tue, Jul 13, 2010 at 11:01 AM, <zhoresh@gmail.com> wrote:

> lgtm, (Do we have any tests for this?)
> The new function is part of the "api", so it probably should be added to
> Shindig documentation of how to use it.
>
>
>
> http://codereview.appspot.com/1760044/show
>

[zhoresh, 2010-07-13 18:21:24]

Well if it won't be documented somewhere it probably won't be used...
but I see your point, not in spec, so it won't be cleared when it is
available.


On Tue, Jul 13, 2010 at 11:05 AM, John Hjelmstad <fargo@google.com> wrote:

> Regrettably the utiltest.js harness still is pretty spare. Re: adding the
> API, I'm a little hesitant since this isn't part of the spec... at the same
> time, it accommodates a common use case.
>
>
> On Tue, Jul 13, 2010 at 11:01 AM, <zhoresh@gmail.com> wrote:
>
>> lgtm, (Do we have any tests for this?)
>> The new function is part of the "api", so it probably should be added to
>> Shindig documentation of how to use it.
>>
>>
>>
>> http://codereview.appspot.com/1760044/show
>>
>
>

[Tim Wintle, 2010-07-13 19:14:47]

While I think this is a fairly common use case, I'm negative on adding the
method.

Adding ~50 bytes to gadgets.core so developers can call

{{{
gadgets.util.getContainer()
}}}

instead of 
{{{
gadgets.util.getUrlParameters().container
}}}

doesn't seem worth it to me - especially considering that if there are
any extra url parameters the user might want to access in the future
it's more methods to add (and provide legacy support for).

If documentation is the issue, then documenting "getUrlParameters()"
would be easier IMO.

(not sure if I've missed some discussion on this)

Tim

[fargo, 2010-07-13 19:54:26]

On Tue, Jul 13, 2010 at 12:14 PM, <timwintle@gmail.com> wrote:

> While I think this is a fairly common use case, I'm negative on adding
> the method.
>
> Adding ~50 bytes to gadgets.core so developers can call
>
> {{{
> gadgets.util.getContainer()
> }}}
>
> instead of
> {{{
> gadgets.util.getUrlParameters().container
> }}}
>
> doesn't seem worth it to me - especially considering that if there are
> any extra url parameters the user might want to access in the future
> it's more methods to add (and provide legacy support for).
>
> If documentation is the issue, then documenting "getUrlParameters()"
> would be easier IMO.
>
> (not sure if I've missed some discussion on this)
>

Nope, this thread _is_ the discussion, so I'm happy for your input ;)

The value I see isn't necessarily in avoiding .container, it's instead:
A) the other two: synd || "default"
B) the flexibility to change the URL scheme later or on a per-installation
basis. For instance, the security token often contains the container ID --
using it would save bytes. A container ID could also be injected by the
server, or the param could be renamed.

It's all really just a hedge though ;)

--j


>
> Tim
>
>
> http://codereview.appspot.com/1760044/show
>

[johnfargo, 2011-01-25 04:10:05]

FYI I'm tossing this CL.

On 2010/07/13 19:54:26, fargo wrote:
> On Tue, Jul 13, 2010 at 12:14 PM, <mailto:timwintle@gmail.com> wrote:
> 
> > While I think this is a fairly common use case, I'm negative on adding
> > the method.
> >
> > Adding ~50 bytes to gadgets.core so developers can call
> >
> > {{{
> > gadgets.util.getContainer()
> > }}}
> >
> > instead of
> > {{{
> > gadgets.util.getUrlParameters().container
> > }}}
> >
> > doesn't seem worth it to me - especially considering that if there are
> > any extra url parameters the user might want to access in the future
> > it's more methods to add (and provide legacy support for).
> >
> > If documentation is the issue, then documenting "getUrlParameters()"
> > would be easier IMO.
> >
> > (not sure if I've missed some discussion on this)
> >
> 
> Nope, this thread _is_ the discussion, so I'm happy for your input ;)
> 
> The value I see isn't necessarily in avoiding .container, it's instead:
> A) the other two: synd || "default"
> B) the flexibility to change the URL scheme later or on a per-installation
> basis. For instance, the security token often contains the container ID --
> using it would save bytes. A container ID could also be injected by the
> server, or the param could be renamed.
> 
> It's all really just a hedge though ;)
> 
> --j
> 
> 
> >
> > Tim
> >
> >
> > http://codereview.appspot.com/1760044/show
> >