I've just tried to take the demo for a spin but I had a few problems
trying to convince the dev_mode_on code that super dev mode was
enabled. Hopefully I'm missing something but from a quick look over
the code I think something might be unavailable in the public version.
dev_mode_on contains the following conditional when showing/hiding the
compile bookmarklet -
var mod = modules_on_page[module_name];
var dev_mode_key = '__gwtDevModeHook:' + module_name;
var dev_mode_on = mod['superdevmode'] ||
window.sessionStorage[dev_mode_key];
if (!dev_mode_on && !mod.canRedirect) {
return 'This module doesn\'t have Super Dev Mode enabled';
}
In my case it keeps falling into the "This module doesn't have SDM
enabled" block and no SDM for me! However, if I force one of the
conditions to skip the block everything works nicely for that compile
and subsequent compiles. I'm assuming that the sessionStorage is
responsible for latching the behaviour, so I looked into what sets
window.__gwt_activeModules[module_name]['superdevmode'] and
window.__gwt_activeModules[module_name].canRedirect.
The only place I can find that sets
window.__gwt_activeModules[module_name]['superdevmode'] is a custom
version (although the original doesn't seem to be in the source tree)
of computeScriptBase.js which isn't used by the standard
CrossSiteIframeLinker. A comment in Recompiler suggests that it is
used by Google's server-side linker.
window.__gwt_activeModules[module_name].canRedirect seems only to be
set by the DevModeRedirectHook.js which is included by
CrossSiteIframeLinker when devModeRedirectEnabled is true. However,
Recompiler checks for the existence of this property (throwing if it
doesn't exist) before forcing it to false.
My current workaround is to prepend the following onto my dev mode on
bookmarklet -
window.__gwt_activeModules.hello.superdevmode = true;
Is this a genuine problem or am I going about this all wrong?
Chris
On Tue, Jun 5, 2012 at 9:02 PM, <[email protected]> wrote:
> Ray, you can see the diffs by looking at internal code review. I updated
> a bunch of javadoc, tweaked Recompiler to deal with running with a
> different linker, and changed the regexps in WebServer to be slightly
> tighter and a bit more readable. But sure, basically the same.
>
>
>
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/BUILD
> File dev/codeserver/BUILD (right):
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/BUILD#newcode1
> dev/codeserver/BUILD:1: # Copyright 2012 Google Inc. All rights
> reserved.
> On 2012/06/05 01:05:21, cromwellian wrote:
>>
>> Do we really want the BUILD file in the public repo?
>
>
> I was using an out-of-date version of rietveld that didn't ignore these
> files. Fixed.
>
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java
> File dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java
> (right):
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java#newcode2
> dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java:2: *
> Copyright 2011 Google Inc.
> On 2012/06/05 10:52:58, tbroyer wrote:
>>
>> 2012 ?
>
>
> Well, I started on some of these files last year, so I'm going to leave
> it.
>
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java
> File dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java
> (right):
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java#newcode49
> dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java:49:
> defaultProps.put("user.agent", "safari");
> On 2012/06/05 10:52:58, tbroyer wrote:
>>
>> This is just a "default" for the very first compilation, right?
>> (but hard-coding things that way will prevent detecting the "right"
>
> permutation
>>
>> later on, no?)
>
>
> Yes, this is just for the first compile and the output isn't intended to
> be run. Normally when you are running a separate server, the binding
> properties will be computed by the nocache.js script of the
> non-superdevmode version of the GWT app, and then they're saved in
> session storage, so we always compile the same permutation.
>
> However, I recently added support for running html files directly out of
> the Super Dev Mode code server (for an all-static GWT app where a
> separate server isn't needed). In that case, the initial compile *is*
> used, which is the wrong permutation if you're not using Safari or
> Chrome. And on the second compile, it will build all permutations, which
> is another bug.
>
> I'll be fixing this later. I'd like to see if there's a way to terminate
> the initial compile early and not output a permutation. It's a useful
> sanity check but shouldn't take too long.
>
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java
> File dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java
> (right):
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java#newcode134
> dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java:134:
> private class SourceFlag extends ArgHandler {
> On 2012/06/05 10:52:58, tbroyer wrote:
>>
>> Why not use ArgHandlerDir?
>
>
> This variant actually checks that the directory exists. (Probably
> ArgHandlerDir should be fixed, but I didn't want to get into that.)
>
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java#newcode148
> dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java:148:
> return "The root of a directory tree containing GWT source code to
> compile.";
> On 2012/06/05 16:15:35, cromwellian wrote:
>>
>> On 2012/06/05 10:52:58, tbroyer wrote:
>> > Does this mean SuperDevMode no longer loads sources from the
>
> classpath?
>
>> It picks up from the classpath, but this directory shadows the
>
> classpath. The
>>
>> reason is, at least for Google, we always produce source-jars in our
>
> internal
>>
>> build system, and you can't 'edit' them. That is, when we launch
>
> superdevmode,
>>
>> it has the source, but it's been compiled and put into jars on the CP.
>
> This
>>
>> directory allows us to specify another location to look at, in
>
> addition to the
>>
>> classpath (which is the fallback)
>
>
>> For external users, it may not be needed, although I could see if
>
> superdevmode
>>
>> is launched from a Maven build you might run into the same issue.
>
>
>
> Tweaked the help text a bit.
>
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java
> File dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java
> (right):
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java#newcode164
> dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java:164: //
> This is a GET because a bookmarklet can call it from a different origin
> (JSONP).
> On 2012/06/05 10:52:58, tbroyer wrote:
>>
>> We should probably use CORS and XMLHttpRequest with a POST request,
>
> instead of
>>
>> JSON-P. The bookmarklet could handle XDomainRequest for IE8/9 and even
>
> possibly
>>
>> create an HTML form if we want to support IE6/7.
>
>
>> White-listing origins from command-line arguments would also add some
>
> security.
>
> Yeah, CORS is better and I'm not too concerned about old browsers. Users
> would have to maintain the whitelist, though. If we want to wildcard
> hostnames (e.g. everything under corp.google.com), I think that requires
> a preflight request?
>
>
> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java#newcode456
> dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java:456:
> private static String escapeHtmlCharacters(String line) {
> On 2012/06/05 10:52:58, tbroyer wrote:
>>
>> Couldn't we use SafeHtml.fromString() here?
>
>
> Currently, gwt-codeserver.jar only depends on gwt-dev.jar (and its
> dependencies) and I'd rather not add the dependency until it enables a
> more important feature.
>
>
> http://gwt-code-reviews.appspot.com/1727804/
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
