The siteId is also passed along in the set_pref and get_pref convenience functions so that containers can choose to have preferences that are saved per-gadget-instance. I thought that if a container page were to persist gadgets on a page in particular places, those site ids might need to have a greater significance than just an autogenerated number.
From: daviesd <[email protected]> To: shindig <[email protected]>, Date: 11/17/2011 11:04 AM Subject: siteId from element id Right now the siteId gets set to the id of the element you pass to newGadgetSite (or the next sequence number if not provided). We are using the siteId to correlate to our gadgetId, so that when user_prefs is called (one of the parameters is the siteId) we can use that to store/retrieve data on behalf of the gadget. The way our database is constructed this gadgetId is numeric. As a quick implementation I set our element id to app-# and strip off the app- in our prefs implementation. That works, but is very clunky. So then I thought I¹d plug into the onConstructed calls for GadgetSite or GadgetHolder, but the order of events doesn¹t seem to allow this, because in GadgetSite it¹s too early to access the gadget and in GadgetHolder it¹s too late because the site array has been setup. I tried overriding osapi.container.Container.prototype.newGadgetSite and then set a siteId attribute on my html element that I used in the overridden function, but I really don¹t like this either (I¹m just trading off one attribute for another). Since the siteId is only used as a communication mechanism, is it ok that it is just a number? My concern of having an id as just a number was collision with other dom items, but maybe this isn¹t really an issue and I¹m going to too much work to solve this. I don¹t know if the common container spec is set in concrete, but a newGadgetSite that takes a gadget might be a good solution too. Ideas? Doug
