Hi Doug,
You may have already gotten to the bottom of this but I'll provide a quick
rundown here anyway.
siteId: Client-side ID that is generated to help manage communication
between the container and the gadget sites for services like actions,
selection, and more
appId: An id that is unique to the application, i.e. gadget, being
rendered. AppId in the case of gadgets is generally just the URL to the
gadget XML. Thus, this ID is the same across all instances of a given
gadget and is for storing data like app data.
moduleId: An id that is unique to the instance of a gadget. If multiple
instances of the same gadget are rendering on the page, they should have
unique module ids. The server is also aware of module ids, as you saw with
ModuleIdManager, and is the one responsible for generating them. They are
included in security tokens to differentiate between separate instances of
a gadget. The module id for a gadget instance should be the same across
page reloads. A gadget preferences implementation would use the module id
to store instance-specific information.
Shindig's default implementation of moduleId is naive (it's always 0!) but
a ModuleIdManager implementation can be injected that handles them more
intelligently.
I hope that helps!
On Fri, Apr 24, 2015 at 4:10 PM, Davies,Douglas <davi...@oclc.org> wrote:
> I think I just had an ah ha moment. I realized the ModuleIdManager is
> concerned about persistence. I’m not sure that’s what I need here. I
> think the piece I was missing it RenderParam.MODULE_ID on the container
> side. I’m gonna play with this and I’ll be back if I have more questions.
>
> Thanks,
> doug
>
>
> On Apr 24, 2015, at 2:15 PM, Davies,Douglas <davi...@oclc.org> wrote:
>
> > Ok, I think I’ve figured this out (at least our use-case).
> >
> > We are using the siteId all over the place in the container and having
> to pass it along to the userPrefs calls. I’m guessing I shouldn’t be doing
> this and allowed the moduleId bake into the security token to be used
> server-side to identify the gadget.
> >
> > So… I implemented my own ModuleIdManager, however I noticed it NEVER
> gets called. I traced it back to getToken in GadgetsHandlerService, which
> in turn is called by the token method over in GadgetsHandler. It looks as
> follows
> >
> > @Operation(httpMethods = {"POST", "GET"}, path = "token")
> > public Map<String, GadgetsHandlerApi.BaseResponse> token(BaseRequestItem
> request)
> > throws ProtocolException {
> > return new AbstractExecutor() {
> > @Override
> > protected Callable<CallableData> createJob(String url,
> BaseRequestItem request)
> > throws ProcessingException {
> > return createTokenJob(url, request);
> > }
> > }.execute(request);
> > }
> >
> > However I NEVER see this endpoint hit. I see the metadata endpoint get
> called. Does the js container need to be doing something with the “token”
> endpoint? I don’t see it documented anywhere. The common container that
> comes with shindig doesn’t seem to call this endpoint either.
> >
> > Thanks,
> > doug
> >
> > On Apr 22, 2015, at 12:49 PM, Davies,Douglas <davi...@oclc.org<mailto:
> davi...@oclc.org>> wrote:
> >
> > I’ve been combing through past conversations and wikis, but I’ve yet to
> find a good explanation of the difference between appId, moduleId, and
> siteId. Does anyone know where I can find a good explanation of where I
> should be using each one? Right now I think the default ModuleIIdManager
> always returns 0. We are using siteId quite a bit in our container to
> indicate which gadget is making requests. I know the moduleId is baked
> into the SecurityToken and it would be a better implementation. Any
> guidance on this would be appreciated.
> >
> > Thanks,
> > Doug
> >
> >
> >
>
>
>
