Ok. Thanks.
A little more info.
Here¹s my code that works
var content = document.createElement( 'DIV' );
content.id = 'app-x';
document.getElementById( 'gadget-wrapper' ).appendChild( content
);
var gadgetSite = container.newGadgetSite( content );
container.navigateGadget( gadgetSite,
'http://www.google.com/ig/modules/horoscope.xml', [], {} );
> <div id="gadget-wrapper" class="gadgets-gadget-chrome"></div>
If all I do is change the id
content.id = 'app-1';
It stops working.
The iframe urls end up different too. In the first case it has the up_uid
that it needs to lookup the horoscope
//localhost:8080/opensocial/gadgets/ifr?url=http%3A%2F%2Fwww.google.com%2Fig
%2Fmodules%2Fhoroscope.xml&container=oclc&view=default&lang=en&country=US&de
bug=0&nocache=0&sanitize=0&v=86819abe8eb2f9f10cd8ec89420fc7a9&testmode=0&par
ent=http%3A%2F%2Flocalhost%3A8080&mid=app-x#up_day=&up_month=&up_selectedTab
=0&up_uid=80432da8a9d14b25f8f2e461562f6d65fc99a4f6&up_selectedFriend=0
In the second case it¹s empty
//localhost:8080/opensocial/gadgets/ifr?url=http%3A%2F%2Fwww.google.com%2Fig
%2Fmodules%2Fhoroscope.xml&container=oclc&view=default&lang=en&country=US&de
bug=0&nocache=0&sanitize=0&v=86819abe8eb2f9f10cd8ec89420fc7a9&testmode=0&par
ent=http%3A%2F%2Flocalhost%3A8080&mid=app-1#up_day=&up_month=&up_selectedTab
=0&up_uid=&up_selectedFriend=0
Strange. I¹ll keep you posted if I find anything else. If you have any
ideas, thanks. I¹m gonna dig into the appdata keys and see if numbers some
how mess it up.
Doug
On 8/2/11 12:17 PM, "Dan Dumont" <ddum...@us.ibm.com> wrote:
> I haven't, is your container changing the id of the element or site after the
> fact?
>
> When I get back from vacation, I'll take a peek and see if it's anything in
> the common container code changing the id of the site.
>
> -----daviesd <davi...@oclc.org> wrote: -----
> To: <dev@shindig.apache.org>
> From: daviesd <davi...@oclc.org>
> Date: 08/02/2011 12:02PM
> Cc: Dan Dumont/Westford/IBM@Lotus
> Subject: Re: Example implementation for user prefs?
>
> 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" <ddum...@us.ibm.com> wrote:
>
>> >
>>
http://opensocial-resources.googlecode.com/svn/spec/2.0/incubating/Core-Contai
>> > ner.xml#Configuring-The-Container
>> >
>> >
>> > When you insantiate the common container, you can provide these functions,
>> > keyed appropriately, via the config object.
>> >
>> > The GET_PREFERENCES function will be called as defined when making the
>> > metadata request to the server. The prefs will be supplied to the
>> > server, which will use any provided ones instead of default preferences
>> > when providing the metadata for a gadget. This all happens automatically
>> > in a call to navigate gadget...and now that I think about it, I forgot to
>> > include it in the preLoad method in the common container... I'll submit a
>> > patch shortly.
>> >
>> > The server side impl is totally up to you. I originally had in mind a
>> > client-side html5 store for a default implementation.
>> >
>> > The gadget site encapsulates the site ID. It will prefer the id attr of
>> > the site element you created the site with, otherwise it will default to
>> > an auto-incremented number.
>> >
>> > If you wish to persist preferences for a particular occurrence of a
>> > gadget(per gadget url instance), then you'll need to keep track of the
>> > site (the auto generated ids are less helpful), if you wish to provide
>> > "per gadget url" preferences you can just ignore they siteid and return or
>> > persist the preferences for all gadgets coming from that url.
>> >
>> >
>> >
>> >
>> > From: daviesd <davi...@oclc.org>
>> > To: <dev@shindig.apache.org>,
>> > Date: 07/27/2011 03:22 PM
>> > Subject: Re: Example implementation for user prefs?
>> >
>> >
>> >
>> > Dan,
>> >
>> > Nice! I'm still using 3.0.0-beta2, so hadn't seen this yet. Was there an
>> > earlier thread on how to use this? Can you explain how I hook into this
>> > and
>> > provide a server-side implementation? And does this mean when I call
>> > navigateGadget that I should now be providing a unique id for the siteId
>> > (maybe correlating to my spaceid?)?
>> >
>> > Thanks,
>> > doug
>> >
>> >
>> > On 7/27/11 1:50 PM, "Dan Dumont" <ddum...@us.ibm.com> wrote:
>> >
>>> >> FYI, there have been some recent changes in the common container to
>> > expose
>>> >> a callback to the container page that allows for the persisting and
>>> >> retrieval of persisted preferences.
>>> >>
>>> >> /**
>>> >> * @see setprefs.js setprefs feature.
>>> >> */
>>> >> this.rpcRegister('set_pref', function(rpcArgs, key, value) {
>>> >> var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY];
>>> >> var setPrefs =
>>> >> self.config_[osapi.container.ContainerConfig.SET_PREFERENCES];
>>> >> if (site && setPrefs) { // Check if site is not already closed.
>>> >> var data = {};
>>> >> for (var i = 2, j = arguments.length; i < j; i += 2) {
>>> >> data[arguments[i]] = arguments[i + 1];
>>> >> }
>>> >> setPrefs(site.getId(), site.getActiveGadgetHolder().getUrl(),
>> > data);
>>> >> }
>>> >> });
>>> >>
>>> >> A container may specify functions to the CommonContainer that will be
>>> >> called to retrieve and set preferences for a particular gadget.
>>> >> Please also note that gadget site id will now prefer the id attribute of
>>> >> the gadget site element, so that named locations for specific gadgets
>> > can
>>> >> have preferences persisted accordingly.
>>> >>
>>> >> If you are going to be providing a default preference persistence impl,
>> > it
>>> >> would be great if you could hook into this :)
>>> >>
>>> >>
>>> >>
>>> >> From: daviesd <davi...@oclc.org>
>>> >> To: <dev@shindig.apache.org>,
>>> >> Date: 07/27/2011 01:09 PM
>>> >> Subject: Re: Example implementation for user prefs?
>>> >>
>>> >>
>>> >>
>>> >> Paul,
>>> >>
>>> >> Sure. Give me a few days, I just got back from vacation. I'll have to
>>> >> figure
>>> >> out whether the container token will be sufficient for this, as I had to
>>> >> apply other patches to get the gadget token to be used.
>>> >>
>>> >> Thanks,
>>> >> doug
>>> >>
>>> >>
>>> >> On 7/27/11 12:58 PM, "Paul Lindner" <lind...@inuus.com> wrote:
>>> >>
>>>> >>> Can you write this up a patch so we can make this the default
>>>> >>> implementation? This is something I've been meaning to do for months.
>>>> >>>
>>>> >>> On Wed, Jul 27, 2011 at 8:58 AM, daviesd <davi...@oclc.org> wrote:
>>>> >>>
>>>>> >>>> Actually, I was lazy and went with the approach of layering userprefs
>>> >> on
>>>>> >>>> top
>>>>> >>>> of appdata as follows:
>>>>> >>>>
>>>>> >>>> container.rpcRegister('set_pref', function(rpcArgs, data) {
>>>>> >>>>
>>>>> >>>> var prefName = rpcArgs['a'][1];
>>>>> >>>> var prefKey = 'up_' + prefName;
>>>>> >>>> var prefValue = rpcArgs['a'][2];
>>>>> >>>>
>>>>> >>>> var data = {};
>>>>> >>>> data[prefKey] = prefValue;
>>>>> >>>>
>>>>> >>>> osapi.appdata.update({
>>>>> >>>> userid : '@me',
>>>>> >>>> groupid : '@self',
>>>>> >>>> appId : '@app',
>>>>> >>>> data : data
>>>>> >>>>
>>>>> >>>> }).execute(function(response) {
>>>>> >>>> });
>>>>> >>>> });
>>>>> >>>>
>>>>> >>>> This is with anticipation that appdata and userprefs will align as
>>>>> >>>> discussed
>>>>> >>>> here:
>>>>> >>>>
>>>>> >>>> http://code.google.com/p/opensocial-resources/issues/detail?id=1182
>>>>> >>>>
>>>>> >>>> Of course this also requires you to implement appdata server side.
>>> >> Right
>>>>> >>>> now I¹m just using the JsonDb implementation (in-memory), but we¹ll
be
>>>>> >>>> writing a persistent layer soon.
>>>>> >>>>
>>>>> >>>> I also ran into issues with the correct token (the gadget one with
the
>>>>> >>>> appid
>>>>> >>>> that you¹ll need to use to index the data) being passed to the
>>>>> appdata
>>>>> >>>> request. You can search for my other thread about this.
>>>>> >>>>
>>>>> >>>> doug
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On 7/25/11 6:53 PM, "Henry Saputra" <henry.sapu...@gmail.com> wrote:
>>>>> >>>>
>>>>>> >>>>> If you want the user pref to be persisted in the database you need
to
>>>>>> >>>>> implement the server handler for it.
>>>>>> >>>>>
>>>>>> >>>>> I remember Doug Davies has tried to add persistent layer for user
>>>>>> >>>>> pref. Maybe he could share his progress.
>>>>>> >>>>>
>>>>>> >>>>> Including him in the email.
>>>>>> >>>>>
>>>>>> >>>>> - Henry
>>>>>> >>>>>
>>>>>> >>>>> On Mon, Jul 25, 2011 at 3:42 PM, Mat Schaffer <m...@schaffer.me>
>> > wrote:
>>>>>>>> >>>>>>> So with some research it looks like I'm supposed to be
>>>>>>>> implementing
>>> >> my
>>>>> >>>> own
>>>>>>>> >>>>>>> server module. Is that pretty much accurate?
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> Again, any advice or RTFMs (with a link to the respective FMs)
is
>>>>>>>> >>>>>>> appreciated.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> Thanks,
>>>>>>>> >>>>>>> Mat
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> On Fri, Jul 22, 2011 at 10:20 AM, Mat Schaffer
>>>>>>>> <m...@schaffer.me>
>>>>> >>>> wrote:
>>>>>>>> >>>>>>>
>>>>>>>>>> >>>>>>>>> So I noticed that UserPref items don't work on the sample
>>> >> container
>>>>> >>>> which
>>>>>>>>>> >>>>>>>>> makes sense after finding this thread:
>>>>>>>>>> >>>>>>>>> http://markmail.org/message/tlwtlo4mrnrpz4w5
>>>>>>>>>> >>>>>>>>>
>>>>>>>>>> >>>>>>>>> Is there any good example of best-practice for implementing
user
>>>>> >>>> prefs in
>>>>>>>>>> >>>>>>>>> my containing application? Do I just make my own
>>>>> >>>> shindig-container.js and
>>>>>>>>>> >>>>>>>>> handleOpenUserPrefsDialog? And does the page we point to
just
>>> >> render
>>>>>>>>>> >>>>>>>>> information into a div with id of `this.id`?
>>>>>>>>>> >>>>>>>>>
>>>>>>>>>> >>>>>>>>> The gmodule code appears to be obfuscated, so it's a bit
hard to
>>>>> >>>> tell >>>
>>>>> >>>> what
>>>>>>>>>> >>>>>>>>> the right course of action would be. Any documentation or
>>> >> assistance
>>>>>>>> >>>>>>> would
>>>>>>>>>> >>>>>>>>> be appreciated.
>>>>>>>>>> >>>>>>>>>
>>>>>>>>>> >>>>>>>>> Thanks,
>>>>>>>>>> >>>>>>>>> Mat
>>>>>>>>>> >>>>>>>>>
>>>>>>>> >>>>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>> >>>>
>>>>> >>>>
>>>> >>>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>> >
>> >
>> >
>> >
>> >
>
>
>
>
