shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From daviesd <davi...@oclc.org>
Subject Re: getModuleId
Date Mon, 23 Jan 2012 20:06:32 GMT
Like I said... An edge case... And probably not a real world use case.

But my test gadget sets a bunch of userprefs and then it needs to repull the
values (from persistence) and make sure they've been set properly (tests a
race condition we had).

I was using osapi.userprefs.get to retrieve the values.  Is there a gadget
way of triggering the get call that is in the container?  I don't want to
just get the map that the container has, I need to reforce a read from
persistence.

Hope that makes sense,
doug


On 1/23/12 3:00 PM, "Dan Dumont" <ddumont@us.ibm.com> wrote:

> I don't think so.   In my opinion, the siteId is a purely container piece
> of information.
> why do you need to get it inside the gadget?
> 
> 
> 
> From:   daviesd <daviesd@oclc.org>
> To:     <dev@shindig.apache.org>,
> Date:   01/23/2012 02:57 PM
> Subject:        Re: getModuleId
> 
> 
> 
> I agree on everything you just stated.
> 
> So my only outstanding question would be is anyone aware of a way for a
> gadget to find out it's siteId (the id that was set on the element the
> gadget was rendered into)?
> 
> Any yes, I'd like to see the rpc requests changed to use the gadget
> security
> token.
> 
> doug
> 
> 
> On 1/23/12 1:44 PM, "Dan Dumont" <ddumont@us.ibm.com> wrote:
> 
>> Not a problem.
>> 
>> mid is for the moduleId.  (maybe it wasn't always so... but for
>> consistency sake it probably should remain so)
>> IIRC, Prefs.getModuleId returns the value in the ifr url 'mid' param.
>> 
>> Your GET_PREFERENCES/SET_PREFERENCES impl should be getting the siteid,
>> which it can look up a gadget site with.
>> You can then determine the moduleId (which should be 0 for now).
>> 
>> I agree, if the rpc requests do not pass the gadget's token along, they
>> probably should now.  Most people will be wanting to key things off of
> the
>> moduleId rather than the siteId.  The moduleId is baked in the token and
>> not something one could spoof with firebug.
>> 
>> 
>> From:   daviesd <daviesd@oclc.org>
>> To:     <dev@shindig.apache.org>,
>> Date:   01/23/2012 01:34 PM
>> Subject:        Re: getModuleId
>> 
>> 
>> 
>> In pref.js shindig was setting the Prefs moduleId to the "mid"
> parameter.
>> Perhaps something is different here now.  So for whatever reason that
> use
>> to
>> return me whatever I had as my siteId and now it doesn't.
>> 
>> At any rate, this is a TEST gadget that is probably trying to access
>> something it shouldn't.  When the userprefs are stored they are stored
>> using
>> the siteId granted by our container implementation (the container
>> registers
>> SET_PREFERENCES and GET_PREFERENCES handlers).  I think I opened up this
>> ticket because of that.
>> 
>> https://issues.apache.org/jira/browse/SHINDIG-1557
>> 
>> It would really be nice if the rpc requests used the gadget security
> token
>> (that would hopefully have the moduleId set now that you've implemented
>> that).
>> 
>> So in my test gadget I don't know what the siteId is.  For some reason I
>> was
>> calling Prefs().getModuleId (I think this thread suggests that).
>> 
>> http://shindig-dev.markmail.org/thread/zyi2zvpn7akhrbi3
>> 
>> Is there another way for a gadget to know this?  I realize implementing
>> moduleId would probably give me this (although a gadget doesn't really
>> know
>> what's in it's security token, but it can certainly pass it along to api
>> calls).
>> 
>> Sorry if I'm muddying the waters.  I should have been more active in
> your
>> moduleId discussion.
>> 
>> doug
>> 
>> 
>> On 1/23/12 12:57 PM, "Dan Dumont" <ddumont@us.ibm.com> wrote:
>> 
>>> Hrmm... I don't recall moduleId ever being anything other than 0.
>>> 
>>> The discussions have focused around what a moduleId is (a number that's
>>> baked into the security token, primarily used to identify saved
>> instances
>>> of a gadget) and what a siteId is ( a string value that's used in or as
>> an
>>> id attribute of a DOM element in the container ).  The recent patches
>>> created a way to generate, save, and track moduleIds on the server,
>> should
>>> you choose to implement the bits, otherwise they return 0 as they
> always
>>> have.
>>> 
>>> I'm curious how you got numbers other than 0.  Especially for the
>> security
>>> token, moduleId was always 0 in shindig.
>>> 
>>> 
>>> 
>>> From:   daviesd <daviesd@oclc.org>
>>> To:     shindig <dev@shindig.apache.org>,
>>> Date:   01/23/2012 12:51 PM
>>> Subject:        getModuleId
>>> 
>>> 
>>> 
>>> I have a gadget that was using
>>> 
>>> var moduleId = new gadgets.Prefs().getModuleId();
>>> 
>>> To get the current moduleId (siteId) of the gadget so that it could
>>> retrieve
>>> userprefs
>>> 
>>> osapi.userprefs.get( { siteId : moduleId } )
>>> 
>>> This is now return 0 instead of the id I have for the element the
> gadget
>>> was
>>> rendered into.
>>> 
>>> I haven¹t kept up with the whole moduleId/siteId patch that is going
> on,
>>> but
>>> perhaps something has changed here and is not backwards compatible?
>>> 
>>> Any ideas?  It¹s been a while since I¹ve played around with userprefs
>> and
>>> today was the first I noticed it wasn¹t working.
>>> 
>>> doug
>>> 
>> 
>> 
>> 
> 
> 
> 



Mime
View raw message