Argh... Nevermind... I wasn't removing my up_siteid_ prefix from the get_pref value before returning it. This is working beautifully Dan. Nice job!
doug On 7/28/11 12:19 PM, "daviesd" <davi...@oclc.org> wrote: > Dan, > > Are you sure about this? I am having an issue now where I've implemented the > plugin points you've provided but the gadget isn't recognizing the userprefs > once set. I'm pretty sure I need them at metadata time. > > doug > > > On 7/27/11 3:41 PM, "Dan Dumont" <ddum...@us.ibm.com> wrote: > >> 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-Conta>> i >> 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 >>>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> >>
