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. Thanks, Ilya Shtein FIS Enterprise Architecture Phone: 414-815-(5)2335 e-mail: [email protected]<mailto:[email protected]> From: Rich Thompson [mailto:[email protected]] Sent: Sunday, March 04, 2012 7:37 PM To: [email protected] Cc: [email protected] 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? Rich Thompson IBM T.J. Watson Research Center / Hawthorne, NY Phone: (914) 784-6203 / (203) 445-0384 email: [email protected]<mailto:[email protected]> [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 protected]<mailto:[email protected]>> To: [email protected]<mailto:[email protected]>, Date: 03/03/2012 09:46 PM Subject: [jira] [Commented] (SHINDIG-1704) rpc does not support communicating with gadget created in an existing iframe ________________________________ [ https://issues.apache.org/jira/browse/SHINDIG-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221768#comment-13221768 ] Henry Saputra commented on SHINDIG-1704: ---------------------------------------- Can the CKeditor iframe include Shindg common container script to become small OS container? this will allow the CKEditor to host the gadget? > rpc does not support communicating with gadget created in an existing iframe > ---------------------------------------------------------------------------- > > Key: SHINDIG-1704 > URL: https://issues.apache.org/jira/browse/SHINDIG-1704 > Project: Shindig > Issue Type: Bug > Components: Javascript > Affects Versions: 2.0.2 > Reporter: Yao Zhang > > When you try to render a gadget to a dom node inside an existing iframe, rpc > does not work as the code is using document.getElementById to get the domnode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
