Re: [gwt-contrib] Re: Bad link in GWT Documentation
No, Don't bother... I am starting to believe that it is caused by some reverse proxy that does some URL rewriting. I can not reproduce when working from home. Enterprise security features have a big impact on productivity :-( Thanks for the support. On Tuesday, July 8, 2014 3:15:57 AM UTC+2, Michael Vogt wrote: I checked with document mode set to IE9 with IE11, and ran in all kinds of strange behavior when navigating through the menu. Is it worth to investigate further? -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/216cbcfc-e33f-4e05-93a3-293d311ab1cc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Async process return operation on AbstractRequestContext
RequestFactory has some performance problems. One of them occurs when the AbstractRequestContext need to parse the response and create all proxies. This problem is especially annoying if the time required to process this response forces the explorer to show the warning message ~*A script on this page may be busy, or it may have stopped responding**.* I review the code and apply and alternative async execution which solves the warning-popup problem (this is not a improve performance solution), but I'm not sure if this simple solution may have some collateral problems. One weird thing about the solution is that the EntityProxyChangeEvents might be fired in different javascript loops, but this might be solved throwing this event after all operations were processed. Is there any other problem? https://github.com/ibaca/gwt/commit/cd4901a23109c5350113363f2c539a8105e874b9 I create this post to decide whether to create an issue (and patch) or not. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a369ec0c-21c9-45aa-8b5f-23d595fd4eed%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Bad link in GWT Documentation
The main problem is that pushState does not work until IE10 so IE8 and IE9 should show the plain web without menu enhancements, but it seems we are producing a permutation for them with is messing how it works. Another problem is that IE10 is executing some bad code and menu does not work at all but links work fine. IE11 is taking gecko permutation and seems to work fine. I'll take a look and try to fix. - Manolo On Tue, Jul 8, 2014 at 8:29 AM, stuckagain david.no...@gmail.com wrote: No, Don't bother... I am starting to believe that it is caused by some reverse proxy that does some URL rewriting. I can not reproduce when working from home. Enterprise security features have a big impact on productivity :-( Thanks for the support. On Tuesday, July 8, 2014 3:15:57 AM UTC+2, Michael Vogt wrote: I checked with document mode set to IE9 with IE11, and ran in all kinds of strange behavior when navigating through the menu. Is it worth to investigate further? -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/216cbcfc-e33f-4e05-93a3-293d311ab1cc%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/216cbcfc-e33f-4e05-93a3-293d311ab1cc%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAtiMdq-N8JCLSMW8aAV5GGFwt%3DoEoi84FhypGj0k7_K-A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Async process return operation on AbstractRequestContext
In this ignore white-diff is much more clear that I just wrap the end of the process in a callback - https://github.com/ibaca/gwt/commit/cd4901a23109c5350113363f2c539a8105e874b9?w=1 Also, I had tested this patch in a '1500 lines deobfuscator' application with no issue, although this patch can generate some silent concurrency problems that I had not detected yet. If I add this patch with some improvements and tests as a pull-request, it might be accepted? On Monday, July 7, 2014 3:00:53 PM UTC+2, Ignacio Baca Moreno-Torres wrote: RequestFactory has some performance problems. One of them occurs when the AbstractRequestContext need to parse the response and create all proxies. This problem is especially annoying if the time required to process this response forces the explorer to show the warning message ~*A script on this page may be busy, or it may have stopped responding**.* I review the code and apply and alternative async execution which solves the warning-popup problem (this is not a improve performance solution), but I'm not sure if this simple solution may have some collateral problems. One weird thing about the solution is that the EntityProxyChangeEvents might be fired in different javascript loops, but this might be solved throwing this event after all operations were processed. Is there any other problem? https://github.com/ibaca/gwt/commit/cd4901a23109c5350113363f2c539a8105e874b9 I create this post to decide whether to create an issue (and patch) or not. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4ee6a8ce-3925-4896-bc2e-81dea26ad8e6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Async process return operation on AbstractRequestContext
Well in general I think its not a big issue to process the response in an async way, however it just moves your problem into the future. Your patch allows you to load more data from the server without blocking the browser. However sooner or later the browser will block again because you probably start loading even more data in the future and the chunks of work will become too large again. But a maintainer of RequestFactory will decide if its worth it. IMHO your real solution would be to rethink your UI / workflow so you don't need load such a large amount of data at once. Out of curiosity: How much data are you actually trying to transfer and which causes the browser to block? As a side note: GWT does not accept pull requests on GitHub. You must sign up on Gerrit and sign a CLA: http://www.gwtproject.org/makinggwtbetter.html#submittingpatches -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9c5244f3-e55b-4ade-aa82-4c60e2294229%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Removal of IE6/7 specific code from the code base
At the end of last year, Daniel started to remove IE6/7 specific code from the SDK and make simplifications based on that; especially for the deferred bindings. We had some progress on it (see some examples [1]) though there are still work to do and looking at our plans it doesn't look like we will able to invest much time into it any time soon. So if you love cleaning up code and making things simpler and also want to be a good GWT citizen, you are highly encouraged to help out :) Please don't forget to attach IE6 topic to your patches as it helps to track them. To find such code, searching the code base with keywords (e.g. IE6. IE7, IE, ActiveX etc) is your best bet. Please always double check that the code or the workaround is only needed for IE6/7. If you encounter cases where the workaround is only required by IE8, please also add a comment for that so we can easily find it when the time comes. I don't know how many people would be interested in this work but just in case to avoid duplicate work, please update this thread after you invest some time into the patch. Cheers, - Goktug [1] https://gwt-review.googlesource.com/#/q/topic:ie6+-status:abandoned -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA3qm4of4wTThprE1V%2BpY5oXELm%3DpzDS7WCi3COoh7N5DQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
