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. Thanks, -Stanton From: Yao Zhang <[email protected]> To: [email protected], 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 by 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. Thanks! Zhang Yao
