We had a similar problem, and found that there are two ways to solve it (depending on the situation):
1) Do what Henry Saputra is suggesting below, and
2) Write a small "wrapper gadget", whose only responsibility is to populate the inner iframe and expose an API to be used by the content hosted in the inner iframe.
The first solution seemed a little heavyweight for us, so we mostly use the second one. Here is how it works:
- The wrapper gadget is a standard gadget XML file, with ModulePrefs which includes all feature definitions, plus title and height, if necessary. It also contains some helper methods and configuration variables (e.g., script location, OAuth endpoint). It also contains some minimal HTML, which contains the "inner iframe".
- This wrapper gadget, when loaded, will load the script and the inner iframe contents. The script essentially is a "poor man" wrapper around Gadget API (in essence, you only need to expose a handful of methods. Signatures of all wrapper methods are the same as those of the originals. This establishes an internal convention, which is used by some of our stateful enterprise applications.
I have to admit that this solution is rather crude, but it allows us to easily integrate with existing applications. Every application lives in a special "bubble" (think bubble wrap ), but for the container and the rest of the gadgets every bubble looks like a standard gadget. Every gadget can access the wrapper API without including any files; the gadget can have a separate session with its application, without conflicting with the renderer's session.
The biggest drawback of this solution is that the wrapper and the "inner gadget" must pretend they are in the same domain, which is relatively easy to accomplish in an enterprise environment, where applications' URLs normally have the same root domain, i.e., xxx.zzz.com, yyy.zzz.com, etc. (the .zzz.com part is common for all apps), by setting document.domain to "zzz.com". But doing so simplifies the API and allows to create an infrastructure that is much lighter than would be required to build and embed another OS container.
There are certainly more intelligent ways of creating a wrapper, but this one works, and there doesn't seem to be a strong drive to re-do it.
FIS Enterprise Architecture
From: Rich Thompson firstname.lastname@example.org
Sent: Sunday, March 04, 2012 7:37 PM
Subject: Re: [jira] [Commented] (SHINDIG-1704) rpc does not support communicating with gadget created in an existing iframe
Problem is that it is an outside tool that is consumed as a component. From what I understand, we do not have a way of impacting the loading of the iframe and making it a completely separate container would result in significant bloat in the client and not provide normal operation for things such as eventing.
Is there some significant problem with having the core provide support for placing a gadget within an (uncontrolled,) embedded iframe?
IBM T.J. Watson Research Center / Hawthorne, NY
Phone: (914) 784-6203 / (203) 445-0384 email: email@example.com<firstname.lastname@example.org>
[Inactive hide details for "Henry Saputra (Commented) (JIRA)" --
03/03/2012 09:46:28 PM-- [ https://issues.apache.org/jira/b]"Henry Saputra (Commented) (JIRA)" -- 03/03/2012 09:46:28 PM-- [ https://issues.apache.org/jira/browse/SHINDIG-1704?page=com.atlassian.jira.plugin.system.issue
From: "Henry Saputra (Commented) (JIRA)" <email@example.com<firstname.lastname@example.org>>
Date: 03/03/2012 09:46 PM
Subject: [jira] [Commented] (SHINDIG-1704) rpc does not support communicating with gadget created in an existing iframe