This is GOOD stuff.  I think I'm gonna have to move off of beta2 (is there a
beta3 in site?).  I didn't realize all this work had been done and I was
doing a lot of it myself.

Thanks,
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
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 


Reply via email to