"view" parameter in /gadgets/metadata context

[John Hjelmstad <fa...@google.com>]

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":"
dwh+rps@google.com <dw...@google.com>
","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

Re: "view" parameter in /gadgets/metadata context

[Kevin Brown <et...@google.com>]

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 <fa...@google.com> 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":"
> dwh+rps@google.com <dw...@google.com> <dw...@google.com>
> >
> ","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
>