I'm ok with setting the id (now that I've thought about it more). I just didn't know how set in concrete the api was. Thanks for the feedback.
On 11/17/11 1:25 PM, "Dan Dumont" <[email protected]> wrote: > Ahh I see. > > If you never use the autogen, I think you can use a number in the id of > the site. Just don't every use the autogen by not specifying an id :) > I did it this way because it was less invasive than changing the api. > > Passing in an id to the constructor might be ok too, but it is an api > change. If you feel strongly about it or can't easily work with the > current behavior, write up a patch :) > > > > From: daviesd <[email protected]> > To: <[email protected]>, > Date: 11/17/2011 11:34 AM > Subject: Re: siteId from element id > > > > Rereading I may not have been totally clear. We are NOT using the > auto-generated number. We are using a sequence number from our database > (which correlates to our gadget space). It is always the same number for > an > installed gadget. > > I guess my question was... Is using an html element attribute the correct > way to communicate this id or would changing the api for newGadgetSite to > accept an id be more appropriate? > > doug > > > On 11/17/11 11:15 AM, "Dan Dumont" <[email protected]> wrote: > >> 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. > > > > >
