>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: rjbax...@us.ibm.com
>Phone: 978-899-3041
>developerWorks Profile
>
>
>
>From: daviesd <davi...@oclc.org>
>To: <dev@shindig.apache.org>,
>Date: 07/28/2011 11:55 AM
>Subject: Re: Example implementation for user prefs?
>
>
>
>Jesse,
>
>I think you are correct that it should be per instance. That's where the
>siteid would come into play. At least that's how I'm reading it (and now
>implementing it). In our case a particular gadget always renders in the
>same
>siteid. Two instances of the same gadget would have different siteids,
>thus
>different preferences.
>
>doug
>
>On 7/28/11 11:51 AM, "Ciancetta, Jesse E." <jc...@mitre.org> wrote:
>
>>> If you wish to persist preferences for a particular occurrence of a
>>> gadget(per gadget url instance), then you'll need to keep track of the
>>> site (the auto generated ids are less helpful), if you wish to provide
>>> "per gadget url" preferences you can just ignore they siteid and return
>or
>>> persist the preferences for all gadgets coming from that url.
>>
>> But if we're talking about providing a reference implementation to
>server as a
>> sample for anyone using the common container -- that implementation
>should be
>> saving preferences per gadget instance, right? I believe that user
>> preferences are supposed to be stored per user/per gadget instance
>(although I
>> just took a quick glance through the 2.0 spec and couldn't find any
>language
>> to support that).
>>
>> Can anyone confirm or deny that to actually be the case (and maybe
>provide a
>> reference to where it's specified)?
>>
>>> From: daviesd <davi...@oclc.org>
>>> To: <dev@shindig.apache.org>,
>>> Date: 07/27/2011 03:22 PM
>>> Subject: Re: Example implementation for user prefs?
>>>
>>>
>>>
>>> Dan,
>>>
>>> Nice! I'm still using 3.0.0-beta2, so hadn't seen this yet. Was there
>an
>>> earlier thread on how to use this? Can you explain how I hook into
>this
>>> and
>>> provide a server-side implementation? And does this mean when I call
>>> navigateGadget that I should now be providing a unique id for the
>siteId
>>> (maybe correlating to my spaceid?)?
>>>
>>> Thanks,
>>> doug
>>>
>>>
>>> On 7/27/11 1:50 PM, "Dan Dumont" <ddum...@us.ibm.com> wrote:
>>>
>>>> FYI, there have been some recent changes in the common container to
>>> expose
>>>> a callback to the container page that allows for the persisting and
>>>> retrieval of persisted preferences.
>>>>
>>>> /**
>>>> * @see setprefs.js setprefs feature.
>>>> */
>>>> this.rpcRegister('set_pref', function(rpcArgs, key, value) {
>>>> var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY];
>>>> var setPrefs =
>>>> self.config_[osapi.container.ContainerConfig.SET_PREFERENCES];
>>>> if (site && setPrefs) { // Check if site is not already closed.
>>>> var data = {};
>>>> for (var i = 2, j = arguments.length; i < j; i += 2) {
>>>> data[arguments[i]] = arguments[i + 1];
>>>> }
>>>> setPrefs(site.getId(), site.getActiveGadgetHolder().getUrl(),
>>> data);
>>>> }
>>>> });
>>>>
>>>> A container may specify functions to the CommonContainer that will be
>>>> called to retrieve and set preferences for a particular gadget.
>>>> Please also note that gadget site id will now prefer the id attribute
>of
>>>> the gadget site element, so that named locations for specific gadgets
>>> can
>>>> have preferences persisted accordingly.
>>>>
>>>> If you are going to be providing a default preference persistence
>impl,
>>> it
>>>> would be great if you could hook into this :)
>>>>
>>>>
>>>>
>>>> From: daviesd <davi...@oclc.org>
>>>> To: <dev@shindig.apache.org>,
>>>> Date: 07/27/2011 01:09 PM
>>>> Subject: Re: Example implementation for user prefs?
>>>>
>>>>
>>>>
>>>> Paul,
>>>>
>>>> Sure. Give me a few days, I just got back from vacation. I'll have to
>>>> figure
>>>> out whether the container token will be sufficient for this, as I had
>to
>>>> apply other patches to get the gadget token to be used.
>>>>
>>>> Thanks,
>>>> doug
>>>>
>>>>
>>>> On 7/27/11 12:58 PM, "Paul Lindner" <lind...@inuus.com> wrote:
>>>>
>>>>> Can you write this up a patch so we can make this the default
>>>>> implementation? This is something I've been meaning to do for
>months.
>>>>>
>>>>> On Wed, Jul 27, 2011 at 8:58 AM, daviesd <davi...@oclc.org> wrote:
>>>>>
>>>>>> Actually, I was lazy and went with the approach of layering
>userprefs
>>>> on
>>>>>> top
>>>>>> of appdata as follows:
>>>>>>
>>>>>> container.rpcRegister('set_pref', function(rpcArgs, data) {
>>>>>>
>>>>>> var prefName = rpcArgs['a'][1];
>>>>>> var prefKey = 'up_' + prefName;
>>>>>> var prefValue = rpcArgs['a'][2];
>>>>>>
>>>>>> var data = {};
>>>>>> data[prefKey] = prefValue;
>>>>>>
>>>>>> osapi.appdata.update({
>>>>>> userid : '@me',
>>>>>> groupid : '@self',
>>>>>> appId : '@app',
>>>>>> data : data
>>>>>>
>>>>>> }).execute(function(response) {
>>>>>> });
>>>>>> });
>>>>>>
>>>>>> This is with anticipation that appdata and userprefs will align as
>>>>>> discussed
>>>>>> here:
>>>>>>
>>>>>> http://code.google.com/p/opensocial-
>resources/issues/detail?id=1182
>>>>>>
>>>>>> Of course this also requires you to implement appdata server side.
>>>> Right
>>>>>> now I¹m just using the JsonDb implementation (in-memory), but we¹ll
>be
>>>>>> writing a persistent layer soon.
>>>>>>
>>>>>> I also ran into issues with the correct token (the gadget one with
>the
>>>>>> appid
>>>>>> that you¹ll need to use to index the data) being passed to the
>appdata
>>>>>> request. You can search for my other thread about this.
>>>>>>
>>>>>> doug
>>>>>>
>>>>>>
>>>>>> On 7/25/11 6:53 PM, "Henry Saputra" <henry.sapu...@gmail.com>
>>> wrote:
>>>>>>
>>>>>>> If you want the user pref to be persisted in the database you need
>to
>>>>>>> implement the server handler for it.
>>>>>>>
>>>>>>> I remember Doug Davies has tried to add persistent layer for user
>>>>>>> pref. Maybe he could share his progress.
>>>>>>>
>>>>>>> Including him in the email.
>>>>>>>
>>>>>>> - Henry
>>>>>>>
>>>>>>> On Mon, Jul 25, 2011 at 3:42 PM, Mat Schaffer <m...@schaffer.me>
>>> wrote:
>>>>>>>>> So with some research it looks like I'm supposed to be
>implementing
>>>> my
>>>>>> own
>>>>>>>>> server module. Is that pretty much accurate?
>>>>>>>>>
>>>>>>>>> Again, any advice or RTFMs (with a link to the respective FMs) is
>>>>>>>>> appreciated.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Mat
>>>>>>>>>
>>>>>>>>> On Fri, Jul 22, 2011 at 10:20 AM, Mat Schaffer <m...@schaffer.me>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>> So I noticed that UserPref items don't work on the sample
>>>> container
>>>>>> which
>>>>>>>>>>> makes sense after finding this thread:
>>>>>>>>>>> http://markmail.org/message/tlwtlo4mrnrpz4w5
>>>>>>>>>>>
>>>>>>>>>>> Is there any good example of best-practice for implementing
>user
>>>>>> prefs in
>>>>>>>>>>> my containing application? Do I just make my own
>>>>>> shindig-container.js and
>>>>>>>>>>> handleOpenUserPrefsDialog? And does the page we point to
>just
>>>> render
>>>>>>>>>>> information into a div with id of `this.id`?
>>>>>>>>>>>
>>>>>>>>>>> The gmodule code appears to be obfuscated, so it's a bit hard
>to
>>>>>> tell >>>
>>>>>> what
>>>>>>>>>>> the right course of action would be. Any documentation or
>>>> assistance
>>>>>>>>> would
>>>>>>>>>>> be appreciated.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Mat
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
