I've been spending some time making it easier to implement gadgets in a
container and it seems like I'm going down the path of rewriting
gadgets.js.
I'd like to hear what others have done with/to this to implement their
containers and hopefully make something that works much better.
Here's what I've done so far:
* Prototyping with jquery
* Using custom tags
* Using metadata servlet.
Here's an example of where I'm headed:
<!-- load up the container JS, include the container=default here...-->
<head>
<script type="text/javascript"
src="../../js/rpc:shindig.connect:core.js?container=default&c=1"></script>
<os:config view="home" lang="en" country="US"/>
</head>
<body onLoad="shindig.container.render()">
Hello <os:viewer attr="displayName"/> on page owned by <os:owner
attr="displayName"/>
<os:gadget moduleId="2" url="
http://www.google.com/ig/modules/horoscope.xml";></os:gadget>
<body>
The JsServlet (used in the script tag above) injects ContainerConfig and is
modified to emit container specific information including the relayUrl,
skins info, etc. This is optionally overridden in the os:config tag along
with per-request info like locale and view.
shindig.container.render() gathers the <os:gadget...> entries from the DOM,
assigns unique IDs and constructs a suitable metadata call using JSONP.
The metadata servlet is modified to return security tokens as part of the
response, and will return basic viewer/owner information too -- it can do
this since it runs on a domain where an existing user has cookie values.
The handler for the metadata response then adds the iframes to the DOM,
calls gadgets.rpc.setupReceiver() and substitutes values for os:viewer and
os:owner, and the page is displayed!
Thoughts on this as a technique? Anyone interesting in working with me on
this?
One very intriguing possibility is running the metadata servlet on a central
host and allowing anyone to syndicate the entire system by creating a
container for each partner that wants access to the users on that central
host.
