Actually the PropertiesModule does load all the key-value pairs from shindig.properties.
Take a look at PropertiesModule.readPropertyFile(). - Henry On Wed, Dec 15, 2010 at 11:57 AM, Ryan J Baxter <[email protected]> wrote: > 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 >>> >> >> >> > > > > -- Thanks, Henry
