Correction: the preferences to render with are a RENDER_PARAM and as such are only needed when doing the gadget render, not the metadata request. No patch needed.
From: Dan Dumont/Westford/IBM@Lotus To: dev@shindig.apache.org, Date: 07/27/2011 03:35 PM Subject: Re: Example implementation for user prefs? http://opensocial-resources.googlecode.com/svn/spec/2.0/incubating/Core-Container.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 >>>>>>>> >>>>>> >>>> >>>> >>> >>> >> > > > > >
