I know iGoogle's container stores preferences per user per application instance. Not sure if thats worth anything though, sine the spec does not provide details on this. We also plan on having an implementation where user prefs are per user per application instance.
-Ryan Email: rjbax...@us.ibm.com Phone: 978-899-3041 developerWorks Profile From: Henry Saputra <henry.sapu...@gmail.com> To: dev@shindig.apache.org, Date: 07/28/2011 09:13 PM Subject: Re: Example implementation for user prefs? Hmm I cant seem to find if user preference is per application instance. I always assume that its per user/per application. - Henry On Wed, Jul 27, 2011 at 10:21 AM, Ciancetta, Jesse E. <jc...@mitre.org> wrote: > I believe appdata is stored per user/per application as opposed to per user/per application instance, so I think you'll need to add the module ID (application instance ID) somewhere in your naming scheme for the persisted appdata. > > I think as its implemented currently two instances of the same application for the same user will share user preference values (and I believe user preferences are supposed to be stored per user/per application instance). > >>-----Original Message----- >>From: daviesd [mailto:davi...@oclc.org] >>Sent: Wednesday, July 27, 2011 11:59 AM >>To: dev@shindig.apache.org >>Subject: Re: Example implementation for user prefs? >> >>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 >>>>> >> >>>> > >>> >>> > >
