Filtering is useful for the "one request per render case" (the common one).
Returning all view urls is useful for the more dynamic consumer.
The easiest option is probably to just add iframeUrl to the views map that
is returned. This cleanly normalizes type=url and type=html views.
On Mon, Jun 30, 2008 at 6:55 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote:
> 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\<http://gadgets.exitthree.com/4zs9/rps.xml%5C>"
> } ], context: { container: "ig",
> ignoreCache: true, view: "canvas" } }"
> http://sandbox.gmodules.com/gadgets/metadata
> {"gadgets":[{"userPrefs":{},"moduleId":0,"screenshot":"","authorEmail":"
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> <[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
>
