Activity

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:https://reviews.apache.org/r/3908/
-----------------------------------------------------------

jiraposter@reviews.apache.org
added a comment - 15/Feb/12 04:09
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3908/
-----------------------------------------------------------
Review request for shindig, Henry Saputra, Dan Dumont, and Stanton Sievers.
Summary
-------
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 addresses bug SHINDIG-1704 .
https://issues.apache.org/jira/browse/SHINDIG-1704
Diffs
http://svn.apache.org/repos/asf/shindig/trunk/extras/src/main/javascript/features-extras/org.openajax.hub-2.0.5/iframe.js 1238149
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/rpc/rpc.js 1238149
Diff: https://reviews.apache.org/r/3908/diff
Testing
-------
Thanks,
Yao

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:https://reviews.apache.org/r/3908/
-----------------------------------------------------------

jiraposter@reviews.apache.org
added a comment - 15/Feb/12 14:44
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3908/#review5123
-----------------------------------------------------------
Could you please provide a bit more information on the use case that you are trying and what's going on? I want to make sure I understand this before I review.
Also, there's a bunch of whitespace that needs to be cleaned up. Please remove all trailing line whitespace =~/[ \t]+$//; (if you'll forgive my perl)
Also, please use tab = 2 spaces + convert tabs to spaces.
Dan
On 2012-02-15 04:09:39, Yao Zhang wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3908/
-----------------------------------------------------------
(Updated 2012-02-15 04:09:39)
Review request for shindig, Henry Saputra, li xu, Dan Dumont, and Stanton Sievers.
Summary
-------
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 addresses bug SHINDIG-1704 .
https://issues.apache.org/jira/browse/SHINDIG-1704
Diffs
-----
http://svn.apache.org/repos/asf/shindig/trunk/extras/src/main/javascript/features-extras/org.openajax.hub-2.0.5/iframe.js 1238149
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/rpc/rpc.js 1238149
Diff: https://reviews.apache.org/r/3908/diff
Testing
-------
Thanks,
Yao

Hi Dan, the story is:
When you try to render a gadget to a certain dom node like this:
var cc = new osapi.container.Container({});
var site = cc.newGadgetSite(siteEle/an existing dom node/);
cc.navigateGadget(site,....);

Gadget rendering will fail if siteEle is a dom node is in side an iframe in top paranet window. The cause is rpc code is assuming the input dom node is just in the top parent window.

jiraposter@reviews.apache.org
added a comment - 27/Feb/12 08:57
On 2012-02-15 14:43:55, Dan Dumont wrote:
> Could you please provide a bit more information on the use case that you are trying and what's going on? I want to make sure I understand this before I review.
>
> Also, there's a bunch of whitespace that needs to be cleaned up. Please remove all trailing line whitespace =~/[ \t]+$//; (if you'll forgive my perl)
> Also, please use tab = 2 spaces + convert tabs to spaces.
Hi Dan, the story is:
When you try to render a gadget to a certain dom node like this:
var cc = new osapi.container.Container({});
var site = cc.newGadgetSite(siteEle/ an existing dom node /);
cc.navigateGadget(site,....);
Gadget rendering will fail if siteEle is a dom node is in side an iframe in top paranet window. The cause is rpc code is assuming the input dom node is just in the top parent window.
Yao
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3908/#review5123
-----------------------------------------------------------
On 2012-02-15 04:09:39, Yao Zhang wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3908/
-----------------------------------------------------------
(Updated 2012-02-15 04:09:39)
Review request for shindig, Henry Saputra, li xu, Dan Dumont, and Stanton Sievers.
Summary
-------
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 addresses bug SHINDIG-1704 .
https://issues.apache.org/jira/browse/SHINDIG-1704
Diffs
-----
http://svn.apache.org/repos/asf/shindig/trunk/extras/src/main/javascript/features-extras/org.openajax.hub-2.0.5/iframe.js 1238149
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/rpc/rpc.js 1238149
Diff: https://reviews.apache.org/r/3908/diff
Testing
-------
Thanks,
Yao

I just want to make sure I understand the purpose of the patch:
1. Trying to render gadget with common container which has gadget site inside the window of another iframe already in the same window.
2. Now, the rpc code in the container should check for the embeddedlevel hash value of the current container window to get the right window where the DOM element for the site live?

I dont think this is the scenario intended for the rpc and common container.

Henry Saputra
added a comment - 27/Feb/12 18:26 I just want to make sure I understand the purpose of the patch:
1. Trying to render gadget with common container which has gadget site inside the window of another iframe already in the same window.
2. Now, the rpc code in the container should check for the embeddedlevel hash value of the current container window to get the right window where the DOM element for the site live?
I dont think this is the scenario intended for the rpc and common container.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:https://reviews.apache.org/r/3908/
-----------------------------------------------------------

jiraposter@reviews.apache.org
added a comment - 01/Mar/12 06:32
On 2012-02-15 14:43:55, Dan Dumont wrote:
> Could you please provide a bit more information on the use case that you are trying and what's going on? I want to make sure I understand this before I review.
>
> Also, there's a bunch of whitespace that needs to be cleaned up. Please remove all trailing line whitespace =~/[ \t]+$//; (if you'll forgive my perl)
> Also, please use tab = 2 spaces + convert tabs to spaces.
Yao Zhang wrote:
Hi Dan, the story is:
When you try to render a gadget to a certain dom node like this:
var cc = new osapi.container.Container({});
var site = cc.newGadgetSite(siteEle/ an existing dom node /);
cc.navigateGadget(site,....);
Gadget rendering will fail if siteEle is a dom node is in side an iframe in top paranet window. The cause is rpc code is assuming the input dom node is just in the top parent window.
Hi Dan, I've updated the new patch that clean the spaces.
Yao
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3908/#review5123
-----------------------------------------------------------
On 2012-03-01 06:29:05, Yao Zhang wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3908/
-----------------------------------------------------------
(Updated 2012-03-01 06:29:05)
Review request for shindig, Henry Saputra, li xu, Dan Dumont, and Stanton Sievers.
Summary
-------
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 addresses bug SHINDIG-1704 .
https://issues.apache.org/jira/browse/SHINDIG-1704
Diffs
-----
http://svn.apache.org/repos/asf/shindig/trunk/extras/src/main/javascript/features-extras/org.openajax.hub-2.0.5/iframe.js 1238149
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/rpc/rpc.js 1291547
Diff: https://reviews.apache.org/r/3908/diff
Testing
-------
Thanks,
Yao

jiraposter@reviews.apache.org
added a comment - 01/Mar/12 19:05
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3908/#review5510
-----------------------------------------------------------
I think the scenario is not what the rpc mechanism intend to do. The communication between container and gadgets happen between one parent window and a child window via iframe.
Henry
On 2012-03-01 06:29:05, Yao Zhang wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3908/
-----------------------------------------------------------
(Updated 2012-03-01 06:29:05)
Review request for shindig, Henry Saputra, li xu, Dan Dumont, and Stanton Sievers.
Summary
-------
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 addresses bug SHINDIG-1704 .
https://issues.apache.org/jira/browse/SHINDIG-1704
Diffs
-----
http://svn.apache.org/repos/asf/shindig/trunk/extras/src/main/javascript/features-extras/org.openajax.hub-2.0.5/iframe.js 1238149
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/rpc/rpc.js 1291547
Diff: https://reviews.apache.org/r/3908/diff
Testing
-------
Thanks,
Yao

jiraposter@reviews.apache.org
added a comment - 02/Mar/12 02:24
On 2012-03-01 19:04:07, Henry Saputra wrote:
> I think the scenario is not what the rpc mechanism intend to do. The communication between container and gadgets happen between one parent window and a child window via iframe.
Hi Henry,
There is the scenario that people want to render their gadget inside an existing iframe(like inside a editor). And rcp prevent them do so... Do you think this is a reasonable scenario?
Yao
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3908/#review5510
-----------------------------------------------------------
On 2012-03-01 06:29:05, Yao Zhang wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3908/
-----------------------------------------------------------
(Updated 2012-03-01 06:29:05)
Review request for shindig, Henry Saputra, li xu, Dan Dumont, and Stanton Sievers.
Summary
-------
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 addresses bug SHINDIG-1704 .
https://issues.apache.org/jira/browse/SHINDIG-1704
Diffs
-----
http://svn.apache.org/repos/asf/shindig/trunk/extras/src/main/javascript/features-extras/org.openajax.hub-2.0.5/iframe.js 1238149
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/rpc/rpc.js 1291547
Diff: https://reviews.apache.org/r/3908/diff
Testing
-------
Thanks,
Yao

We have a number of applications that leverage tools such as the CKeditor
to enable embedding user authored content. Allowing this content to refer
to a gadget is a valuable use case, but introduces a problem when the user
goes into edit mode as the editor component injects its own iframe into the
page. This patch allows such a gadget placement to work even while in the
rich text editing mode.

I just want to make sure I understand the purpose of the patch:
1. Trying to render gadget with common container which has gadget site
inside the window of another iframe already in the same window.
2. Now, the rpc code in the container should check for the embeddedlevel
hash value of the current container window to get the right window where
the DOM element for the site live?

I dont think this is the scenario intended for the rpc and common
container.

Rich Thompson
added a comment - 02/Mar/12 23:47
We have a number of applications that leverage tools such as the CKeditor
to enable embedding user authored content. Allowing this content to refer
to a gadget is a valuable use case, but introduces a problem when the user
goes into edit mode as the editor component injects its own iframe into the
page. This patch allows such a gadget placement to work even while in the
rich text editing mode.
Rich Thompson
From: "Henry Saputra (Commented) (JIRA)" <jira@apache.org>
To: issues@shindig.apache.org,
Date: 02/27/2012 01:30 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=13217353#comment-13217353
]
Henry Saputra commented on SHINDIG-1704 :
----------------------------------------
I just want to make sure I understand the purpose of the patch:
1. Trying to render gadget with common container which has gadget site
inside the window of another iframe already in the same window.
2. Now, the rpc code in the container should check for the embeddedlevel
hash value of the current container window to get the right window where
the DOM element for the site live?
I dont think this is the scenario intended for the rpc and common
container.
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

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
added a comment - 05/Mar/12 01:38
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: richt2@us.ibm.com
From: "Henry Saputra (Commented) (JIRA)" <jira@apache.org>
To: issues@shindig.apache.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
[
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?
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

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.

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?

Ilya Shtein
added a comment - 05/Mar/12 04:44 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: ilya.shtein@fisglobal.com< ilya.shtein@fisglobal.com >
From: Rich Thompson richt2@us.ibm.com
Sent: Sunday, March 04, 2012 7:37 PM
To: dev@shindig.apache.org
Cc: issues@shindig.apache.org
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: richt2@us.ibm.com< richt2@us.ibm.com >
[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)" <jira@apache.org< jira@apache.org >>
To: issues@shindig.apache.org< issues@shindig.apache.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

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:https://reviews.apache.org/r/3908/
-----------------------------------------------------------