Hi Dan, maybe good idea to add a Shindig wiki page to explain how to hook the moduleid to siteId extractor for Shindig implementor after your patch.
- Henry On Mon, Jan 23, 2012 at 1:05 PM, Dan Dumont <ddum...@us.ibm.com> wrote: > The server side moduleId stuff is all there for you to implement however > you want to persist gadget instances. > > It should be fairly flexible so that you can implement it many different > ways. Just inject your implementation in place of shindig's module id > manager > I have a spec patch out there that specifies how to use the moduleId > render param when navigating a gadget. > > > > From: daviesd <davi...@oclc.org> > To: <dev@shindig.apache.org>, > Date: 01/23/2012 03:19 PM > Subject: Re: getModuleId > > > > That's what I was kind of figuring. So can you tell me what state the > moduleId stuff is at? Is it still under development or can I start using > it > now? I hope we get another beta (or final 3.0.0 release) soon that has > this > and oauth2 in a stable state. > > doug > > > On 1/23/12 3:16 PM, "Dan Dumont" <ddum...@us.ibm.com> wrote: > >> Hrmm... >> >> I don't know if you'll be able to do this anymore until you hook up the >> moduleId support. >> >> >> >> From: daviesd <davi...@oclc.org> >> To: <dev@shindig.apache.org>, >> Date: 01/23/2012 03:08 PM >> Subject: Re: getModuleId >> >> >> >> 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 >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > >
