You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shindig.apache.org by "John Hjelmstad (JIRA)" <ji...@apache.org> on 2010/01/19 21:04:54 UTC
[jira] Created: (SHINDIG-1267) Implement affirmative signal of
"gadget-ness" for use by gadgets.rpc initialization
Implement affirmative signal of "gadget-ness" for use by gadgets.rpc initialization
-----------------------------------------------------------------------------------
Key: SHINDIG-1267
URL: https://issues.apache.org/jira/browse/SHINDIG-1267
Project: Shindig
Issue Type: Improvement
Components: Javascript
Affects Versions: 1.1-BETA6
Reporter: John Hjelmstad
Assignee: John Hjelmstad
People are increasingly using gadgets.rpc as a cross-domain communication library for arbitrary IFRAMEs. In doing so (and for type=url gadgets), they typically do:
<script src="http://server.com/gadgets/js/rpc.js?c=1"/>
...then initialize communication.
The above inclusion now (properly) pulls in gadgets.config libs, so the check in rpc.js that determines "gadget-ness" for initialization purposes is rendered meaningless:
if (gadgets.config) {
setupContainerGadgetContext(rpctoken);
} else {
// never happens
setupContainerGenericIframe(rpctoken, opt_receiverurl);
}
I propose adding a small JS beacon in the gadget-rendering case, in RenderingGadgetRewriter, that affirms that the context is in fact that a gadget is being processed. In particular, this ensures that gadgets.config.init({"rpc":...}) will be called.
The beacon will be small eg:
<script>window["__isgadget"] = true;</script>
With this injected and gadgets.rpc updated to use the check, initialization should work properly for all cases. At such time as we're comfortable getting rid of IFPC, we can remove all of this and just use setupContainerGenericIframe(...) always.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-1267) Implement affirmative signal of
"gadget-ness" for use by gadgets.rpc initialization
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802761#action_12802761 ]
Paul Lindner commented on SHINDIG-1267:
---------------------------------------
sounds like a fine transitional idea.
> Implement affirmative signal of "gadget-ness" for use by gadgets.rpc initialization
> -----------------------------------------------------------------------------------
>
> Key: SHINDIG-1267
> URL: https://issues.apache.org/jira/browse/SHINDIG-1267
> Project: Shindig
> Issue Type: Improvement
> Components: Javascript
> Affects Versions: 1.1-BETA6
> Reporter: John Hjelmstad
> Assignee: John Hjelmstad
>
> People are increasingly using gadgets.rpc as a cross-domain communication library for arbitrary IFRAMEs. In doing so (and for type=url gadgets), they typically do:
> <script src="http://server.com/gadgets/js/rpc.js?c=1"/>
> ...then initialize communication.
> The above inclusion now (properly) pulls in gadgets.config libs, so the check in rpc.js that determines "gadget-ness" for initialization purposes is rendered meaningless:
> if (gadgets.config) {
> setupContainerGadgetContext(rpctoken);
> } else {
> // never happens
> setupContainerGenericIframe(rpctoken, opt_receiverurl);
> }
> I propose adding a small JS beacon in the gadget-rendering case, in RenderingGadgetRewriter, that affirms that the context is in fact that a gadget is being processed. In particular, this ensures that gadgets.config.init({"rpc":...}) will be called.
> The beacon will be small eg:
> <script>window["__isgadget"] = true;</script>
> With this injected and gadgets.rpc updated to use the check, initialization should work properly for all cases. At such time as we're comfortable getting rid of IFPC, we can remove all of this and just use setupContainerGenericIframe(...) always.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SHINDIG-1267) Implement affirmative signal of
"gadget-ness" for use by gadgets.rpc initialization
Posted by "John Hjelmstad (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Hjelmstad resolved SHINDIG-1267.
-------------------------------------
Resolution: Fixed
Committed CL to fix a pressing issue, after getting comments from Paul and Henry. Happy to tweak the impl if ppl have strong opinions.
> Implement affirmative signal of "gadget-ness" for use by gadgets.rpc initialization
> -----------------------------------------------------------------------------------
>
> Key: SHINDIG-1267
> URL: https://issues.apache.org/jira/browse/SHINDIG-1267
> Project: Shindig
> Issue Type: Improvement
> Components: Javascript
> Affects Versions: 1.1-BETA6
> Reporter: John Hjelmstad
> Assignee: John Hjelmstad
>
> People are increasingly using gadgets.rpc as a cross-domain communication library for arbitrary IFRAMEs. In doing so (and for type=url gadgets), they typically do:
> <script src="http://server.com/gadgets/js/rpc.js?c=1"/>
> ...then initialize communication.
> The above inclusion now (properly) pulls in gadgets.config libs, so the check in rpc.js that determines "gadget-ness" for initialization purposes is rendered meaningless:
> if (gadgets.config) {
> setupContainerGadgetContext(rpctoken);
> } else {
> // never happens
> setupContainerGenericIframe(rpctoken, opt_receiverurl);
> }
> I propose adding a small JS beacon in the gadget-rendering case, in RenderingGadgetRewriter, that affirms that the context is in fact that a gadget is being processed. In particular, this ensures that gadgets.config.init({"rpc":...}) will be called.
> The beacon will be small eg:
> <script>window["__isgadget"] = true;</script>
> With this injected and gadgets.rpc updated to use the check, initialization should work properly for all cases. At such time as we're comfortable getting rid of IFPC, we can remove all of this and just use setupContainerGenericIframe(...) always.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-1267) Implement affirmative signal of
"gadget-ness" for use by gadgets.rpc initialization
Posted by "John Hjelmstad (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803163#action_12803163 ]
John Hjelmstad commented on SHINDIG-1267:
-----------------------------------------
Implemented:
http://codereview.appspot.com/186253/show
> Implement affirmative signal of "gadget-ness" for use by gadgets.rpc initialization
> -----------------------------------------------------------------------------------
>
> Key: SHINDIG-1267
> URL: https://issues.apache.org/jira/browse/SHINDIG-1267
> Project: Shindig
> Issue Type: Improvement
> Components: Javascript
> Affects Versions: 1.1-BETA6
> Reporter: John Hjelmstad
> Assignee: John Hjelmstad
>
> People are increasingly using gadgets.rpc as a cross-domain communication library for arbitrary IFRAMEs. In doing so (and for type=url gadgets), they typically do:
> <script src="http://server.com/gadgets/js/rpc.js?c=1"/>
> ...then initialize communication.
> The above inclusion now (properly) pulls in gadgets.config libs, so the check in rpc.js that determines "gadget-ness" for initialization purposes is rendered meaningless:
> if (gadgets.config) {
> setupContainerGadgetContext(rpctoken);
> } else {
> // never happens
> setupContainerGenericIframe(rpctoken, opt_receiverurl);
> }
> I propose adding a small JS beacon in the gadget-rendering case, in RenderingGadgetRewriter, that affirms that the context is in fact that a gadget is being processed. In particular, this ensures that gadgets.config.init({"rpc":...}) will be called.
> The beacon will be small eg:
> <script>window["__isgadget"] = true;</script>
> With this injected and gadgets.rpc updated to use the check, initialization should work properly for all cases. At such time as we're comfortable getting rid of IFPC, we can remove all of this and just use setupContainerGenericIframe(...) always.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.