Hey Michel, I do not know specifically which problems he had but, i also have some troubles with that, and what i can say is:
When you call addGadget on container, in some moment, the container will create the BaseIfrGadget, and even you pass opt_params, after set opt_params the BaseIfrGadget set the server base to /gadgets, and the only way to fix this i found was override the BaseIfrGadget constructor and change to /gadgets to /my-context/gadgets. Container handles the BaseIfrGadget, we can not call setServerBase after constructor, the only way to handle it's overriding method and "copy/changing" some behaviors. So the common-container, replace all features of shindig-container? Instead of override and work with shindig-container, could I work with common-container? Is shindig already using common container? On Wed, Dec 15, 2010 at 10:14 PM, Michael Hermanto <[email protected]>wrote: > 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 > > > > >
