shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stanton Sievers" <>
Subject Re: Question of supporting creating a gadget inside an existing iframe on base document.
Date Thu, 12 Jan 2012 12:42:08 GMT
There are several concerns like this with the current RPC code and I've 
been wanting to overhaul it for some time now.  I had spoken to John 
Hjelmstad about a use case similar to this before as well as other ways to 
improve some assumptions the RPC code makes about where the gadget is 
running in relation to the container.

I've cc'd John on my response in hopes he may be able to provide some more 
information about any ongoing work in this area.


From:   Yao Zhang <>
Date:   01/12/2012 01:21
Subject:        Question of supporting creating a gadget inside an 
existing iframe on base document.

Hi all,

I met a problem when I tried to create a new gadget site by newGadgetSite
with the parameter gadgetEl set to a DOM node inside an existing iframe on
base document. The gadget can not be rendered.

I did some debugging and found that feature org.openajax.hub-2.0.5 and rpc
can not handle this case. Basically a random DOM id is created for the DOM
node and document.getElementById is used later to get this DOM node.
However, if this node is inside an iframe, you can only get the DOM node 
using its owner document's getElementById.

I tried to change the code in org.openajax.hub-2.0.5 and rpc to use
ownerDocument and it works well.

The question is that I do not have other good idea but change the rpc's
public interface rpc.setupReceiver to accept a new DOM node parameter
instead of current DOM id parameter. But this might break current code
calling rpc.setReceiver.

This new DOM node parameter can be added to the end of rpc.setupReceiver
parameter list which will not break current usage. But if someone need to
create gadget inside iframe, this new DOM node parameter is required.

Is this kind of change acceptable? Any suggestion and direction on how to
handle this better are appreciated.


Zhang Yao

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message