On 11/06/12 12:01, Thomas Broyer wrote:
> How about customizing the CrossSiteIframeLinker instead?
> Customizing either the computeUrlForResource or loadExternalStylesheets to no
> longer be relative to the "module base url" (but rather to, say, the "host
> page base url").
> Or if you need it to be relative to the "module base url", add a linker to
> emit the appropriate CSS files in the module output dir (where the Super Dev
> Mode's will find them).
I have this working, so I'm back to using the standard code server. I have to
remember to disable my custom linker before a production release, but I had to
do that anyway with the new Super Dev Mode.
I gave my new linker the same name as the original (xsiframe) so that the
change in ScriptTagLoadingStrategory <when-linker-added name="xsiframe">
continues to work without me having to replicate that explicitly for my own
linker.
Some things I've noticed about Super Dev Mode:
(1) ImageBundle requests for *.cache.png do not go to the code server, nor do
they go through computeUrlForResource. They should probably always come from
the code server in super dev mode. Worse than this though, it seems that the
computed strong name is different in client and server. I don't know if this is
just me, but the client asks for a *.cache.png file that doesn't exist in a
production compiled app, but does exist in the code server. So I don't have any
ImageBundles working.
(2) Chrome doesn't seem to ask for the source maps unless the javascript
console is open while a compilation is done. This means that you can't debug
your app without an additional compilation if you happened to compile with the
console closed.
(3) I only worked out what was going on in (2) because the custom code server I
was originally using was set to log a message every time there was an http GET.
Perhaps there should be a verbose option on code server to provide something
similar?
(4) I have two host html files, with different deferred binding settings in
them. If I change the URL in the browser's address bar to switch between them,
a subsequent compile doesn't pick up the new bindings. I have to close the
browser tab and open a new one.
(5) If you create an interface, and then define classes that implement that
interface within the same source file, then the implementations don't appear
inside Chrome. Eg:
public interface Foo {
public int getValue();
public class FooImpl implements Foo { // --> FooImpl doesn't show up
public int getValue() { return something; }
}
}
I can live with these things, especially given the experimental nature of Super
Dev Mode. And I wouldn't want to delay 2.5 :)
Paul
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
