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
