On Sunday, July 6, 2014 8:27:29 PM UTC+2, Henrik wrote: > > On Saturday, July 5, 2014 11:29:10 PM UTC+2, Magnus wrote: >> >> I never managed to get SuperDevMode work, because I don't understand it's >> basic architecture and I was missing some detailed tutorial. So >> SuperDevMode now is the only development mode with GWT and Eclipse then I >> finally need a good tutorial, where all the steps are explained in detail. >> > > A few weeks ago I spent most of two days getting SDM to work for a client > (together with the Eclipse plugin and a multi-module maven-based project), > but in the end we could come to no other conclusion that it was borderline > unusable. While it works from cmdline with maven, that really doesn't give > you anything. > > Once working, the new thing of debugging directly in the browser certainly > seemed cool at first, until you realize that in most cases you would rather > have the java-view on your data. It's not much fun trying to drill down a > javascriptobject-representation of your arraylist or hashmap, for instance, > while your IDE's default 'toString'-view is exactly what you would want. >
That sure would be cool. The problem is that it's simply no longer technically possible. If you have the time and energy to build and maintain a browser fork with a working DevMode, go ahead; everyone will probably thank you. That would be just one browser though… > I would even be okay without any debugging options, if only the time from > "you make a change" till "you see the change" would remain a one-step > process (like a reload in the browser), and I don't see why this cannot be > done. > It can: drag the "Compile" button to your bookmarks. That saves you the click on "DevMode On" so instead of click "reload", just click the "compile" bookmarklet. Manolo has also been working on an easier way to launch SuperDevMode (just pass the -superDevMode argument to the DevMode) that also hosts the web application and doesn't require the bookmarks: there's a button in a corner instead, and a keyboard shortcut (Ctrl+K IIRC). > Why not simply use a web-filter on any *.js files (or other relevant > files) to automaticly check if the corresponding class-files have been > changed on disk and if so, then recompile the necessary gwt-parts. If the > new compiler becomes more incremental (as I've seen mentioned in some > presentations), then that should even be pretty fast, but more importantly, > it would be a one-step thing. > You could do that if you liked I believe (filter the host page; each time it's loaded, make the appropriate request to the CodeServer to trigger compilation), but sometimes reload the page without recompiling can be useful. That means your webapp would have to be different in dev than in prod too, which generally adds complexity. So at work, we still use Firefox with the automatic updates disabled for > GWT-dev in good old DevMode. It's hardly a long term solution, so I'm > really anxious to see what happens with 2.7. > Did you know you can try it out now? 2.7.0-SNAPSHOT are deployed nightly at https://oss.sonatype.org/content/repositories/google-snapshots/ -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
