Henry I didn't revert them yet I just reverted them in my local environment. I will let you do that if you want :)
-Ryan From: Henry Saputra <[email protected]> To: daviesd <[email protected]>, Cc: "[email protected]" <[email protected]> Date: 06/01/2012 03:29 PM Subject: Re: requestNavigateTo and beta1 v.s. trunk differences Doug, Super mea culpa from me. I remember testing this in my env and was ok :( We need to add unit test for it. I will take a look at this tonight when I have access to my dev machine, but thanks to Ryan for reverting the changes for now. Henry On Friday, June 1, 2012, daviesd <[email protected]> wrote: > 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" <[email protected]> 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 <[email protected]> >> To: <[email protected]>, >> 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" <[email protected]> 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 <[email protected]> >>> To: shindig <[email protected]>, >>> 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" <[email protected]> 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 >>> >>> >> >> >> > > >
