Ah ok =) Doug, how do you consume Shindig? If you do it through maven resource you can get the fix in the next beta release.
I will take a look at it once I have access to my dev env, and apologize again for the trouble =( - Henry On Fri, Jun 1, 2012 at 12:31 PM, Ryan J Baxter <[email protected]> wrote: > 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 >>>> >>>> >>> >>> >>> >> >> >> >
