Yes you can use your own version of container.js, but I do not think you can use the same for shindig.properties. How could you do that?
Sent from my iPhone On 15/12/2010, at 17:23, "Ryan J Baxter" <[email protected]> wrote: > I am not so worried about container.js and shindig.properties being in a > common jar because its possible to point to your own versions of these, > right? My understanding is that shindig.properties is loaded from a guice > module. shindig.properties also contains a property that points to the > container.js file you want to use. So you can create your own guice > module which loads your own shindig.properties file and that > shindig.properties file can point to your own container.js file. If I am > wrong, please let me know, because then that will cause more issues for > me. > > To my original point in the email, I just find the way it is currently > coded to cause people to have to do more work than they should to > implement their own container. Would anyone be against me opening a bug > for this and fixing it? > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > > > > From: Maxwell <[email protected]> > To: "[email protected]" <[email protected]> > Date: 12/15/2010 02:16 PM > Subject: Re: shindig.BaseIfrGadget Constructor > > > > 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 >> > > >
