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" <ddum...@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 <davi...@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" <ddum...@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 <davi...@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" <ddum...@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 <davi...@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 >>> >> >> >> > > >
