You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shindig.apache.org by "Jon Weygandt (JIRA)" <ji...@apache.org> on 2010/01/08 21:17:55 UTC
[jira] Created: (SHINDIG-1258) Shindig fails to support the "libs"
parameter for URL Gadgets
Shindig fails to support the "libs" parameter for URL Gadgets
-------------------------------------------------------------
Key: SHINDIG-1258
URL: https://issues.apache.org/jira/browse/SHINDIG-1258
Project: Shindig
Issue Type: Bug
Components: Java
Affects Versions: 1.1-BETA5
Reporter: Jon Weygandt
The render of a URL gadget requires "libs", Gadget Specification, Section 3.1.3.6(c): http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html#process
The attached change will generate a libs parameter, suitable for adding to the "JS path", which for Shindig is: http://xxx/gadgets/js/. However the Gadget Specification is silent on what that is, and how it is communicated to the gadget developer. I remember for iGoogle, they simply documented the string. Additionally there are security and trust issues with gadget developers including foreign JavaScript. This patch will not attempt to address these issues.
Additionally there is a new parameter "unsup" to report unsupported features to the remote site, reference Gadget Spec 3.1.3.5(a).
Overview of the changes:
*) RenderingContext - added a new enum URLGADGET
**) c=2 ==> URLGADGET for URLs
**) Made several changes to propagate that throughout the code base
*) For the feature.xml files added <urlgadget>
**) Updated the feature.xml for features that should work, in general my thoughts are anything a URL author cannot do another way should be supported (e.g. rpc and related functions like dynamic height, info on views). Things like user prefs, message bundles, etc... all have "another way" and are not supported. Also most of the opensocial calls have "another way" (e.g. REST/RPC).
*) JS Servlet now responds to c=2
**) Not only does it return the JS itself, but it will also return the container configuration, which is normally part of the gadget rewriter (which is not called for a URL gadget).
*) The URL Generator will return with the remote URL with the metadata, which eliminates the return trip to the server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-1258) Shindig fails to support the "libs"
parameter for URL Gadgets
Posted by "Jon Weygandt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Weygandt updated SHINDIG-1258:
----------------------------------
Attachment: 100106-UrlGadget.patch
Code review: http://codereview.appspot.com/184041/show
> Shindig fails to support the "libs" parameter for URL Gadgets
> -------------------------------------------------------------
>
> Key: SHINDIG-1258
> URL: https://issues.apache.org/jira/browse/SHINDIG-1258
> Project: Shindig
> Issue Type: Bug
> Components: Java
> Affects Versions: 1.1-BETA5
> Reporter: Jon Weygandt
> Attachments: 100106-UrlGadget.patch
>
>
> The render of a URL gadget requires "libs", Gadget Specification, Section 3.1.3.6(c): http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html#process
> The attached change will generate a libs parameter, suitable for adding to the "JS path", which for Shindig is: http://xxx/gadgets/js/. However the Gadget Specification is silent on what that is, and how it is communicated to the gadget developer. I remember for iGoogle, they simply documented the string. Additionally there are security and trust issues with gadget developers including foreign JavaScript. This patch will not attempt to address these issues.
> Additionally there is a new parameter "unsup" to report unsupported features to the remote site, reference Gadget Spec 3.1.3.5(a).
> Overview of the changes:
> *) RenderingContext - added a new enum URLGADGET
> **) c=2 ==> URLGADGET for URLs
> **) Made several changes to propagate that throughout the code base
> *) For the feature.xml files added <urlgadget>
> **) Updated the feature.xml for features that should work, in general my thoughts are anything a URL author cannot do another way should be supported (e.g. rpc and related functions like dynamic height, info on views). Things like user prefs, message bundles, etc... all have "another way" and are not supported. Also most of the opensocial calls have "another way" (e.g. REST/RPC).
> *) JS Servlet now responds to c=2
> **) Not only does it return the JS itself, but it will also return the container configuration, which is normally part of the gadget rewriter (which is not called for a URL gadget).
> *) The URL Generator will return with the remote URL with the metadata, which eliminates the return trip to the server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.