Your right, this is my inexperience shining through here. I thought the PropertiesModule actually loaded all the properties from shindig.properties, but I guess not. It looks like its just used to set the values of shindig.port and shindig.host. So there is no way to change the property values set in shindig.properties after you have built shindig?
-Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile From: Maxwell <[email protected]> To: "[email protected]" <[email protected]> Date: 12/15/2010 02:41 PM Subject: Re: shindig.BaseIfrGadget Constructor 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 >> > > >
