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
