Ryan, Thank You Thank You Thank You. I will try what you suggest with the buffering, but I'm not sure I want that as a long term solution.
doug On 6/1/12 2:55 PM, "Ryan J Baxter" <rjbax...@us.ibm.com> wrote: > This is certainly a bug, I can reproduce it in the common container as > well. After stepping through the code I think I figured out what is > happening, basically when you switch views after the initial load in the > GadgetSite code both the currentGadgetHolder and the loadingGadgetHolder > are set to a GadgetHolder pointing to the same DOM element. When we call > GadgetSite.onRender when switching views we first call > currentGadgetHolder.dispose which removes the element from the DOM and > then we finally set currentGadgetHolder to loadingGadgetHolder. Problem > is since the currentGadgetHolder and the loadingGadgetHolder point to the > same DOM element we end up removing the iframe which contained the new > view. > > I THINK if you supply a separate buffering element when you create your > site you would not run into this problem, you can certainly give that a > shot and see if that works. If there is no buffering element the site > will use the element in which the gadget is currently rendered in when > creating the loadingGadgetHolder, which leads to the problem we are > seeing. > > I reverted the changes Henry made in this review, > https://reviews.apache.org/r/4486/ and the problem goes away. Henry can > you take a look at this? I am pretty sure it is the changes in > SiteHolder.dispose that are causing the problem here. While I think using > a buffering element would solve the problem, the API (at this point) > indicates the buffering element is optional, so everything should work > without it. > > -Ryan > > > > > From: daviesd <davi...@oclc.org> > To: <dev@shindig.apache.org>, > Date: 06/01/2012 11:30 AM > Subject: Re: requestNavigateTo and beta1 v.s. trunk differences > > > > Ya, that was my first thought. But inspecting with firebug reveals that > there is not even any content from the view navigated to. Even if I > change > the code to > > container.navigateGadget( site, url, [], {} ); > > It doesn't re-navigate to the default view again (even though that how I > rendered the gadget in the first place). > > I'll double check on the adjustHeight stuff, but I don't think that is it. > > Thanks Ryan (btw... I watched some of your youtube opensocial sandbox > videos > yesterday... very nice). > > doug > > > On 6/1/12 11:18 AM, "Ryan J Baxter" <rjbax...@us.ibm.com> wrote: > >> Doug, does the gadget call adjustHeight? There were changes that went >> into Shindig [1] [2] that changed some of the CSS inside the gadgets >> iframe to allow the inter content to scroll. We noticed in some of our >> containers that we had to alter the CSS on our gadget sites to make > things >> work properly. Is there content actually in the site? Maybe the >> adjustHeight call is not working / the CSS for the site element needs to >> change. >> >> >> [1] https://issues.apache.org/jira/browse/SHINDIG-1766 >> [2] https://issues.apache.org/jira/browse/SHINDIG-1767 >> >> -Ryan >> >> >> >> >> From: daviesd <davi...@oclc.org> >> To: shindig <dev@shindig.apache.org>, >> Date: 06/01/2012 10:58 AM >> Subject: Re: requestNavigateTo and beta1 v.s. trunk differences >> >> >> >> Doh! It¹s Friday. I guess I should have described the symptoms. I end > up >> with a gadget with no content area (collapsed). >> >> >> On 6/1/12 10:50 AM, "daviesd" <davi...@oclc.org> wrote: >> >>> Does anyone (Dan?) have any idea why this code >>> >>> container.rpcRegister("requestNavigateTo", function >>> requestNavigateTo(rpcArgs, view, params) { >>> >>> var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY], >>> url = site.getActiveSiteHolder().getUrl(), >>> renderParams = {}; >>> >>> renderParams[osapi.container.RenderParam.VIEW] = view; >>> container.navigateGadget( site, url, params, renderParams ); >>> }); >>> >>> doesn¹t work with the latest 2.5 snapshot? We¹ve been using beta1 > since >> it >>> was created, but will all the activity for beta2 I thought I ought to >> get a >>> jump start and see what broke for us. This worked in beta1. I¹ve >> logged the >>> site, url, and view and they all seem legit. >>> >>> doug >> >> > > >
