Dan, Thanks. This is working for the most part, however I'm having issues with the GET_PREFERENCES function. In my implementation I need to gadget site (not just the id) so I do
var site = self.sites_[siteId]; This returns me the right site, however then when I go to get the gadget holder var holder = site.getActiveGadgetHolder(); It's null. It appears this should be either returning the loading or current gadget holder. Just wondering if the get_preferences is being called too early before things are setup completely. doug On 7/27/11 3:33 PM, "Dan Dumont" <ddum...@us.ibm.com> wrote: > http://opensocial-resources.googlecode.com/svn/spec/2.0/incubating/Core-Contai > ner.xml#Configuring-The-Container > > > When you insantiate the common container, you can provide these functions, > keyed appropriately, via the config object. > > The GET_PREFERENCES function will be called as defined when making the > metadata request to the server. The prefs will be supplied to the > server, which will use any provided ones instead of default preferences > when providing the metadata for a gadget. This all happens automatically > in a call to navigate gadget...and now that I think about it, I forgot to > include it in the preLoad method in the common container... I'll submit a > patch shortly. > > The server side impl is totally up to you. I originally had in mind a > client-side html5 store for a default implementation. > > The gadget site encapsulates the site ID. It will prefer the id attr of > the site element you created the site with, otherwise it will default to > an auto-incremented number. > > If you wish to persist preferences for a particular occurrence of a > gadget(per gadget url instance), then you'll need to keep track of the > site (the auto generated ids are less helpful), if you wish to provide > "per gadget url" preferences you can just ignore they siteid and return or > persist the preferences for all gadgets coming from that url. > > > > > From: daviesd <davi...@oclc.org> > To: <dev@shindig.apache.org>, > Date: 07/27/2011 03:22 PM > Subject: Re: Example implementation for user prefs? > > > > Dan, > > Nice! I'm still using 3.0.0-beta2, so hadn't seen this yet. Was there an > earlier thread on how to use this? Can you explain how I hook into this > and > provide a server-side implementation? And does this mean when I call > navigateGadget that I should now be providing a unique id for the siteId > (maybe correlating to my spaceid?)? > > Thanks, > doug > > > On 7/27/11 1:50 PM, "Dan Dumont" <ddum...@us.ibm.com> wrote: > >> FYI, there have been some recent changes in the common container to > expose >> a callback to the container page that allows for the persisting and >> retrieval of persisted preferences. >> >> /** >> * @see setprefs.js setprefs feature. >> */ >> this.rpcRegister('set_pref', function(rpcArgs, key, value) { >> var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY]; >> var setPrefs = >> self.config_[osapi.container.ContainerConfig.SET_PREFERENCES]; >> if (site && setPrefs) { // Check if site is not already closed. >> var data = {}; >> for (var i = 2, j = arguments.length; i < j; i += 2) { >> data[arguments[i]] = arguments[i + 1]; >> } >> setPrefs(site.getId(), site.getActiveGadgetHolder().getUrl(), > data); >> } >> }); >> >> A container may specify functions to the CommonContainer that will be >> called to retrieve and set preferences for a particular gadget. >> Please also note that gadget site id will now prefer the id attribute of >> the gadget site element, so that named locations for specific gadgets > can >> have preferences persisted accordingly. >> >> If you are going to be providing a default preference persistence impl, > it >> would be great if you could hook into this :) >> >> >> >> From: daviesd <davi...@oclc.org> >> To: <dev@shindig.apache.org>, >> Date: 07/27/2011 01:09 PM >> Subject: Re: Example implementation for user prefs? >> >> >> >> Paul, >> >> Sure. Give me a few days, I just got back from vacation. I'll have to >> figure >> out whether the container token will be sufficient for this, as I had to >> apply other patches to get the gadget token to be used. >> >> Thanks, >> doug >> >> >> On 7/27/11 12:58 PM, "Paul Lindner" <lind...@inuus.com> wrote: >> >>> Can you write this up a patch so we can make this the default >>> implementation? This is something I've been meaning to do for months. >>> >>> On Wed, Jul 27, 2011 at 8:58 AM, daviesd <davi...@oclc.org> wrote: >>> >>>> Actually, I was lazy and went with the approach of layering userprefs >> on >>>> top >>>> of appdata as follows: >>>> >>>> container.rpcRegister('set_pref', function(rpcArgs, data) { >>>> >>>> var prefName = rpcArgs['a'][1]; >>>> var prefKey = 'up_' + prefName; >>>> var prefValue = rpcArgs['a'][2]; >>>> >>>> var data = {}; >>>> data[prefKey] = prefValue; >>>> >>>> osapi.appdata.update({ >>>> userid : '@me', >>>> groupid : '@self', >>>> appId : '@app', >>>> data : data >>>> >>>> }).execute(function(response) { >>>> }); >>>> }); >>>> >>>> This is with anticipation that appdata and userprefs will align as >>>> discussed >>>> here: >>>> >>>> http://code.google.com/p/opensocial-resources/issues/detail?id=1182 >>>> >>>> Of course this also requires you to implement appdata server side. >> Right >>>> now I¹m just using the JsonDb implementation (in-memory), but we¹ll be >>>> writing a persistent layer soon. >>>> >>>> I also ran into issues with the correct token (the gadget one with the >>>> appid >>>> that you¹ll need to use to index the data) being passed to the appdata >>>> request. You can search for my other thread about this. >>>> >>>> doug >>>> >>>> >>>> On 7/25/11 6:53 PM, "Henry Saputra" <henry.sapu...@gmail.com> wrote: >>>> >>>>> If you want the user pref to be persisted in the database you need to >>>>> implement the server handler for it. >>>>> >>>>> I remember Doug Davies has tried to add persistent layer for user >>>>> pref. Maybe he could share his progress. >>>>> >>>>> Including him in the email. >>>>> >>>>> - Henry >>>>> >>>>> On Mon, Jul 25, 2011 at 3:42 PM, Mat Schaffer <m...@schaffer.me> > wrote: >>>>>>> So with some research it looks like I'm supposed to be implementing >> my >>>> own >>>>>>> server module. Is that pretty much accurate? >>>>>>> >>>>>>> Again, any advice or RTFMs (with a link to the respective FMs) is >>>>>>> appreciated. >>>>>>> >>>>>>> Thanks, >>>>>>> Mat >>>>>>> >>>>>>> On Fri, Jul 22, 2011 at 10:20 AM, Mat Schaffer <m...@schaffer.me> >>>> wrote: >>>>>>> >>>>>>>>> So I noticed that UserPref items don't work on the sample >> container >>>> which >>>>>>>>> makes sense after finding this thread: >>>>>>>>> http://markmail.org/message/tlwtlo4mrnrpz4w5 >>>>>>>>> >>>>>>>>> Is there any good example of best-practice for implementing user >>>> prefs in >>>>>>>>> my containing application? Do I just make my own >>>> shindig-container.js and >>>>>>>>> handleOpenUserPrefsDialog? And does the page we point to just >> render >>>>>>>>> information into a div with id of `this.id`? >>>>>>>>> >>>>>>>>> The gmodule code appears to be obfuscated, so it's a bit hard to >>>> tell >>> >>>> what >>>>>>>>> the right course of action would be. Any documentation or >> assistance >>>>>>> would >>>>>>>>> be appreciated. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Mat >>>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> >> >> > > > > >
