Doug can you explain more about how your using appdata + site id to store
user prefs? I tried looking below but couldn't find an explanation. I
realize that every gadget site has a unique gadget id, but couldn't a
container choose to reuse a gadget site? Say a container renders gadget 1
in site 1. Gadget 1 saves some user preferences using your
implementation. Then the container reuses site 1 to render gadget 2. In
theory couldn't gadget 2 now have access to gadget 1's preferences?
-Ryan
Email: rjbax...@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: daviesd <davi...@oclc.org>
To: <dev@shindig.apache.org>,
Date: 07/28/2011 11:55 AM
Subject: Re: Example implementation for user prefs?
Jesse,
I think you are correct that it should be per instance. That's where the
siteid would come into play. At least that's how I'm reading it (and now
implementing it). In our case a particular gadget always renders in the
same
siteid. Two instances of the same gadget would have different siteids,
thus
different preferences.
doug
On 7/28/11 11:51 AM, "Ciancetta, Jesse E." <jc...@mitre.org> wrote:
>> 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
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
