Douglas, I made a new post here so I wouldn't hijack your thread but I
hope that some of my questions may help you or the other way around. :)
I've noticed that the reference container has no implementation of
persisting user preferences. I am under the impression that it is the
container's job to manage and persist user preferences.
There was a recent spec change proposal to deprecate the existing
replacement method of user prefs in favor of EL syntax replacement (a
server side procedure).
Correct me if I'm wrong, but wouldn't this require that the container post
all preference information it contains to the shindig server so that the
gadget could be rendered correctly? That could be quite a performance
drain on gadgets with a large preference store.
My first stab at adding (at the very least: default) preferences support
to the reference container impl:
Index: gadget_site.js
===================================================================
--- gadget_site.js (revision 1137018)
+++ gadget_site.js (working copy)
@@ -286,7 +286,16 @@
viewInfo[osapi.container.MetadataResponse.PREFERRED_WIDTH] ||
gadgetInfo[osapi.container.MetadataResponse.MODULE_PREFS][osapi.container.MetadataResponse.WIDTH]
||
String(osapi.container.GadgetSite.DEFAULT_WIDTH_);
-
+
+ localRenderParams[osapi.container.RenderParam.USER_PREFS] = {};
+ for (var name in gadgetInfo[osapi.container.RenderParam.USER_PREFS]) {
+ var pref = gadgetInfo[osapi.container.RenderParam.USER_PREFS][name];
+ if (pref.defaultValue) {
+ localRenderParams[osapi.container.RenderParam.USER_PREFS] =
pref.defaultValue;
+ }
+ }
+ // TODO: process container persisted user prefs here?
+
this.updateSecurityToken_(gadgetInfo, localRenderParams);
this.loadingGadgetHolder_.render(gadgetInfo, viewParams,
localRenderParams);
I'd appreciate some feedback. I've noticed some unreliable behavior of
default permissions being injected into the URL for the ifr request by the
metadata request. With templating turned on I seem to get a %up_key%
syntax in the url. It seems that pure client side replacement would be
less prone to failure with whatever configuration error I may currently be
running into and the server component could be removed. It also raises
the question about why the el syntax spec change is really needed here. If
anyone can point me to documentation about how preference data is expected
to be communicated from the container to the server, I'd appreciate it.
