>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.
But if we're talking about providing a reference implementation to server as a
sample for anyone using the common container -- that implementation should be
saving preferences per gadget instance, right? I believe that user preferences
are supposed to be stored per user/per gadget instance (although I just took a
quick glance through the 2.0 spec and couldn't find any language to support
that).
Can anyone confirm or deny that to actually be the case (and maybe provide a
reference to where it's specified)?
>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
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
