Hello,
I'd like to better utilize/clean up use of the "view" parameter passed to
/gadgets/metadata.
Today, "view" doesn't do much when supplied to /gadgets/metadata (RpcServlet
in Java). eg:
$ curl --data "{ gadgets: [ { url: \"
http://gadgets.exitthree.com/4zs9/rps.xml\"; } ], context: { container: "ig",
ignoreCache: true, view: "canvas" } }"
http://sandbox.gmodules.com/gadgets/metadata
{"gadgets":[{"userPrefs":{},"moduleId":0,"screenshot":"","authorEmail":"
[EMAIL PROTECTED] <[EMAIL PROTECTED]>
","singleton":false,"width":0,"links":{},"iframeUrl":".
ig.sandbox.gmodules.com/gadgets/ifr?container=ig&nocache=1&lang=&country=&url=http%3A%2F%2Fgadgets.exitthree.com%2F4zs9%2Frps.xml
","url":"http://gadgets.exitthree.com/4zs9/rps.xml","scaling":false,"author":"Dan
Holevoet","authorAffiliation":"Google Inc.","title":"Rock Paper
Scissors","height":0,"titleUrl":"","thumbnail":"","scrolling":false,"authorLocation":"Mountain
View,
CA","views":{"default":{"preferredHeight":0,"quirks":true,"type":"html","preferredWidth":0},"canvas":{"preferredHeight":0,"quirks":true,"type":"html","preferredWidth":0}},"features":["views","dynamic-height","opensocial-0.7","analytics"],"showStats":false,"categories":["",""],"showInDirectory":false}]}
It's not integrated into the iframeUrl output string, and all views are
returned as an object.
This leads to the following proposals:
1. Minimally, include &view=<view> in iframeUrl.
2.A. Filter "views" to only include the matching view.
2.B. Alternately, incorporate matching view's view-specific metadata into
the response, removing "views" altogether.
Conceptually I feel 1+2B is cleanest, but is also most disruptive as it adds
new data to the response object. #1 could be done independently of either of
options in #2.
In either case, unsupported view could be returned if an unsupported view is
specified, though that leads to one question:
This "view" parameter attaches to the entire request at present. Should that
continue to be so, or should "view" be a supported attribute of a JSONObject
representation of a gadget? As far as I've seen it used thus far, the API is
used for rendering gadgets all with a given view, so it should probably stay
in the context arguments. Still, what happens when one gadget has view "foo"
and another doesn't? Is "unsupported view" returned, or do we add some dummy
value indicating "invalid gadget"?
In the nominal case, I'd like to add &view=foo to iframeUrl even if it's
invalid for the gadget, as a minor way of standardizing the URL param name -
just as PHP's impl does.
Thoughts welcome. Would the added filtering be of any value?
--John
