You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@shindig.apache.org by Justin Wyllie <ju...@hotmail.co.uk> on 2010/11/01 14:12:48 UTC

RE: userPrefs is undefined / getting UserPreferences to work













Hi Peter
Are you using the PHP or Java version btw?

I hope this helps - you may just need to pick out the bits that apply:
By the prefs dialog do you mean the box that appears on iGoogle when you click 'Edit Settings'? If so - it isn't there in Shindig. You have to make your own. What we do is:
A. Make a metadata request on the server. B. Get the default prefs (values and types) out of the metadataC. Over-write any we've saved for this userD. Build a little fragment of HTML for the settings box - there are I think 5 types of data types e.g. STRING, BOOL, ENUM and populate with the defaults (or saved user ones from C). I'm happy to share our PHP code with you if it would just make it clearer what is going on.E. Output this with the iframe source. The user can then edit them.
You would not do C. if you aren't saving them.
>From your code though it looks like you are rendering the gadgets on the client. I think you based this on the sample container page? http://yourdomain:yourport/gadgets/files/samplecontainer/samplecontainer.html ? 
Anyway I tried to reproduce your error on one of my test sites: http://mms-oxford.com/shindig/index.html using gadget: http://mms-oxford.com/gadgets/prefs_test.xml  and I think I got something similar. I then solved it by:
adding this line: 
gadgets.rpc.register('set_pref', testPrefs);
and the function:
function testPrefs(t,name,value) {alert('trying to save user prefs');alert (name);alert(value);alert(this.f);//now get the iframe src, replace the user pref params with the new ones and reload the gadget
//the main point in your case is that you want to put the new params onto the iframe source with up_name=value - and reload the iframe. This will cause the new params to be available in the gadget code so a request to get a param would now get the new one.
//reload the gadget by setting its src property?? can cause an error}
A working version of the above in Partuza container.js:
	setUserPref: function(editToken, name, value) {
		var elm = $('#' + this.f);
		// we use the security token to tell our backend who this is (app/mod/viewer)
		// since it's the only fail safe way of doing so
		if (elm != undefined) {
			var params = gadgets.container._parseIframeUrl(elm.attr('src'));
			//TODO use params.st to make the store request, it holds the owner / viewer / app id / mod id required
			var ret = $.ajax({
				type: "GET",
				dataType: 'html',
				cache: false,
				url : '/prefs/set',
				data : { name : name, value : value, st : params.st }
			});
		}
	},
A few things to pick up: the gadget http://mms-oxford.com/gadgets/prefs_test.xml has <Require feature="setprefs"/> in the head section. I think you got that.
When you click the Save button on the gadget it calls my function in the gadget (do view source on the gadget iframe and look for any user added code after all the included JS) which then calls this:
var prefs = new gadgets.Prefs();prefs.set("name",vname);
This makes an RPC call to the container. (There is a bunch of very interesting code in the Gadget Javascript which determines how it is going to make this RPC call. With modern browsers it uses postMessage. In some older browsers it won't work unless you set up an html_relay file - but we don't have one and it works in IE6+, Chrome and FF 3 - see rpc.js for the nitty gritty details). 
This is why you need to register a handler for that call:
gadgets.rpc.register('set_pref', testPrefs); //setUserPref is the partuza example
testPrefs here is your own function. Looking at the Shindig sample code there is an incomplete implementation of this. We copied ours from Partuza. Partuza is a sample PHP implementation of Shindig and fills in some of the gaps missing from Shindig. See http://code.google.com/p/partuza/. We just downloaded the code and looked at it - we didn't actually set up the site. 
The name and value are passed in from the prefs.set call in the gadget and this.f gives you the id of the iframe. The Partuza sample code then has a parameter replacement function - you can add the new params onto the iframe source and redraw the gadget - thus, without saving, your new prefs would be on the gadget. So the partuza code is well worth getting. Look especially at container.js. 
I should say that I have a problem with the above. If my testPrefs function tries to reload the gadget when set_prefs is called automatically by some other code (the tabs feature) the function causes an error. So for now my gadget does not refresh. Mostly your call to change the prefs would come from the settings box outside the gadget and this is not a problem. Ie. they are called by your own Javascript and not some Shindig code. To explain this a bit further: there are 2 cases - i) the call to update a pref comes from within a gadget and ii) the call comes from a Edit box you have provided as part of your container. The sample page I've sent you is case i). The second case which in fact is probably more common is like the iGoogle edit settings box. With i) the rpc mechanism comes into play as I've described. With ii) it is all up to you. You make the box and the save is whatever you want to do - in your cases of not needing persistence the main point is to modify the url src for your new params. (Look at a gadget with prefs in iGoogle and see how the iframe src is constructed - you see params being passed as up_paramname=value on the src). 
Finally - the line at the top where you include Shindig container code is important. You have:
<script type="text/javascript" src="http://localhost:8080/gadgets/js/shindig-container:rpc.js?c=1&debug=1"></script><script type="text/javascript" src="http://localhost:8080/gadgets/js/core.js?c=1&debug=1"></script>
We have in my sample:
<script type="text/javascript" src="http://198.66.163.13:85/gadgets/js/core:opensocial:rpc?debug=1"></script> 
The fields separated by a colon refer to Javascript files that you are including. You are using the shindig-container. We are not. In our full implementation we built our own container doing a pick and mix from the Shindig sample container and the partuza sample container (container.js). I don't know if any of the code you are including is trying to register another handler for set_prefs - if you use Chrome or Firebug you could try searching all the loaded resources to rpc.register to see.
Re. docs -
Yes. There is not very much at all. (Again Partuza helped us a lot). And the JS API is defined here:  http://wiki.opensocial.org/index.php?title=JavaScript_API_Reference. I *think* Shindig 2.0 supports OpenSocial 0.9 and 1.0 but it may be worth asking on the dev group about that.
HTH 0 let me know if I can add anything
Justin


> 
> Currently, I am using the mentioned "setUserPref" in
> shindig-container.js which sadly produces the error described in my last
> mail (this.userPrefs is undefined on line 5796 - which is taken from
> shindig-container.js, line 212) so I guess the basic functionality
> should work and should just be missing the persistence. So the handler
> should be registered and actually is called.

Are 


> 
> In another (older) setup, using
> shindig-server-1.1-BETA6-incubating-SNAPSHOT.war, the above (i.e.
> without persistence) is working fine and it is even showing the
> "Preference" Button + Dialog in the rendered gadget. For this, I'm using
> the sample4.html code from the old shindig, including the "cookies.js",
> "gadget.js" and "util.js" from the "container" (samples) directory of
> shindig 1.1.
> 
> Reading your mail I am starting to think that I may be missing a great
> deal of information about shindig. Could you point me to some ressources
> for setting up the gadget-rendering/javascript-feature part of shindig?
> 
> > I assume your gadget has <Require feature="setprefs"/>?
> I tried both (desperate me!) - with or without, doesnt make a difference
> concerning the error message in FireBug.
> 
> Regards,
> Peter



 		 	   		  

Persistence of userPrefs

Posted by Peter Rothenpieler <ro...@itm.uni-luebeck.de>.
Hi all,

After getting my UserPref-Dialog to work (see other thread), I'm now
trying to get the Persistence of my UserPref, using the AppDataService
as proposed e.g. in [1]. I have successfully set up my AppDataService by
implementing the AppDataService interface and binding it to the
AppDataService.class in my AbstractModule.
My intention is to use the AppDataService to e.g. set the
UserPreferences upon clicking the "save" Button in the rendered
Gadget-Preference-Panel. I understand that I need to implement my own
UserPrefStore (in shindig-container.js) and the Function
"shindig.DefaultUserPrefStore.prototype.savePrefs" is indeed called.
However I'm currently missing the connection to my AppDataServce in the
backend. I tried using the "osapi.appdata.update()" function as proposed
in [1] but sadly my AppDataService isn't called.

I'm getting an error message related a "malformed security token" (is
this a good "sign"?):

> 08.11.2010 17:02:33 org.apache.shindig.auth.AuthenticationServletFilter doFilter
> INFO: Malformed security token -1:-1:*::*:0:default
> org.apache.shindig.auth.SecurityTokenException: Malformed security token
>         at org.apache.shindig.auth.BasicSecurityTokenCodec.createToken(BasicSecurityTokenCodec.java:82)
>         at org.apache.shindig.auth.DefaultSecurityTokenCodec.createToken(DefaultSecurityTokenCodec.java:68)
>         at org.apache.shindig.auth.UrlParameterAuthenticationHandler.getSecurityTokenFromRequest(UrlParameterAuthen
> ticationHandler.java:56)
>         at org.apache.shindig.auth.AuthenticationServletFilter.doFilter(AuthenticationServletFilter.java:84)
>         at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
>         at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
>         at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>         at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>         at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
>         at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440)
>         at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>         at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>         at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>         at org.mortbay.jetty.Server.handle(Server.java:326)
>         at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>         at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943)
>         at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
>         at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
>         at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>         at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
>         at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

So does this mean I am on the right way and just need to correct
something regarding the security token or am I confusing some key
concept of shindig in this aspect?

-Peter

[1] http://www.mail-archive.com/dev@shindig.apache.org/msg01938.html

Re: userPrefs is undefined / getting UserPreferences to work

Posted by Peter Rothenpieler <ro...@itm.uni-luebeck.de>.
I am using "shindig-2.0.0-source.zip" (JAVA) downloaded from [1]

[1] http://shindig.apache.org/download/index.html

RE: userPrefs is undefined / getting UserPreferences to work

Posted by Justin Wyllie <ju...@hotmail.co.uk>.
Hi Peter
What version of Shindig are you using?




> Date: Wed, 3 Nov 2010 12:51:58 +0100
> From: rothenpieler@itm.uni-luebeck.de
> To: users@shindig.apache.org
> Subject: Re: userPrefs is undefined / getting UserPreferences to work
> 
> Hey Justin,
> 
> Just wanted to let you know that Shindig does offer a "settings-dialog"
> (see shindig.BaseIfrGadget.prototype.getTitleBarContent in
> shindig-container.js)
> 
> Also, I got the settings-dialog working with my gadget by adding the
> following line in shindig-container.js:
> 
> > shindig.Gadget = function(params) {
> >   this.userPrefs = {};
> >   if (params) {
> >     for (var name in params)  
> >       if (params.hasOwnProperty(name)) {
> >         this[name] = params[name];
> >         this.userPrefs[name] = params[name];  // <--- this one
> >       }
> >   }
> >   if (!this.secureToken) {
> >     // Assume that the default security token implementation is
> >     // in use on the server.
> >     this.secureToken = 'john.doe:john.doe:appid:cont:url:0:default';
> >   }
> > };
> 
> I'm not sure if this fixes all issues, but right now I think this pretty
> much helps me getting started with the preference-persistence on
> server-side. For this I am going to go through the other stuff which you
> posted in the last days.
> 
> Cheers,
> Peter
 		 	   		  

Re: userPrefs is undefined / getting UserPreferences to work

Posted by Peter Rothenpieler <ro...@itm.uni-luebeck.de>.
Hey Justin,

Just wanted to let you know that Shindig does offer a "settings-dialog"
(see shindig.BaseIfrGadget.prototype.getTitleBarContent in
shindig-container.js)

Also, I got the settings-dialog working with my gadget by adding the
following line in shindig-container.js:

> shindig.Gadget = function(params) {
>   this.userPrefs = {};
>   if (params) {
>     for (var name in params)  
>       if (params.hasOwnProperty(name)) {
>         this[name] = params[name];
>         this.userPrefs[name] = params[name];  // <--- this one
>       }
>   }
>   if (!this.secureToken) {
>     // Assume that the default security token implementation is
>     // in use on the server.
>     this.secureToken = 'john.doe:john.doe:appid:cont:url:0:default';
>   }
> };

I'm not sure if this fixes all issues, but right now I think this pretty
much helps me getting started with the preference-persistence on
server-side. For this I am going to go through the other stuff which you
posted in the last days.

Cheers,
Peter

RE: userPrefs is undefined / getting UserPreferences to work

Posted by Justin Wyllie <ju...@hotmail.co.uk>.
Hi Peter
I think one thing with Shindig is that it supports the Open Social spec but is not itself a portal. UserPrefs would be something that each different container is going to have to implement in it's own way. 
I think the reason there is so little documentation is that they are all busy writing the code. The dev@shindig.apache.org mailing list is where they all hang out - and they are quite helpful. I have to offer a disclaimer - I am definitely a user not a developer of Shindig. 
For learning - we used iGoogle a lot. I think it's based on Shindig so it's a good site to copy. You can look at the url strings, examine the XHR requests in Firebug etc and it helps a lot. Partuza helped. Once you understand the basics of the container, how JS files are loaded into the gadgets with a Require statement or into the web page with that gadgets/js:feature:feature syntax which I mentioned yesterday and the different services you are well on the way. 
I found some of the examples for gadgets I've used in developer sites on Ning etc. You do just have to hunt around for info. (I agree it's a pain).
regards
Justin 






> Date: Tue, 2 Nov 2010 09:31:28 +0100
> From: rothenpieler@itm.uni-luebeck.de
> To: users@shindig.apache.org
> Subject: Re: userPrefs is undefined / getting UserPreferences to work
> 
> Hey Justin,
> 
> Thank you very much for your comprehensive answer - I'm using the JAVA
> version of Shindig, but I think you nevertheless pointed me into the
> right direction. I will have look at Partuzza and get back to you (the
> mailing-list) as soon as I (don't) get things figured out.
> 
> BTW - how come that there is so little documentation on these things? As
> a absolute newbie to shindig, I was of course looking at the samples
> which you were also referring to in your last post. However, the samples
> concerning the "set_prefs" feature don't seem to work for me "out of the
> box" which I normally would expect from "samples". Don't get me wrong -
> I think the work and effort that you people put into shindig is really
> cool! It's just a real bummer that it's so hard to actually learn how to
> use shindig (which I would love to). Or am I just missing the "well
> known howto #1"?
> 
> -Peter
 		 	   		  

Re: userPrefs is undefined / getting UserPreferences to work

Posted by Peter Rothenpieler <ro...@itm.uni-luebeck.de>.
Hey Justin,

Thank you very much for your comprehensive answer - I'm using the JAVA
version of Shindig, but I think you nevertheless pointed me into the
right direction. I will have look at Partuzza and get back to you (the
mailing-list) as soon as I (don't) get things figured out.

BTW - how come that there is so little documentation on these things? As
a absolute newbie to shindig, I was of course looking at the samples
which you were also referring to in your last post. However, the samples
concerning the "set_prefs" feature don't seem to work for me "out of the
box" which I normally would expect from "samples". Don't get me wrong -
I think the work and effort that you people put into shindig is really
cool! It's just a real bummer that it's so hard to actually learn how to
use shindig (which I would love to). Or am I just missing the "well
known howto #1"?

-Peter