[
https://issues.apache.org/jira/browse/SHINDIG-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222164#comment-13222164
]
Ilya Shtein commented on SHINDIG-1704:
--------------------------------------
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
> 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
