You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Mat Schaffer <ma...@schaffer.me> on 2011/07/22 19:20:39 UTC
Example implementation for user prefs?
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
Re: Example implementation for user prefs?
Posted by Ryan J Baxter <rj...@us.ibm.com>.
As someone pointed out earlier in the thread, Mark Weitzel, was looking
into cleaning up app data and user prefs. This did not make it into
OpenSocial 2.0 but I think Mark wants to pick it back up in OpenSocial
Next. I think it's a fair assumption that the APIs around app data and
user prefs may change in the near future. I am not sure if we can do this
in 2.1 since it may require some API changes, and that may not be allowed,
but I am not sure about that.
I am kind of indifferent on how user prefs are stored in a reference
implementation, its more about demonstrating the concept. The other
option I would like to throw out there is to use an HTML 5 web database to
store user prefs. While this certainly is not a production level
implementation, it eliminates the confusion of using app data to store
user prefs.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: daviesd <da...@oclc.org>
To: <de...@shindig.apache.org>,
Cc: Ryan J Baxter/Westford/IBM@Lotus
Date: 07/29/2011 10:41 AM
Subject: Re: Example implementation for user prefs?
In our implementation the siteid SHOULD be unique and specific to an
instance of a gadget (I¹m still working out the details on this). So they
won¹t be reused. That still means appdata could be queried and user
preferences visible to others. However I¹m working off this comment...
> http://permalink.gmane.org/gmane.comp.web.shindig.devel/6998
> This sentence is there in the 2.0 draft version as well[2], but there is
> some draft language in the Social API spec about allowing you, when you
> create or update appdata entries, to set the groupId of the group
allowed to
> see the data[3] (defaults to "@app" for backwards compatibility, setting
it
> to "@self" would mean only the viewer could read it). Don't know
when/if
> that will make it in to the final version.
Which I think says, eventually opensocial 2.0 containers SHOULD restrict
visibility of appdata based on the groupid used when setting the appdata.
Am I off base here?
This means in the interim we have this gaping hole, so the gadgets we are
developing (which are really our main focus for the container, not other
gadgets) need to make sure no sensitive information is stored in user
preferences. I figured I¹d move towards the spec instead of doing
something
completely different and having to catch up with the spec. But then again
maybe I¹m trying to overload appdata too much, but the concepts seem so
similar that I think the spec change would help converge them.
So... With that said... Is an appdata implmentation of userprefs still
something that would be useful in the default shindig implementation if
that¹s the direction things are headed? Or does this lead one down the
wrong path and maybe a cookie base implementation (like sample container
used) is a better solution.
doug
On 7/28/11 8:41 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
> 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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: daviesd <da...@oclc.org>
> To: <de...@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 <da...@oclc.org>
>>> >> To: <de...@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" <dd...@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 <da...@oclc.org>
>>>> >>> To: <de...@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" <li...@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 <da...@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" <he...@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
<ma...@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
>>>>>>>>> <ma...@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
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>> >>>>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>> >>
>>> >>
>>> >>
>>> >>
>> >
>> >
>
>
>
>
>
>
RE: Example implementation for user prefs?
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>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?
Yes -- if your using the common container code standalone out of the box I think this could definitely happen -- which serves to illuminate the fact that (depending on what your trying to do) you can only get just so far by using the common container standalone (without also having a server side component to help offload some of the heavy lifting). Someone (Dan maybe?) pushed a patch through recently that makes common container prefer a siteId parsed from the one of the HTML elements containing the gadget site -- so with that patch in place you can have a server side component which generates gadget site container elements with guaranteed unique and consistent id's for gadget instances and the common container will pick them up and use them when rendering the gadget sites.
There are lots of other cases where the need for a server side component comes up as well -- one example that comes to mind is drag n' drop -- if you want users to be able to arrange gadgets on their page you really need to persist that state server side somewhere so that its available to the user no matter how they're accessing the application (different computers etc). Another thing that is likely problematic without a server side component is security token generation -- without a server side component you have to rely on the security token to come back in the shindig metadata call that the common container makes when rendering a gadget site. This means at a minimum you need to run your shindig server behind single sign on (so shindig can properly generate a security token for the logged in user) -- but in the case where the container page and shindig are not on the same domain (which you likely want for security) then you need to proxy the call from your container domain to the shindig server -- and since shindig needs authentication to generate security tokens this means now you're doing something like proxying the users SSO cookies along with the proxied metadata request (which means you had to do bad things to the configuration on your SSO servers to allow tokens to be used from anywhere -- not just the client IP they were originally issued to)...
Just to be clear though -- none of this should be taken as a knock against the common container. I think the point of it is to make turning a web page into a gadget container as simple as doing a script include for some JavaScript libraries and away you go -- and it does a good job of that -- and if your requirements are simple, your done. And it also allows you to replace the bits and pieces that you want to do on your own with a server side component as well but still use the rest of the common functionality it provides. For example in Rave we fetch the shindig metadata on the server side (where we'll likely start caching it since it doesn't change often), embed it in the page, then use it to prime the common container metadata cache before we ask common container to render gadget sites -- and by doing that common container no longer has to make the metadata call from the client side. We're also planning to generate security tokens in our server side component and push them into the common container as well so shindig can then run on any domain and not need to authenticate users at all.
>-Ryan
>
>Email: rjbaxter@us.ibm.com
>Phone: 978-899-3041
>developerWorks Profile
>
>
>
>From: daviesd <da...@oclc.org>
>To: <de...@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 <da...@oclc.org>
>>> To: <de...@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" <dd...@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 <da...@oclc.org>
>>>> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
Re: Example implementation for user prefs?
Posted by daviesd <da...@oclc.org>.
In our implementation the siteid SHOULD be unique and specific to an
instance of a gadget (I¹m still working out the details on this). So they
won¹t be reused. That still means appdata could be queried and user
preferences visible to others. However I¹m working off this comment...
> http://permalink.gmane.org/gmane.comp.web.shindig.devel/6998
> This sentence is there in the 2.0 draft version as well[2], but there is
> some draft language in the Social API spec about allowing you, when you
> create or update appdata entries, to set the groupId of the group allowed to
> see the data[3] (defaults to "@app" for backwards compatibility, setting it
> to "@self" would mean only the viewer could read it). Don't know when/if
> that will make it in to the final version.
Which I think says, eventually opensocial 2.0 containers SHOULD restrict
visibility of appdata based on the groupid used when setting the appdata.
Am I off base here?
This means in the interim we have this gaping hole, so the gadgets we are
developing (which are really our main focus for the container, not other
gadgets) need to make sure no sensitive information is stored in user
preferences. I figured I¹d move towards the spec instead of doing something
completely different and having to catch up with the spec. But then again
maybe I¹m trying to overload appdata too much, but the concepts seem so
similar that I think the spec change would help converge them.
So... With that said... Is an appdata implmentation of userprefs still
something that would be useful in the default shindig implementation if
that¹s the direction things are headed? Or does this lead one down the
wrong path and maybe a cookie base implementation (like sample container
used) is a better solution.
doug
On 7/28/11 8:41 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
> 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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: daviesd <da...@oclc.org>
> To: <de...@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 <da...@oclc.org>
>>> >> To: <de...@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" <dd...@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 <da...@oclc.org>
>>>> >>> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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
>>>>>>>>> <ma...@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
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>> >>>>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>> >>
>>> >>
>>> >>
>>> >>
>> >
>> >
>
>
>
>
>
>
Re: Example implementation for user prefs?
Posted by Ryan J Baxter <rj...@us.ibm.com>.
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: daviesd <da...@oclc.org>
To: <de...@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 <da...@oclc.org>
>> To: <de...@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" <dd...@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 <da...@oclc.org>
>>> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
Re: Example implementation for user prefs?
Posted by daviesd <da...@oclc.org>.
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 <da...@oclc.org>
>> To: <de...@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" <dd...@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 <da...@oclc.org>
>>> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
RE: Example implementation for user prefs?
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>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 <da...@oclc.org>
>To: <de...@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" <dd...@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 <da...@oclc.org>
>> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
Are more dependency upgrades planned for Shindig 3.0.0?
Posted by Matthew G Marum <mg...@us.ibm.com>.
Do people have Java dependency changes that they know they need to get in
before the GA of Shindig 3.0.0? Obviously, not every change can be
anticipated but if there's something in the pipe, we'd love to get a heads
up about it.
Matt Marum
Re: Example implementation for user prefs?
Posted by daviesd <da...@oclc.org>.
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" <da...@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" <dd...@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 <da...@oclc.org>
>> To: <de...@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" <dd...@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 <da...@oclc.org>
>>> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
Re: Example implementation for user prefs?
Posted by daviesd <da...@oclc.org>.
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" <dd...@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-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 <da...@oclc.org>
> To: <de...@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" <dd...@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 <da...@oclc.org>
>> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
Re: Example implementation for user prefs?
Posted by Dan Dumont <dd...@us.ibm.com>.
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-Container.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 <da...@oclc.org>
To: <de...@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" <dd...@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 <da...@oclc.org>
> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>
>
>
Re: Example implementation for user prefs?
Posted by daviesd <da...@oclc.org>.
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" <dd...@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 <da...@oclc.org>
> To: <de...@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" <dd...@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 <da...@oclc.org>
>> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
>
Re: Example implementation for user prefs?
Posted by daviesd <da...@oclc.org>.
Dan,
Thanks. This is working for the most part, however I'm having issues with
the GET_PREFERENCES function. In my implementation I need to gadget site
(not just the id) so I do
var site = self.sites_[siteId];
This returns me the right site, however then when I go to get the gadget
holder
var holder = site.getActiveGadgetHolder();
It's null. It appears this should be either returning the loading or
current gadget holder. Just wondering if the get_preferences is being
called too early before things are setup completely.
doug
On 7/27/11 3:33 PM, "Dan Dumont" <dd...@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 <da...@oclc.org>
> To: <de...@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" <dd...@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 <da...@oclc.org>
>> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
>
Re: Example implementation for user prefs?
Posted by daviesd <da...@oclc.org>.
Dan,
Have you seen an timing issues with this setpref implementation? I am
seeing strange things. I'm using the horoscope gadget which renders
differently if the user preferences have been set (it shows your horoscope
based on a uid). Sometimes this works and sometimes it doesn't. What's
strange is it seems that switching the id of the html element (which then is
used as the siteid) is what's causing the behavior to change. I'll do some
more investigation, just wondered if you had seen any peculiarities like
that.
doug
On 7/27/11 3:33 PM, "Dan Dumont" <dd...@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 <da...@oclc.org>
> To: <de...@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" <dd...@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 <da...@oclc.org>
>> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
>
Re: Example implementation for user prefs?
Posted by Dan Dumont <dd...@us.ibm.com>.
http://opensocial-resources.googlecode.com/svn/spec/2.0/incubating/Core-Container.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 <da...@oclc.org>
To: <de...@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" <dd...@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 <da...@oclc.org>
> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>
>
>
Re: Example implementation for user prefs?
Posted by daviesd <da...@oclc.org>.
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" <dd...@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 <da...@oclc.org>
> To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>
>
>
Re: Example implementation for user prefs?
Posted by Dan Dumont <dd...@us.ibm.com>.
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 <da...@oclc.org>
To: <de...@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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>
>>>>>
>>>
>>>
>>
>>
>
Re: Example implementation for user prefs?
Posted by daviesd <da...@oclc.org>.
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" <li...@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 <da...@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" <he...@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 <ma...@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 <ma...@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
>>>>>>>
>>>>>
>>>
>>>
>>
>>
>
Re: Example implementation for user prefs?
Posted by Paul Lindner <li...@inuus.com>.
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 <da...@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" <he...@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 <ma...@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 <ma...@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
> >>> >>
> >> >
> >
> >
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: Example implementation for user prefs?
Posted by Craig McClanahan <cr...@apache.org>.
On Thu, Jul 28, 2011 at 6:18 PM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> 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.
>
> FWIW, we (Jive) also implement user preferences per user + gadget instance
(as well as disallowing any other user from seeing another user's
preferences settings, which is why basing an implementation on top of
appdata would seem problematic to me). This is based on two factors:
* The gadgets API accepts an optional "module id" for which you want to
retrieve user preferences.
* I could find informal definitions of the term "module id" in pre-1.0
versions of the OpenSocial spec
as "an integer identifier for the gadget in a given container context."
This also makes sense looking at use cases. For example, I might want to
install multiple instances of a stock ticker gadget, each configured to
watch different sets of stocks, so I could see both instances at the same
time in some sort of dashboard.
Craig McClanahan
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Henry Saputra <he...@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:daviesd@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" <he...@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 <ma...@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 <ma...@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
> >>>>> >>
> >>>> >
> >>>
> >>>
> >
> >
>
>
>
>
Re: Example implementation for user prefs?
Posted by Ryan J Baxter <rj...@us.ibm.com>.
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Henry Saputra <he...@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:daviesd@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" <he...@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 <ma...@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 <ma...@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
>>>>> >>
>>>> >
>>>
>>>
>
>
Re: Example implementation for user prefs?
Posted by Henry Saputra <he...@gmail.com>.
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:daviesd@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" <he...@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 <ma...@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 <ma...@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
>>>>> >>
>>>> >
>>>
>>>
>
>
RE: Example implementation for user prefs?
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
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:daviesd@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" <he...@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 <ma...@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 <ma...@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
>>>> >>
>>> >
>>
>>
Re: Example implementation for user prefs?
Posted by daviesd <da...@oclc.org>.
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" <he...@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 <ma...@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 <ma...@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
>>> >>
>> >
>
>
Re: Example implementation for user prefs?
Posted by Henry Saputra <he...@gmail.com>.
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 <ma...@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 <ma...@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
>>
>
Re: Example implementation for user prefs?
Posted by Mat Schaffer <ma...@schaffer.me>.
On Tue, Jul 26, 2011 at 5:17 AM, Ciancetta, Jesse E. <jc...@mitre.org>wrote:
> >So with some research it looks like I'm supposed to be implementing my own
> >server module. Is that pretty much accurate?
>
> Yes -- you'll need to implement both the client side UI for editing
> preferences and the server side API for persisting them. I actually just
> did that work though for the Apache Rave project last week so you can have a
> look at that implementation to see how it was done. It isn't part of a Rave
> release yet though so to see it working you'll need to build and run from
> the latest source. One thing to note is that it doesn't have the container
> side RPC hook implemented yet for the gadgets.Prefs API to use (so
> prefs.set(...) from within a gadget doesn't work yet) but that's pretty
> straightforward to implement -- we just haven't gotten to it yet. If you
> have any questions about the implementation feel free to post them over on
> the rave-dev list - and if Rave looks useful to you please feel free to jump
> in and get involved with the project!
>
> One other thought -- you mentioned shindig-container.js in your last
> message -- I believe that is part of the older shindig sample container
> which is being replaced by the newer common container code. Rave is using
> the common container code so you can look there for some insight into how
> we're using it.
Sweet, thanks! I'll have to give Rave a look.
-Mat
RE: Example implementation for user prefs?
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>So with some research it looks like I'm supposed to be implementing my own
>server module. Is that pretty much accurate?
Yes -- you'll need to implement both the client side UI for editing preferences and the server side API for persisting them. I actually just did that work though for the Apache Rave project last week so you can have a look at that implementation to see how it was done. It isn't part of a Rave release yet though so to see it working you'll need to build and run from the latest source. One thing to note is that it doesn't have the container side RPC hook implemented yet for the gadgets.Prefs API to use (so prefs.set(...) from within a gadget doesn't work yet) but that's pretty straightforward to implement -- we just haven't gotten to it yet. If you have any questions about the implementation feel free to post them over on the rave-dev list - and if Rave looks useful to you please feel free to jump in and get involved with the project!
One other thought -- you mentioned shindig-container.js in your last message -- I believe that is part of the older shindig sample container which is being replaced by the newer common container code. Rave is using the common container code so you can look there for some insight into how we're using it.
>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 <ma...@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
>>
Re: Example implementation for user prefs?
Posted by Mat Schaffer <ma...@schaffer.me>.
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 <ma...@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
>