Re: Debugging GWT 2.0 is pain
On FireFox, you could install the GreaseMonkey extension and write a quick script that looks for the gwt.codesvr parameter on the current page and adds the same parameter to all links. I don't know if there is something similar in other browsers. https://addons.mozilla.org/en-US/firefox/addon/748 HTH, Eric On Mar 11, 12:46 pm, JazzyJava ole...@gmail.com wrote: Thanks for the quick response. I looked at the link (https://groups.google.com/group/google-web- toolkit/msg/e6d2814e79bc3a45), and it looks like a hack. It will only work if I have some centralized URL generation logic, AND if I pass the gwt.codesvr=x query param at some correct prior point that will start adding it to the generated URL's. There is nothing fancy about how we generate URL's. We have mostly a JSP application, and the GWT module is linked to from a half-dozen places (e.g. from another GWT module and from non-GWT jsp files, etc.). Each link passes dynamic params (e.g. orderId, clientId, etc.) to the GWT module in question. It appears that a better solution would be to provide a list of modules (by URL pattern, for example) directly to the browser plugin, so that it can append the gwt.codesvr=x automatically when needed. Thanks, Oleg On Mar 11, 11:53 am, Chris Ramsdale cramsd...@google.com wrote: Comments in line below: On Thu, Mar 11, 2010 at 11:40 AM, JazzyJava ole...@gmail.com wrote: Helllo, I am testing an upgrade of our appliation fro GWT 1.7 to 2.0. All is fine, except I find that debugging now is a much bigger pain than it was in 1.7. I have a feeling I am missing something, since it's hard for me to believe that it is so much more inconvinient now. In GWT 1.7 Hosted Mode browser, I could happily click on my links (GWT or non non-GWT modules), and when I clicked on the GWT module that had a breakpoint, the Eclipse debugger would kick in. Correct. The downside of this was that the GWT hosted mode browser was wrapping IE on Windows, Safari on Mac, and Firefox on linux, which meant that you had to bounce around to separate operating systems in order to debug your application in a different browser. Our URL's are for the most part dynamic, i.e. they pass a bunch of dynamic URL query parameters to the GWT module. In GWT 2.0 debugging, I now have to copy-paste the dynamic URL into a browser window that has the address bar enabled, and manually add gwt.codesvr=xxx URL query parameter at the end. Since they're dynamic, you might be able to incorporate some of the techniques discussed here:https://groups.google.com/group/google-web-toolkit/msg/e6d2814e79bc3a45 This is major pain and I am not sure how I can justify an upgrade to 2.0 until I understand how to let my development team conveniently debug. If the above suggestion doesn't work out for a you, a repost with an explanation and code snippets (regarding how you generate your URLs) would be helpful. If anyone can shed some light on this pain, it will be very much appreciated. Oleg -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2Bunsubs cr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.-Hide quoted text - - Show quoted text - -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Debugging GWT 2.0 is pain
I find hat being able to debug in firefox with firebug and have gwt breakpoints to be vastly surperior to old school hosted mode. I guess I haven't had the frustration that you have because I just leave the browser minimized between debug sessions and refresh when necessary. On Mar 11, 10:40 am, JazzyJava ole...@gmail.com wrote: Helllo, I am testing an upgrade of our appliation fro GWT 1.7 to 2.0. All is fine, except I find that debugging now is a much bigger pain than it was in 1.7. I have a feeling I am missing something, since it's hard for me to believe that it is so much more inconvinient now. In GWT 1.7 Hosted Mode browser, I could happily click on my links (GWT or non non-GWT modules), and when I clicked on the GWT module that had a breakpoint, the Eclipse debugger would kick in. Our URL's are for the most part dynamic, i.e. they pass a bunch of dynamic URL query parameters to the GWT module. In GWT 2.0 debugging, I now have to copy-paste the dynamic URL into a browser window that has the address bar enabled, and manually add gwt.codesvr=xxx URL query parameter at the end. This is major pain and I am not sure how I can justify an upgrade to 2.0 until I understand how to let my development team conveniently debug. If anyone can shed some light on this pain, it will be very much appreciated. Oleg -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Debugging GWT 2.0 is pain
Thanks. GreaseMonkey could prove to be the solution here, although I have to experiment to see if GreaseMonkey will correctly pick up dynamically generated DOM (e.g. links generated as part of a GWT module). Wouldn't be surprised if such script has already been written On Mar 12, 6:34 am, Eric edimickeast...@gmail.com wrote: On FireFox, you could install the GreaseMonkey extension and write a quick script that looks for the gwt.codesvr parameter on the current page and adds the same parameter to all links. I don't know if there is something similar in other browsers. https://addons.mozilla.org/en-US/firefox/addon/748 HTH, Eric On Mar 11, 12:46 pm, JazzyJava ole...@gmail.com wrote: Thanks for the quick response. I looked at the link (https://groups.google.com/group/google-web- toolkit/msg/e6d2814e79bc3a45), and it looks like a hack. It will only work if I have some centralized URL generation logic, AND if I pass the gwt.codesvr=x query param at some correct prior point that will start adding it to the generated URL's. There is nothing fancy about how we generate URL's. We have mostly a JSP application, and the GWT module is linked to from a half-dozen places (e.g. from another GWT module and from non-GWT jsp files, etc.). Each link passes dynamic params (e.g. orderId, clientId, etc.) to the GWT module in question. It appears that a better solution would be to provide a list of modules (by URL pattern, for example) directly to the browser plugin, so that it can append the gwt.codesvr=x automatically when needed. Thanks, Oleg On Mar 11, 11:53 am, Chris Ramsdale cramsd...@google.com wrote: Comments in line below: On Thu, Mar 11, 2010 at 11:40 AM, JazzyJava ole...@gmail.com wrote: Helllo, I am testing an upgrade of our appliation fro GWT 1.7 to 2.0. All is fine, except I find that debugging now is a much bigger pain than it was in 1.7. I have a feeling I am missing something, since it's hard for me to believe that it is so much more inconvinient now. In GWT 1.7 Hosted Mode browser, I could happily click on my links (GWT or non non-GWT modules), and when I clicked on the GWT module that had a breakpoint, the Eclipse debugger would kick in. Correct. The downside of this was that the GWT hosted mode browser was wrapping IE on Windows, Safari on Mac, and Firefox on linux, which meant that you had to bounce around to separate operating systems in order to debug your application in a different browser. Our URL's are for the most part dynamic, i.e. they pass a bunch of dynamic URL query parameters to the GWT module. In GWT 2.0 debugging, I now have to copy-paste the dynamic URL into a browser window that has the address bar enabled, and manually add gwt.codesvr=xxx URL query parameter at the end. Since they're dynamic, you might be able to incorporate some of the techniques discussed here:https://groups.google.com/group/google-web-toolkit/msg/e6d2814e79bc3a45 This is major pain and I am not sure how I can justify an upgrade to 2.0 until I understand how to let my development team conveniently debug. If the above suggestion doesn't work out for a you, a repost with an explanation and code snippets (regarding how you generate your URLs) would be helpful. If anyone can shed some light on this pain, it will be very much appreciated. Oleg -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2Bunsubs cr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.-Hidequoted text - - Show quoted text -- Hide quoted text - - Show quoted text - -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Debugging GWT 2.0 is pain
I fully agree, running a GWT app in native browser and being able to debug it is the way to go, hosted mode is history. However, for the time being, it looks like Google didn't really think their browser plug-in through for accomodate apps which are gradually introducing GWT by incorporating GWT modules into existing pages. If my app was fully GWT with one module running the whole app, then I would just do what you do. I have seen others around the web posting similar frustrations, calling new GWT debugging virtually impossible, now I understand why. The browser plug-in should really accept URL patterns that represent GWT modules you want to debug. I may be missing something here, but this appears as the most practical solution. On Mar 12, 12:11 pm, Trevis trevistho...@gmail.com wrote: I find hat being able to debug in firefox with firebug and have gwt breakpoints to be vastly surperior to old school hosted mode. I guess I haven't had the frustration that you have because I just leave the browser minimized between debug sessions and refresh when necessary. On Mar 11, 10:40 am, JazzyJava ole...@gmail.com wrote: Helllo, I am testing an upgrade of our appliation fro GWT 1.7 to 2.0. All is fine, except I find that debugging now is a much bigger pain than it was in 1.7. I have a feeling I am missing something, since it's hard for me to believe that it is so much more inconvinient now. In GWT 1.7 Hosted Mode browser, I could happily click on my links (GWT or non non-GWT modules), and when I clicked on the GWT module that had a breakpoint, the Eclipse debugger would kick in. Our URL's are for the most part dynamic, i.e. they pass a bunch of dynamic URL query parameters to the GWT module. In GWT 2.0 debugging, I now have to copy-paste the dynamic URL into a browser window that has the address bar enabled, and manually add gwt.codesvr=xxx URL query parameter at the end. This is major pain and I am not sure how I can justify an upgrade to 2.0 until I understand how to let my development team conveniently debug. If anyone can shed some light on this pain, it will be very much appreciated. Oleg- Hide quoted text - - Show quoted text - -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Debugging GWT 2.0 is pain
Comments in line below: On Thu, Mar 11, 2010 at 11:40 AM, JazzyJava ole...@gmail.com wrote: Helllo, I am testing an upgrade of our appliation fro GWT 1.7 to 2.0. All is fine, except I find that debugging now is a much bigger pain than it was in 1.7. I have a feeling I am missing something, since it's hard for me to believe that it is so much more inconvinient now. In GWT 1.7 Hosted Mode browser, I could happily click on my links (GWT or non non-GWT modules), and when I clicked on the GWT module that had a breakpoint, the Eclipse debugger would kick in. Correct. The downside of this was that the GWT hosted mode browser was wrapping IE on Windows, Safari on Mac, and Firefox on linux, which meant that you had to bounce around to separate operating systems in order to debug your application in a different browser. Our URL's are for the most part dynamic, i.e. they pass a bunch of dynamic URL query parameters to the GWT module. In GWT 2.0 debugging, I now have to copy-paste the dynamic URL into a browser window that has the address bar enabled, and manually add gwt.codesvr=xxx URL query parameter at the end. Since they're dynamic, you might be able to incorporate some of the techniques discussed here: https://groups.google.com/group/google-web-toolkit/msg/e6d2814e79bc3a45 This is major pain and I am not sure how I can justify an upgrade to 2.0 until I understand how to let my development team conveniently debug. If the above suggestion doesn't work out for a you, a repost with an explanation and code snippets (regarding how you generate your URLs) would be helpful. If anyone can shed some light on this pain, it will be very much appreciated. Oleg -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Debugging GWT 2.0 is pain
Thanks for the quick response. I looked at the link (https://groups.google.com/group/google-web- toolkit/msg/e6d2814e79bc3a45), and it looks like a hack. It will only work if I have some centralized URL generation logic, AND if I pass the gwt.codesvr=x query param at some correct prior point that will start adding it to the generated URL's. There is nothing fancy about how we generate URL's. We have mostly a JSP application, and the GWT module is linked to from a half-dozen places (e.g. from another GWT module and from non-GWT jsp files, etc.). Each link passes dynamic params (e.g. orderId, clientId, etc.) to the GWT module in question. It appears that a better solution would be to provide a list of modules (by URL pattern, for example) directly to the browser plugin, so that it can append the gwt.codesvr=x automatically when needed. Thanks, Oleg On Mar 11, 11:53 am, Chris Ramsdale cramsd...@google.com wrote: Comments in line below: On Thu, Mar 11, 2010 at 11:40 AM, JazzyJava ole...@gmail.com wrote: Helllo, I am testing an upgrade of our appliation fro GWT 1.7 to 2.0. All is fine, except I find that debugging now is a much bigger pain than it was in 1.7. I have a feeling I am missing something, since it's hard for me to believe that it is so much more inconvinient now. In GWT 1.7 Hosted Mode browser, I could happily click on my links (GWT or non non-GWT modules), and when I clicked on the GWT module that had a breakpoint, the Eclipse debugger would kick in. Correct. The downside of this was that the GWT hosted mode browser was wrapping IE on Windows, Safari on Mac, and Firefox on linux, which meant that you had to bounce around to separate operating systems in order to debug your application in a different browser. Our URL's are for the most part dynamic, i.e. they pass a bunch of dynamic URL query parameters to the GWT module. In GWT 2.0 debugging, I now have to copy-paste the dynamic URL into a browser window that has the address bar enabled, and manually add gwt.codesvr=xxx URL query parameter at the end. Since they're dynamic, you might be able to incorporate some of the techniques discussed here:https://groups.google.com/group/google-web-toolkit/msg/e6d2814e79bc3a45 This is major pain and I am not sure how I can justify an upgrade to 2.0 until I understand how to let my development team conveniently debug. If the above suggestion doesn't work out for a you, a repost with an explanation and code snippets (regarding how you generate your URLs) would be helpful. If anyone can shed some light on this pain, it will be very much appreciated. Oleg -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.- Hide quoted text - - Show quoted text - -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
