[
https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167539#comment-13167539
]
[email protected] commented on SHINDIG-1669:
--------------------------------------------------------
bq. On 2011-12-09 14:25:51, Jesse Ciancetta wrote:
bq. > LGTM
bq. >
bq. > This is an interesting capability -- its too bad we couldn't find a way
to get it done without two requests though.
bq. >
bq. > I did actually have one other thought about an alternative that could
work (but again has its own share of drawbacks -- many of which are the same as
the head approach) but thought I'd share anyway in case it spurs some thoughts
from others too. I was thinking there might be a way to add another proxy to
shindig for cases like this -- maybe something like IframeProxyServlet -- so
the iframe src would point to
shindig-server/iframeProxy?url=http://example.com/theIframeContent.html -- and
then on the shindig side it could fetch the content, add a script include for
the shindig RPC library and then a script block that would fire a message to
the parent container as soon as it's processed. On the parent page you could
listen for the RPC call and when fired you'd know the iframe loaded. You could
probably even do the same thing for the failure case on the shindig side -- you
return a page with a friendly error message saying that the content failed to
load and fire the RPC to the parent page with a message letting it know that
the iframe failed -- and you could even include any details you needed to as to
exactly what failed.
bq. >
bq. > Again -- just throwing out some thoughts here -- there would be plenty
of issues with this approach too (besides being much more work) like the iframe
domain would be that of shindig instead of the real host, relative links in
documents probably wouldn't work unless they were rewritten (which I guess
shindig already knows how to do) etc -- but thought it was still worth sharing
in case anyone else was interested.
Thanks Jesse. This is def something to consider for a future enhancement.
- Ryan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3779
-----------------------------------------------------------
On 2011-12-08 17:58:33, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-08 17:58:33)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the
caller has no way of knowing if the URL was navigated successfully or not. To
solve this we make a head request to the URL we are navigating to and add a
callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the
head request. While this could possibly give us better performance we have no
way of guaranteeing the server will still be up next time and everything may
fail. This is different from the gadget case where we have the gadget XML
cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq.
http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml
1211913
bq.
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js
1211913
bq.
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js
1211913
bq.
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js
1211913
bq.
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js
1211913
bq.
http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js
1211913
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or
> failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the
> caller has no way of knowing if the URL was navigated successfully or not.
> To solve this we make a head request to the URL we are navigating to and add
> a callback to the API.
> It is important to note that we will not be caching the response of the head
> request. While this could possibly give us better performance we have no way
> of guaranteeing the server will still be up next time and everything may
> fail. This is different from the gadget case where we have the gadget XML
> cached on the server.
--
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
