>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/'; Yes this is one way to fix the problem, my point being we would have to make a code change in shindig-container.js in order to make this work. >> 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_? Here is the code shindig.BaseIfrGadget = function(opt_params) { shindig.Gadget.call(this, opt_params); this.serverBase_ = '/gadgets/'; // default gadget server this.queryIfrGadgetType_(); }; The problem here is that queryIfrGadgetType_() uses serverBase_ to request the gadget metadata and immediately before we make that call we are setting serverBase_. So if you set serverBase_ in opt_params it will be set in the first call to shindig.Gadget.call but immediately set to '/gadgets/' right after. We would need to make a change, like you suggested above in order for this to work. The other option I thought of was not setting serverBase_ in the constructor at all and just have a member variable to the class, something like: shindig.BaseIfrGadget.prototype.serverBase_ = '/gadgets/'; >> 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 > >. Has this code been contributed yet? I am def interested in taking a look at it. >> -Ryan >> >> Email: [email protected] >> Phone: 978-899-3041 >> developerWorks Profile >> >> From: Michael Hermanto <[email protected]> To: [email protected] Date: 12/15/2010 07:16 PM Subject: Re: shindig.BaseIfrGadget Constructor 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 > >
