I never worked with this API, but chiming in anyway (and hopefully not repeating) ...
On Wed, Dec 15, 2010 at 11:03 AM, Ryan J Baxter <[email protected]> wrote: > I have a question about the constructor for shindig.BaseIfrGadget in > shindig-container.js which is part of the feature shindig.container. Why > do we set the serverBase_ variable to '/gadgets/' in the constructor of > this object? Because of the way this is coded it makes it hard for > objects extending shindig.BaseIfrGadget to override serverBase_. For > example, even if you wanted to override serverBase_ in the opt_params > passed into the constructor Yes, you should be able to override serverBase_ by piggy-backing on opt_parms, with -- this.serverBase_ = (opt_params && opt_params['serverBase']) ? opt_params['serverBase'] : '/gadgets/'; > you wouldn't be able to because after we add > the params to the object we just set serverBase_ to '/gadgets/'. Not following here, where do you set serverBase_? > The only > way to extend shindig.BaseIfrGadget and to override serverBase_ is to > never call the super constructor and instead put the code from the > constructor of shindig.BaseIfrGadget in the constructor of your extending > class and set serverBase_ to whatever value you want. > > Can you also do ? var g = new shindig.BaseIfrGadget(); g.setServerBase(...) // immediately after > Wouldn't it be cleaner to not set serverBase_ in the shindig.BaseIfrGadget > constructor and instead have it as a member variable to the class itself? > > FMI, is this a new gadget container that you want to setup? If so, we have a newer/more-supported gadget-container framework (aka common container) that allows gadgets navigation, preloading, token refresh, with one line of source-script and a few lines of JS. More information for your read here<http://mail-archives.apache.org/mod_mbox/shindig-dev/201005.mbox/%[email protected]%3e> . > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > >
