shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Saputra <henry.sapu...@gmail.com>
Subject Re: shindig.BaseIfrGadget Constructor
Date Wed, 15 Dec 2010 20:16:34 GMT
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 <rjbaxter@us.ibm.com> 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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From:   Maxwell <mchiareli@gmail.com>
> To:     "dev@shindig.apache.org" <dev@shindig.apache.org>
> 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" <rjbaxter@us.ibm.com> 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: rjbaxter@us.ibm.com
>> Phone: 978-899-3041
>> developerWorks Profile
>>
>>
>>
>> From:   Maxwell <mchiareli@gmail.com>
>> To:     "dev@shindig.apache.org" <dev@shindig.apache.org>
>> 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" <rjbaxter@us.ibm.com> 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: rjbaxter@us.ibm.com
>>> Phone: 978-899-3041
>>> developerWorks Profile
>>>
>>
>>
>>
>
>
>
>



-- 
Thanks,
Henry

Mime
View raw message