Widget: setting title and height

[Martin Webb <ma...@gmail.com>]

There are (at least) three use cases for setting widget attributes:

* programmatically from within the widget by invoking the appropriate API -
supported already within Shindig - requires a widget developer to utilise
* programmatically from within the container framework - supported by the
APIs already within Shindig - requires a container developer to utilise
* data driven from the width and title settings within the gadget XML whilst
the gadget is being rendered within the container - not implemented.

This last requires shindig to examine the (optional?) title and height
settings and to use them when rendering the widget, e.g.:

<ModulePrefs title="Zombies!" height="350" />

It would appear that the client-side Javascript has no direct access to the
contents of the gadget XML?  That the gadget XML is parsed by the
server-side implementation (the proxy?).  It would appear that the
server-side implementation needs to provide the details of the ModulePres to
the client-side implementation (possibly to the gadget.js)?

I'd like to have a stab at solving this, but I'm not sure how this is
supposed to be done.  Is the proxy supposed to inject JavaScript code into
the response to set the title, height?  Is the proxy supposed to pass
details of the ModulePrefs to the widget container, so that the container
can (optionally) set the details?  It can't be the responsibility of the
gadget developer to do this - else all the existing gadgets in existence
would requires changes.

Regards
Martin

Re: Widget: setting title and height

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

A better container approach would probably be a straight XHR to some sort of
RPC service that provides meta data (and avoid any iframe communication
entirely). This is a valid approach, certainly, but I'm not quite convinced
that it's worth doing it this way vs. using the shindig core libraries
directly to get at that data at render time. I assume that very few sites
actually have static html as their parent pages. It would not be a very
efficient way to do this.

~Kevin

On Jan 18, 2008 7:03 AM, Martin Webb <ma...@gmail.com> wrote:

> On 16/01/2008, Kevin Brown <et...@google.com> wrote:
> >
> > ModulePrefs are already exposed in the Gadget / GadgetSpec object. We
> > expect
> > that most containers will use this library directly to get access to
> this
> > meta data. Doing all of this in javascript is extraordinarily
> cumbersome,
> > and in the long run probably isn't necessary. We could certainly
> implement
> > this in pure JS, but I don't think that will be practical for real
> > implementations due to the cost of iframe->container communication.
>
>
> I was think more along the lines of doing a container->iframe to go get
> the
> GadgetSpec.  Is this just as expensive?
>
> Martin
>

Re: Widget: setting title and height

[Martin Webb <ma...@gmail.com>]

On 16/01/2008, Kevin Brown <et...@google.com> wrote:
>
> ModulePrefs are already exposed in the Gadget / GadgetSpec object. We
> expect
> that most containers will use this library directly to get access to this
> meta data. Doing all of this in javascript is extraordinarily cumbersome,
> and in the long run probably isn't necessary. We could certainly implement
> this in pure JS, but I don't think that will be practical for real
> implementations due to the cost of iframe->container communication.


I was think more along the lines of doing a container->iframe to go get the
GadgetSpec.  Is this just as expensive?

Martin

Re: Widget: setting title and height

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

ModulePrefs are already exposed in the Gadget / GadgetSpec object. We expect
that most containers will use this library directly to get access to this
meta data. Doing all of this in javascript is extraordinarily cumbersome,
and in the long run probably isn't necessary. We could certainly implement
this in pure JS, but I don't think that will be practical for real
implementations due to the cost of iframe->container communication.

On Jan 16, 2008 5:30 AM, Martin Webb <ma...@gmail.com> wrote:

> On 15/01/2008, Kevin Brown <et...@google.com> wrote:
> >
> >
> > We could put a hack in for the reference container that forces use of
> set
> > height, but that's not very clean either.
>
>
> Can we not put a hack in to return all the ModulePrefs as an object, so
> that
> the container can opt to make use of it?  If so where would that hack go?
>
> Martin
>

Re: Widget: setting title and height

[Martin Webb <ma...@gmail.com>]

On 15/01/2008, Kevin Brown <et...@google.com> wrote:
>
>
> We could put a hack in for the reference container that forces use of set
> height, but that's not very clean either.


Can we not put a hack in to return all the ModulePrefs as an object, so that
the container can opt to make use of it?  If so where would that hack go?

Martin

Re: Widget: setting title and height

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

On Jan 15, 2008 7:24 AM, Martin Webb <ma...@gmail.com> wrote:

> There are (at least) three use cases for setting widget attributes:
>
> * programmatically from within the widget by invoking the appropriate API
> -
> supported already within Shindig - requires a widget developer to utilise
> * programmatically from within the container framework - supported by the
> APIs already within Shindig - requires a container developer to utilise
> * data driven from the width and title settings within the gadget XML
> whilst
> the gadget is being rendered within the container - not implemented.
>
> This last requires shindig to examine the (optional?) title and height
> settings and to use them when rendering the widget, e.g.:
>
> <ModulePrefs title="Zombies!" height="350" />


This is correct, although in practice containers are free to use or ignore
these attributes depending on their needs.

It would appear that the client-side Javascript has no direct access to the
> contents of the gadget XML?  That the gadget XML is parsed by the
> server-side implementation (the proxy?).  It would appear that the
> server-side implementation needs to provide the details of the ModulePres
> to
> the client-side implementation (possibly to the gadget.js)?


In pure js, the only way to do this is to trigger set height. In practice,
we expect that "real" containers will be using the shindig core (i.e.
everything not in the http directory) to fetch meta data, similar to what
you see on igoogle or orkut today.

We could put a hack in for the reference container that forces use of set
height, but that's not very clean either.

The best option in my mind would be to implement a reference container
servlet that uses the other libraries to render a container. This would give
support for height / width as well as the gadget's title and other meta
data. Since this is much more complicated html than the other pieces, it
would be necessary to pull a templating engine into the project such as
ClearSilver (not sure if the license is compatible or how hard integration
would be, though).

~Kevin