I am out of the office until 06/06/2012.
I will be travelling over this period with limited network access.
Please contact the following for urgent matters, otherwise I will respond
to your email when I return.
For SmartCloud Cluttons queries - John Haslam/UK/IBM, Mike
Owen-Lloyd/UK/IBM, Jim Ca
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 wrote:
> Henry I
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
To: daviesd ,
Cc: "dev@shindig.apache.org"
Date: 06/01/2012 03:29 PM
Subject:Re: requestNavigateTo and beta1 v.s. trunk differen
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 wrote:
> Ryan,
+1 to creating a JIRA, forgot to put that in my email.
-Ryan
From: Dan Dumont/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Cc: daviesd , Henry Saputra
Date: 06/01/2012 03:12 PM
Subject:Re: requestNavigateTo and beta1 v.s. trunk differences
Hi Doug,
The long term so
Hi Doug,
The long term solution I think should be to file a JIRA against the
upcoming beta release (I don't think we'll fix it before then)
Hopefully Henry can find a fix for it and resolve the JIRA.
From: daviesd
To: , Henry Saputra ,
Date: 06/01/2012 03:05 PM
Subject:Re: r
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" wrote:
> This is certainly a bug, I can reproduce it in the common container as
> well. After stepping through t
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 t
Currently the "default" Shindig builds are actually the ones with
generated .opt files.
The JS Closure compiler does not use the minified version because it
"cheats" the flow of getting the JS content =)
Take a look at ClosureJsCompiler.getJsContent. It wraps the incoming
JsUri with the new one tha
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 ga
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 pro
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" wrote:
> Does anyone (Dan?) have any idea why this code
>
> container.rpcRegister("requestNavigateTo", function
> requestNavigateTo(rpcAr
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 = {
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/5330/#review8288
---
Ship it!
LGTM
- Stanton
On 2012-06-01 13:56:20, Adam Clarke wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/5330/
---
Review request for shindig and Stanton Sievers.
Summary
---
Spec did become
I'm pretty sure the closure compiler will not use the pre-minified
sources. All of the code runs through the compiler the first time...
cached copies of the results are kept in ehcache.
If you're not using closure, then yeah, you might want these pre-minified
files. I suggest we move it out t
16 matches
Mail list logo
