You are right, if you want to run shindig in a non-root context, you must. Override the constructor, copy the code and change the serverBase.
That's bad, another thing that is bad about this is the fact you have container.js and shindig.properties in common jar. If you want to create a new project and set shindig as dependence, you will have a lot of workaround to do that. Sent from my iPhone On 15/12/2010, at 17:03, "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, you wouldn't be able to because after we add > the params to the object we just set serverBase_ to '/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. > > 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? > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile >
