I like where you might be going with your last paragraph (the IntelliJ part )..."Other than that there is the experimental Eclipse plugin named SDBG so you can use your IDE for debugging (but you are still debugging JS!). IntelliJ can do the same out of the box."
Are you saying that IntelliJ can somehow use SDM and still be debugging in IntelliJ? If so I'd like to know more about this. I was thinking that for SDM to be acceptable...somehow it has to get back to the IDE so I can debug, navigate & edit in one tool. If this is possible then SDM starts to look better. On Mon, Nov 3, 2014 at 8:36 AM, Jens <jens.nehlme...@gmail.com> wrote: > I definitely use a MVP/C model but not Places. I don't think I should be >> tided to one and only one MVP approach. >> > > Places are just for navigation. They have nothing to do with MVP. You can > use them without GWTs Activity class. > > > >> However even if I did it's not clear how that would help the fact that >> the browser has a 'copy' or 'image' of the real thing...at the end of the >> day I need my IDE to make changes. >> > > Yeah it is a bit counter intuitive if you see your Java code in the > browser and want to debug it. The best thing you can do is to place > breakpoints and then step through the code. Navigating the code with > something like ctrl + click as in Java IDEs is not possible with source > maps (although you can search, open file, goto line using shortcuts). Also > conditional break points obviously need to use JavaScript expressions. At > the end you are debugging JavaScript that only got visually transformed > into your original Java code to please your eyes. > > As an alternative you could try the following in Chrome: > - use the SDM parameter -XmethodNameDisplayMode with your desired setting > - Disable source maps in Chrome Dev Tools. > > Now you are dealing with the raw JavaScript (which already looks pretty > similar to your Java code) but when hitting a breakpoint Chrome will > display your Java class/method name for each stack element. So you kind of > see a Java stack trace in Chrome but when clicking on it you see the raw JS > code. The added benefit of using raw JS is that while a break point is > active you can now hover JS code and Chrome will give you additional > information about the code as well as a link to jump to the definition. And > with the Java like stack trace it is easier to spot the code path in your > IDE. Might be an interesting compromise. > > Other than that there is the experimental Eclipse plugin named SDBG so you > can use your IDE for debugging (but you are still debugging JS!). IntelliJ > can do the same out of the box. > > -- J. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Google Web Toolkit" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > google-web-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@googlegroups.com. > Visit this group at http://groups.google.com/group/google-web-toolkit. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
