----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/3037/#review3779 -----------------------------------------------------------
Ship it! LGTM This is an interesting capability -- its too bad we couldn't find a way to get it done without two requests though. 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. 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. - Jesse On 2011-12-08 17:58:33, Ryan Baxter wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/3037/ > ----------------------------------------------------------- > > (Updated 2011-12-08 17:58:33) > > > Review request for shindig, Dan Dumont and Stanton Sievers. > > > Summary > ------- > > 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 addresses bug SHINDIG-1669. > https://issues.apache.org/jira/browse/SHINDIG-1669 > > > Diffs > ----- > > > http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml > 1211913 > > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js > 1211913 > > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js > 1211913 > > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js > 1211913 > > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js > 1211913 > > http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js > 1211913 > > Diff: https://reviews.apache.org/r/3037/diff > > > Testing > ------- > > Tested in container as well as updating unit tests. > > > Thanks, > > Ryan > >
