[gwt-contrib] [google-web-toolkit commit] r4982 - releases/1.6/tools/benchmark-viewer
Author: sco...@google.com Date: Tue Mar 10 19:16:02 2009 New Revision: 4982 Modified: releases/1.6/tools/benchmark-viewer/build.xml Log: Fixed wrong default build rule. Modified: releases/1.6/tools/benchmark-viewer/build.xml == --- releases/1.6/tools/benchmark-viewer/build.xml (original) +++ releases/1.6/tools/benchmark-viewer/build.xml Tue Mar 10 19:16:02 2009 @@ -74,7 +74,7 @@ - + --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4981 - releases/1.6/eclipse/tools/benchmark-viewer
Author: sco...@google.com Date: Tue Mar 10 18:53:38 2009 New Revision: 4981 Added: releases/1.6/eclipse/tools/benchmark-viewer/ReportViewer-gwtc.launch releases/1.6/eclipse/tools/benchmark-viewer/ReportViewer.launch Log: Adding launch configs for benchmark viewer. Added: releases/1.6/eclipse/tools/benchmark-viewer/ReportViewer-gwtc.launch == --- (empty file) +++ releases/1.6/eclipse/tools/benchmark-viewer/ReportViewer-gwtc.launch Tue Mar 10 18:53:38 2009 @@ -0,0 +1,17 @@ + + + + + + + + + + + + + + + + + Added: releases/1.6/eclipse/tools/benchmark-viewer/ReportViewer.launch == --- (empty file) +++ releases/1.6/eclipse/tools/benchmark-viewer/ReportViewer.launch Tue Mar 10 18:53:38 2009 @@ -0,0 +1,17 @@ + + + + + + + + + + + + + + + + + --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4980 - in releases/1.6: dev/core/src/com/google/gwt/dev dev/core/src/com/google/gwt/dev/shell di...
Author: sco...@google.com
Date: Tue Mar 10 18:42:26 2009
New Revision: 4980
Added:
releases/1.6/dev/core/src/com/google/gwt/dev/RunWebApp.java (contents,
props changed)
releases/1.6/tools/benchmark-viewer/war/
releases/1.6/tools/benchmark-viewer/war/ReportViewer.css
- copied unchanged from r4963,
/releases/1.6/tools/benchmark-viewer/src/com/google/gwt/benchmarks/viewer/public/ReportViewer.css
releases/1.6/tools/benchmark-viewer/war/ReportViewer.html
- copied, changed from r4963,
/releases/1.6/tools/benchmark-viewer/src/com/google/gwt/benchmarks/viewer/public/ReportViewer.html
releases/1.6/tools/benchmark-viewer/war/WEB-INF/
releases/1.6/tools/benchmark-viewer/war/WEB-INF/classes/
releases/1.6/tools/benchmark-viewer/war/WEB-INF/classes/marker
releases/1.6/tools/benchmark-viewer/war/WEB-INF/web.xml (contents,
props changed)
Removed:
releases/1.6/tools/benchmark-viewer/src/com/google/gwt/benchmarks/viewer/public/ReportViewer.css
releases/1.6/tools/benchmark-viewer/src/com/google/gwt/benchmarks/viewer/public/ReportViewer.html
releases/1.6/tools/benchmark-viewer/test/
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/HostedModeBase.java
releases/1.6/dev/core/src/com/google/gwt/dev/shell/BrowserWidget.java
releases/1.6/distro-source/linux/build.xml
releases/1.6/distro-source/linux/src/benchmarkViewer
releases/1.6/distro-source/mac/build.xml
releases/1.6/distro-source/mac/src/benchmarkViewer
releases/1.6/distro-source/windows/build.xml
releases/1.6/distro-source/windows/src/benchmarkViewer.cmd
releases/1.6/eclipse/tools/benchmark-viewer/ (props changed)
releases/1.6/eclipse/tools/benchmark-viewer/.classpath
releases/1.6/eclipse/tools/benchmark-viewer/.project
releases/1.6/tools/benchmark-viewer/build.xml
releases/1.6/tools/benchmark-viewer/src/com/google/gwt/benchmarks/viewer/ReportViewer.gwt.xml
releases/1.6/tools/benchmark-viewer/src/com/google/gwt/benchmarks/viewer/client/ReportServer.java
releases/1.6/tools/benchmark-viewer/src/com/google/gwt/benchmarks/viewer/client/ReportViewer.java
releases/1.6/tools/benchmark-viewer/src/com/google/gwt/benchmarks/viewer/server/ReportImageServer.java
Log:
Updates BenchmarkViewer to 1.6 style. It's now launched through the new
RunWebApp command-line tool.
Suggested by: bruce
Review by: jgw
Modified: releases/1.6/dev/core/src/com/google/gwt/dev/HostedModeBase.java
==
--- releases/1.6/dev/core/src/com/google/gwt/dev/HostedModeBase.java
(original)
+++ releases/1.6/dev/core/src/com/google/gwt/dev/HostedModeBase.javaTue
Mar 10 18:42:26 2009
@@ -322,6 +322,27 @@
}
}
+ public static String normalizeURL(String unknownUrlText, int port,
String host) {
+if (unknownUrlText.indexOf(":") != -1) {
+ // Assume it's a full url.
+ return unknownUrlText;
+}
+
+// Assume it's a trailing url path.
+if (unknownUrlText.length() > 0 && unknownUrlText.charAt(0) == '/') {
+ unknownUrlText = unknownUrlText.substring(1);
+}
+
+if (port != 80) {
+ // CHECKSTYLE_OFF: Not really an assembled error message, so no space
+ // after ':'.
+ return "http://"; + host + ":" + port + "/" + unknownUrlText;
+ // CHECKSTYLE_ON
+} else {
+ return "http://"; + host + "/" + unknownUrlText;
+}
+ }
+
protected final HostedModeBaseOptions options;
/**
@@ -363,26 +384,7 @@
public abstract void launchStartupUrls(final TreeLogger logger);
public final String normalizeURL(String unknownUrlText) {
-if (unknownUrlText.indexOf(":") != -1) {
- // Assume it's a full url.
- return unknownUrlText;
-}
-
-// Assume it's a trailing url path.
-if (unknownUrlText.length() > 0 && unknownUrlText.charAt(0) == '/') {
- unknownUrlText = unknownUrlText.substring(1);
-}
-
-int port = getPort();
-String host = getHost();
-if (port != 80) {
- // CHECKSTYLE_OFF: Not really an assembled error message, so no space
- // after ':'.
- return "http://"; + host + ":" + port + "/" + unknownUrlText;
- // CHECKSTYLE_ON
-} else {
- return "http://"; + host + "/" + unknownUrlText;
-}
+return normalizeURL(unknownUrlText, getPort(), getHost());
}
/**
Added: releases/1.6/dev/core/src/com/google/gwt/dev/RunWebApp.java
==
--- (empty file)
+++ releases/1.6/dev/core/src/com/google/gwt/dev/RunWebApp.java Tue Mar 10
18:42:26 2009
@@ -0,0 +1,144 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicabl
[gwt-contrib] [google-web-toolkit commit] r4979 - in releases/1.6/user: src/com/google/gwt/dom/client src/com/google/gwt/user/client/impl t...
Author: sco...@google.com
Date: Tue Mar 10 18:13:47 2009
New Revision: 4979
Removed:
releases/1.6/user/src/com/google/gwt/user/client/impl/DocumentRootImplSafari.java
Modified:
releases/1.6/user/src/com/google/gwt/dom/client/DOMImplIE6.java
releases/1.6/user/src/com/google/gwt/dom/client/DOMImplSafari.java
releases/1.6/user/src/com/google/gwt/dom/client/Document.java
releases/1.6/user/test/com/google/gwt/user/client/ui/RadioButtonTest.java
Log:
Sort / format / checkstyle cleanup.
Modified: releases/1.6/user/src/com/google/gwt/dom/client/DOMImplIE6.java
==
--- releases/1.6/user/src/com/google/gwt/dom/client/DOMImplIE6.java
(original)
+++ releases/1.6/user/src/com/google/gwt/dom/client/DOMImplIE6.java Tue Mar
10 18:13:47 2009
@@ -148,26 +148,6 @@
/ getZoomMultiple(doc) + doc.getScrollTop());
}
- private native int getBoundingClientRectLeft(Element elem) /*-{
-// getBoundingClientRect() throws a JS exception if the elem is not
attached
-// to the document, so we wrap it in a try/catch block
-try {
- return elem.getBoundingClientRect().left;
-} catch (e) {
- return 0;
-}
- }-*/;
-
- private native int getBoundingClientRectTop(Element elem) /*-{
-// getBoundingClientRect() throws a JS exception if the elem is not
attached
-// to the document, so we wrap it in a try/catch block
-try {
- return elem.getBoundingClientRect().top;
-} catch (e) {
- return 0;
-}
- }-*/;
-
/**
* IE returns a numeric type for some attributes that are really
properties,
* such as offsetWidth. We need to coerce these to strings to prevent a
@@ -241,6 +221,26 @@
@Override
public native void setInnerText(Element elem, String text) /*-{
elem.innerText = text || '';
+ }-*/;
+
+ private native int getBoundingClientRectLeft(Element elem) /*-{
+// getBoundingClientRect() throws a JS exception if the elem is not
attached
+// to the document, so we wrap it in a try/catch block
+try {
+ return elem.getBoundingClientRect().left;
+} catch (e) {
+ return 0;
+}
+ }-*/;
+
+ private native int getBoundingClientRectTop(Element elem) /*-{
+// getBoundingClientRect() throws a JS exception if the elem is not
attached
+// to the document, so we wrap it in a try/catch block
+try {
+ return elem.getBoundingClientRect().top;
+} catch (e) {
+ return 0;
+}
}-*/;
/**
Modified: releases/1.6/user/src/com/google/gwt/dom/client/DOMImplSafari.java
==
--- releases/1.6/user/src/com/google/gwt/dom/client/DOMImplSafari.java
(original)
+++ releases/1.6/user/src/com/google/gwt/dom/client/DOMImplSafari.java Tue
Mar 10 18:13:47 2009
@@ -143,6 +143,20 @@
}-*/;
@Override
+ public int getScrollLeft(Document doc) {
+// Safari always applies document scrolling to the body element, even
in
+// strict mode.
+return doc.getBody().getScrollLeft();
+ }
+
+ @Override
+ public int getScrollTop(Document doc) {
+// Safari always applies document scrolling to the body element, even
in
+// strict mode.
+return doc.getBody().getScrollTop();
+ }
+
+ @Override
public native boolean isOrHasChild(Element parent, Element child) /*-{
while (child) {
if (parent == child) {
@@ -185,20 +199,6 @@
public native void selectRemoveOption(SelectElement select, int index)
/*-{
select.removeChild(select.children[index]);
}-*/;
-
- @Override
- public int getScrollLeft(Document doc) {
-// Safari always applies document scrolling to the body element, even
in
-// strict mode.
-return doc.getBody().getScrollLeft();
- }
-
- @Override
- public int getScrollTop(Document doc) {
-// Safari always applies document scrolling to the body element, even
in
-// strict mode.
-return doc.getBody().getScrollTop();
- }
@Override
public void setScrollLeft(Document doc, int left) {
Modified: releases/1.6/user/src/com/google/gwt/dom/client/Document.java
==
--- releases/1.6/user/src/com/google/gwt/dom/client/Document.java
(original)
+++ releases/1.6/user/src/com/google/gwt/dom/client/Document.java Tue Mar
10 18:13:47 2009
@@ -1216,20 +1216,6 @@
}-*/;
/**
- * Gets the document's viewport element. This is the element that should
be
- * used to for scrolling and client-area measurement. In quirks-mode it
is the
- * element, while in standards-mode it is the
- * element.
- *
- * This is package-protected because the viewport is
- *
- * @return the document's viewport element
- */
- final Element getViewportElement() {
-return isCSS1Compat() ? getDocumentElement() : getBody();
- }
-
- /**
* Im
[gwt-contrib] [google-web-toolkit commit] r4978 - in releases/1.6/user: src/com/google/gwt/user/client/ui test/com/google/gwt/user/client/ui
Author: rj...@google.com
Date: Tue Mar 10 17:16:05 2009
New Revision: 4978
Modified:
releases/1.6/user/src/com/google/gwt/user/client/ui/CheckBox.java
releases/1.6/user/test/com/google/gwt/user/client/ui/RadioButtonTest.java
Log:
Fixes issue 3454, "RadioButtons fire ValueChangeEvents when clicked
even when value does not change"
Reviewed by jgw
Modified: releases/1.6/user/src/com/google/gwt/user/client/ui/CheckBox.java
==
--- releases/1.6/user/src/com/google/gwt/user/client/ui/CheckBox.java
(original)
+++ releases/1.6/user/src/com/google/gwt/user/client/ui/CheckBox.java Tue
Mar 10 17:16:05 2009
@@ -20,6 +20,10 @@
import com.google.gwt.dom.client.LabelElement;
import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
+import com.google.gwt.event.dom.client.KeyUpEvent;
+import com.google.gwt.event.dom.client.KeyUpHandler;
+import com.google.gwt.event.dom.client.MouseUpEvent;
+import com.google.gwt.event.dom.client.MouseUpHandler;
import com.google.gwt.event.logical.shared.ValueChangeEvent;
import com.google.gwt.event.logical.shared.ValueChangeHandler;
import com.google.gwt.event.shared.HandlerRegistration;
@@ -55,6 +59,7 @@
private InputElement inputElem;
private LabelElement labelElem;
private boolean valueChangeHandlerInitialized;
+ private boolean valueBeforeClick;
/**
* Creates a check box with no label.
@@ -111,17 +116,29 @@
public HandlerRegistration addValueChangeHandler(
ValueChangeHandler handler) {
-// Is this the first value change handler? If so, time to listen to
clicks
-// on the checkbox
+// Is this the first value change handler? If so, time to add handlers
if (!valueChangeHandlerInitialized) {
- valueChangeHandlerInitialized = true;
+
+ this.addKeyUpHandler(new KeyUpHandler() {
+public void onKeyUp(KeyUpEvent event) {
+ valueBeforeClick = getValue();
+}
+ });
+
+ this.addMouseUpHandler(new MouseUpHandler() {
+public void onMouseUp(MouseUpEvent event) {
+ valueBeforeClick = getValue();
+}
+ });
+
this.addClickHandler(new ClickHandler() {
public void onClick(ClickEvent event) {
- // No need to compare old value and new value--click handler
- // only fires on real click, and value always toggles
- ValueChangeEvent.fire(CheckBox.this, getValue());
+ ValueChangeEvent.fireIfNotEqual(CheckBox.this, valueBeforeClick,
+ getValue());
}
});
+
+ valueChangeHandlerInitialized = true;
}
return addHandler(handler, ValueChangeEvent.getType());
}
@@ -312,13 +329,15 @@
}
}
- // Unlike other widgets the CheckBox sinks on its input element, not its
- // wrapper element.
+ // Unlike other widgets the CheckBox sinks on its constituent elements,
not
+ // their wrapper element.
@Override
public void sinkEvents(int eventBitsToAdd) {
if (isOrWasAttached()) {
Event.sinkEvents(inputElem,
eventBitsToAdd | Event.getEventsSunk(inputElem));
+ Event.sinkEvents(labelElem,
+ eventBitsToAdd | Event.getEventsSunk(labelElem));
} else {
super.sinkEvents(eventBitsToAdd);
}
Modified:
releases/1.6/user/test/com/google/gwt/user/client/ui/RadioButtonTest.java
==
---
releases/1.6/user/test/com/google/gwt/user/client/ui/RadioButtonTest.java
(original)
+++
releases/1.6/user/test/com/google/gwt/user/client/ui/RadioButtonTest.java
Tue Mar 10 17:16:05 2009
@@ -15,15 +15,28 @@
*/
package com.google.gwt.user.client.ui;
+import com.google.gwt.dom.client.Document;
+import com.google.gwt.dom.client.Element;
+import com.google.gwt.dom.client.InputElement;
+import com.google.gwt.dom.client.LabelElement;
+import com.google.gwt.dom.client.NativeEvent;
+import com.google.gwt.event.logical.shared.ValueChangeEvent;
+import com.google.gwt.event.logical.shared.ValueChangeHandler;
import com.google.gwt.junit.client.GWTTestCase;
import com.google.gwt.user.client.DOM;
-import com.google.gwt.user.client.Element;
/**
* Tests the RadioButton class.
*/
public class RadioButtonTest extends GWTTestCase {
+ private static class Changeable implements ValueChangeHandler {
+Boolean received;
+public void onValueChange(ValueChangeEvent event) {
+ received = event.getValue();
+}
+ }
+
@Override
public String getModuleName() {
return "com.google.gwt.user.DebugTest";
@@ -33,7 +46,7 @@
RadioButton radio = new RadioButton("myName", "myLabel");
// We need to replace the input element so we can keep a handle to it
-Element newInput = DOM.createInputRadio("MyName");
+com.google.gwt.user.client.Element newInput =
DOM.createInputRad
[gwt-contrib] [google-web-toolkit commit] r4977 - releases/1.6/user/src/com/google/gwt/user/tools
Author: sco...@google.com
Date: Tue Mar 10 17:06:05 2009
New Revision: 4977
Modified:
releases/1.6/user/src/com/google/gwt/user/tools/WebAppCreator.java
Log:
Better help message on WebAppCreator's moduleName argument.
Suggested by: bruce
Review by: bruce
Modified: releases/1.6/user/src/com/google/gwt/user/tools/WebAppCreator.java
==
--- releases/1.6/user/src/com/google/gwt/user/tools/WebAppCreator.java
(original)
+++ releases/1.6/user/src/com/google/gwt/user/tools/WebAppCreator.java Tue
Mar 10 17:06:05 2009
@@ -101,7 +101,7 @@
@Override
public String getPurpose() {
- return "The name of the module to create (fully-qualified Java class
name)";
+ return "The name of the module to create (e.g.
com.example.myapp.MyApp)";
}
@Override
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RadioButtons should not fire ValueChange when aleady checked
http://gwt-code-reviews.appspot.com/11801/diff/1/2 File user/src/com/google/gwt/user/client/ui/CheckBox.java (right): http://gwt-code-reviews.appspot.com/11801/diff/1/2#newcode142 Line 142: } Nope, but a nice try. What I actually had to do was extend the override of Widget#sinkEvents to apply to both the checkbox and the label. In fact, if I add an explicit Event.sinkEvents for label after binding the handlers here, it breaks dispatch! On 2009/03/10 20:28:35, jgw wrote: > If you add this line here: > Event.sinkEvents(labelElem, Event.ONMOUSEUP); > testValueChangeViaLabelClick() will work. The problem here (and yet another > reason why I hate CheckBox) is that because it normally sinks events only on > inputElem, is that we're not seeing the mouse-up when you click on labelElem, so > it's not caching the valueBeforeClick field. http://gwt-code-reviews.appspot.com/11801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: testability of static methods
Arthur, One of the things I commonly do when writing "non-GWT-specific" code is to isolate GWT-specific code behind an abstract class or interface and then inject different versions depending on application. One good example is java.text.SimpleDateFormat vs GWT's DateTimeFormat. I have a DateFormatter interface with parse and format methods, and a DateFormatterFactory that makes instances of DateFormatters (from format strings). You can then inject manually (or with something like GIN) versions of DateFormatterFactory, or mocked versions. This may not work for everyone, but in my case, I have to do it, because certain environments (like Android) are very finicky about loading the GWT classes. For example, the Dalvik verifier, upon seeing a method which references the GWT URL class, would try to load it, and even if it were present, it might cause problems due to the native methods, but sometimes you end up with some verification failure far down the execution path because of transitivity (e.g. Foo references URL which references another GWT class, which references another, etc) -Ray On Wed, Feb 18, 2009 at 3:21 PM, Arthur Kalmenson wrote: > > Hello everyone, > > I have a fairly complex class that is almost entirely non-GWT specific > aside from a single line that uses GWT's URL.decodeComponent method. > While I rediscovered GWTMockUtilities and found EasyMock Class > extension, I still can't think of any way to mock out the URL class. > This is because the object is not instantiable (it's final) and it's a > static method call. > > I'm not sure if there's some performance reason behind making it a > final class and using static methods, but it does make testing a pain. > It forces me to use GWTTestCase instead of TestNG to test that > particular class because of the single line of code. > > P.S. Does anyone mind if I write a little guide in the GWT Group about > using GWTMockUtilities with EasyMock? > > -- > Arthur Kalmenson > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: testability of static methods
I was just discussing this on the #gwt IRC channel and tieTYT gave a good suggestion for getting around these static methods. Just create a wrapper class which you can then mock out in a unit test. Sounds like it should work :) > Mind? Heck no! That would be great! Sorry Bruce, being killed by a current project. I'll write something up soon. -- Arthur Kalmenson On Wed, Feb 18, 2009 at 6:34 PM, Bruce Johnson wrote: > Mind? Heck no! That would be great! > On Wed, Feb 18, 2009 at 5:21 PM, Arthur Kalmenson > wrote: >> >> Hello everyone, >> >> I have a fairly complex class that is almost entirely non-GWT specific >> aside from a single line that uses GWT's URL.decodeComponent method. >> While I rediscovered GWTMockUtilities and found EasyMock Class >> extension, I still can't think of any way to mock out the URL class. >> This is because the object is not instantiable (it's final) and it's a >> static method call. >> >> I'm not sure if there's some performance reason behind making it a >> final class and using static methods, but it does make testing a pain. >> It forces me to use GWTTestCase instead of TestNG to test that >> particular class because of the single line of code. >> >> P.S. Does anyone mind if I write a little guide in the GWT Group about >> using GWTMockUtilities with EasyMock? >> >> -- >> Arthur Kalmenson >> >> > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Just what the heck is the "document root", anyway?
Most excellent. I'm building 1.6 right now and will test this with gwt-dnd, using handlers and the new methods. On Tue, Mar 10, 2009 at 11:51 AM, Joel Webber 𐑯(ټ)𐑥 wrote: > Fred, > I just listed you as a reviewer on this code-review thread: > http://gwt-code-reviews.appspot.com/12802 > > Bruce has been reviewing most of the details, but would you mind having a > look to see if these APIs are sufficient to deal with the problems you've > run into in Drag&Drop and GlassPanel? > > Many thanks, > joel. > > On Tue, Mar 10, 2009 at 12:25 PM, Fred Sauer wrote: > >> Joel, >> I like the new proposed methods and I have no issues with the proposed >> enable*Scrolling() methods. >> >> I've never had a need for both document.documentElement and document.body >> at the same time. In fact whenever I've needed one, I *generally* need the >> other when the rendering mode is toggled. That's hardly ever a complete >> picture though. Here are the three ingredients I've found myself needing: >> >>- Need to access document.documentElement or document.body, depending >>on rendering mode >>- Other things also depend on rendering mode so accessing >>$doc.compatMode is still necessary, which also has subtle issues, see >>http://code.google.com/p/google-web-toolkit/issues/detail?id=1981 >>- Cross browser differences as you point out; as part of this also >>older flavors of our supported browsers behaving slightly differently >> >> >> I was just looking at some of the crazy stuff I had to put in GlassPanel. >> Below are a few use cases that pretty much cover my needs. You'll find a >> number of TODOs and weird hacks: >> >> http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplMozilla.java >> >> http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImpl.java >> >> http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplIE6.java >> >> http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplSafari.java >> >> On a side note, I see that the patch that ultimately went in for issues >> 1400 (http://code.google.com/p/google-web-toolkit/issues/detail?id=1400) >> doesn't actually expose "document root" to Java land, which results in the >> necessity to use the violator pattern in >> http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImpl.java >> >> Thanks >> Fred >> >> >> >> On Tue, Mar 10, 2009 at 8:55 AM, Joel Webber 𐑯(ټ)𐑥 wrote: >> >>> I've done a bit more digging, and it looks like "document root" is even >>> less useful than I originally thought. In my research, I missed the fact >>> that all Safari versions report the document's scrollLeft/Top on the >>> element, even in strict mode. So this seems to imply that we *do* need >>> explicit methods on the document for all these operations, because they can >>> be different in subtle ways. So my new proposal is this: >>> Document. >>> get/setScrollLeft/Top() >>> getClientWidth/Height() >>> enableHorizontal/VerticalScrolling() >>> >>> I really don't like the "enable scrolling" method very much, but I can't >>> think of an obvious alternative that doesn't expose a magically-invented >>> "viewport" element that has no standard corollary, and which invites >>> developers to mess with it in ways that will probably just behave oddly. >>> >>> On Tue, Mar 10, 2009 at 10:43 AM, Joel Webber 𐑯(ټ)𐑥 wrote: >>> All, I'm in the process of cleaning up the code in c.g.g.dom that depends upon $doc (which it shouldn't, as this code is all intended to work with multiple documents) and upon DocumentRootImpl (which it *really* shouldn't, for the same reason). This is forcing me to answer the question "just what the heck *is* this document root element, anyway?". The best characterization I can come up with is something like: "the element, which is either document.body or document.documentElement, which you need to use if you want to work with document scrolling, client size (i.e. the window's client area), and the magic 'body offset' on some browsers". It's not a standard DOM element or property, but it's definitely needed. I originally created the method Document.getDocumentRootElement(), but this just feels kind of wrong. The only alternative approach I can think of would be to explicitly define methods such as Document.scrollLeft/Top, Document.clientLeft/Top/Width/Height, and Document.getBodyOffsetLeft/Top() (the last of which already exists). However, this still leaves the element's CSS properties -- so, for example, if you want to turn off document scrolling, you have to set the "document root" element's overflow style. To do this us
[gwt-contrib] Re: GWT Flash components and toggling visibility issue
Ray, Thanks for the help. What you described is kinda the workaround that I was just coding up while I was waiting for my posting to appear. I hadn't planned on keeping all of my state in the GWT, but to get this to work I guess I'll have to go that route. The solution that I'd love to see here would be for the browsers to standardize and adopt one of the Canvas 3D approaches and I can drop the Flash... but I'm not going to hold my breath... Thanks, Darren On Mar 10, 4:01 pm, Ray Cromwell wrote: > You can try looking at my FlashCanvas class > (http://code.google.com/p/gwt-chronoscope/source/browse/trunk/chronosc...) > > Essentially what I do is that on startup of the SWF, I invoke a GWT > callback method. This method setups up some state, and then calls the > SWF and tells it that it's ready as well. What happens if you toggle > display: none? The next time the SWF is loaded, it calls the callback > again, but this time, the GWT code sees that it is not the first time, > so is redraws everything from scratch. > > This approach is only viable if you are keeping most of your state in > GWT code. If you're using Flash as just a 3D renderer, consider it > just like a DirectX/Direct3D surface, which can be "lost" if the user > ALT-TABs your game or application. You detect the loss of rendering > surface, and reupload all the state back. > > I don't really think there's a good solution for this. Sure, you could > change tab panel to use 'visibility: hidden', but there's many other > GWT panels that can't use visibility: hidden, because they need to > resize when components are hidden (e.g. DisclosurePanel, StackPanel, > etc) Then you'd be forcing some kind of hack into all GWT components > to use 'visibility: hidden, width: 0, height: 0, border: 0, padding: > 0, margin: 0' just to hide the Flash component. > > One thing you'll also find that that Flash's ExternalInterface doesn't > like to be deeply nested in HTML on Internet Explorer, so if you place > your object/embed inside of a tag, it will break (see the > fixSWFinIE() function in FlashCanvas). Secondly, putting the > inside of a also breaks ExternalInterface for me on IE6. > > -Ray > > On Tue, Mar 10, 2009 at 10:55 AM, Darren wrote: > > > I have a GWT application that utilizes a Flash/PaperVision3D component > > that I have created. The GWT app places creates instances of the Flash > > component on different tabs in a tab panel. During execution of the > > app, everything works great until the user starts clicking in between > > tabs. At the GWT level, the generated JavaScript is changing the > > style.display attribute to hide and show the contents of the tabs. It > > appears that the Flash component (included in the page by natively > > scripting an 'embed' tag) is reloading/restarting each time that it is > > made visible. > > > How can I prevent it from restarting/reloading? I don't have much > > control at all over the fact that the DIV tag is getting set to > > style.display = 'none', as that is being controlled by the > > autogenerated GWT code, so I can't take the route of playing some > > games of setting transparency or shrinking it down. Is there some > > setting perhaps in the Flex/Flash development to allow it to do this? > > Or maybe in the Embed tag? Or even at the JavaScript level? > > > It seems that a side effect of the unloading/reloading is that the API > > that I export from my Flash component via ExternalInterface is not > > available when the component is not visible. > > > I know there are plenty of GWT Flash based components out there? How > > have you folks solved this problem in those and similar components? > > > Thanks, > > Darren --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RadioButtons should not fire ValueChange when aleady checked
http://gwt-code-reviews.appspot.com/11801/diff/1/2 File user/src/com/google/gwt/user/client/ui/CheckBox.java (right): http://gwt-code-reviews.appspot.com/11801/diff/1/2#newcode142 Line 142: } If you add this line here: Event.sinkEvents(labelElem, Event.ONMOUSEUP); testValueChangeViaLabelClick() will work. The problem here (and yet another reason why I hate CheckBox) is that because it normally sinks events only on inputElem, is that we're not seeing the mouse-up when you click on labelElem, so it's not caching the valueBeforeClick field. http://gwt-code-reviews.appspot.com/11801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4974 - in trunk: dev/core/src/com/google/gwt/dev/jjs/impl user/test/com/google/gwt/dev/jjs/test
Author: sp...@google.com
Date: Tue Mar 10 13:20:06 2009
New Revision: 4974
Modified:
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
trunk/user/test/com/google/gwt/dev/jjs/test/CompilerTest.java
Log:
When adding a bridge method (r4943), set up its override
field to reliably hold the transitive overrides in
addition to the immediate overrides.
Review by: scottb
Modified:
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java Tue
Mar 10 13:20:06 2009
@@ -2111,6 +2111,7 @@
for (JMethod over : overrides) {
if (!classHasMethodOverriding(clazz, over)) {
bridgeMethod.overrides.add(over);
+ bridgeMethod.overrides.addAll(over.overrides);
}
}
}
Modified: trunk/user/test/com/google/gwt/dev/jjs/test/CompilerTest.java
==
--- trunk/user/test/com/google/gwt/dev/jjs/test/CompilerTest.java
(original)
+++ trunk/user/test/com/google/gwt/dev/jjs/test/CompilerTest.java Tue Mar
10 13:20:06 2009
@@ -28,6 +28,12 @@
@SuppressWarnings("unused")
public class CompilerTest extends GWTTestCase {
+ interface Silly { }
+
+ interface SillyComparable extends Comparable {
+int compareTo(T obj);
+ }
+
private abstract static class AbstractSuper {
public static String foo() {
if (FALSE) {
@@ -294,6 +300,25 @@
Bm2KeyNav obs = new Bm2KeyNav() {
};
assertEquals(5, obs.handleEvent(null));
+ }
+
+ /**
+ * When adding a bridge method, be sure to handle transitive overrides
+ * relationships.
+ */
+ public void testBridgeMethods3() {
+class AbstractFoo implements Silly {
+ public int compareTo(AbstractFoo obj) {
+if (FALSE) {
+ return compareTo(obj);
+}
+return 0;
+ }
+}
+class MyFoo extends AbstractFoo implements
SillyComparable {
+}
+
+assertEquals(0, new MyFoo().compareTo(new MyFoo()));
}
public void testCastOptimizer() {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT Flash components and toggling visibility issue
You can try looking at my FlashCanvas class (http://code.google.com/p/gwt-chronoscope/source/browse/trunk/chronoscope/src/main/java/org/timepedia/chronoscope/client/browser/flashcanvas/FlashCanvas.java) Essentially what I do is that on startup of the SWF, I invoke a GWT callback method. This method setups up some state, and then calls the SWF and tells it that it's ready as well. What happens if you toggle display: none? The next time the SWF is loaded, it calls the callback again, but this time, the GWT code sees that it is not the first time, so is redraws everything from scratch. This approach is only viable if you are keeping most of your state in GWT code. If you're using Flash as just a 3D renderer, consider it just like a DirectX/Direct3D surface, which can be "lost" if the user ALT-TABs your game or application. You detect the loss of rendering surface, and reupload all the state back. I don't really think there's a good solution for this. Sure, you could change tab panel to use 'visibility: hidden', but there's many other GWT panels that can't use visibility: hidden, because they need to resize when components are hidden (e.g. DisclosurePanel, StackPanel, etc) Then you'd be forcing some kind of hack into all GWT components to use 'visibility: hidden, width: 0, height: 0, border: 0, padding: 0, margin: 0' just to hide the Flash component. One thing you'll also find that that Flash's ExternalInterface doesn't like to be deeply nested in HTML on Internet Explorer, so if you place your object/embed inside of a tag, it will break (see the fixSWFinIE() function in FlashCanvas). Secondly, putting the inside of a also breaks ExternalInterface for me on IE6. -Ray On Tue, Mar 10, 2009 at 10:55 AM, Darren wrote: > > I have a GWT application that utilizes a Flash/PaperVision3D component > that I have created. The GWT app places creates instances of the Flash > component on different tabs in a tab panel. During execution of the > app, everything works great until the user starts clicking in between > tabs. At the GWT level, the generated JavaScript is changing the > style.display attribute to hide and show the contents of the tabs. It > appears that the Flash component (included in the page by natively > scripting an 'embed' tag) is reloading/restarting each time that it is > made visible. > > How can I prevent it from restarting/reloading? I don't have much > control at all over the fact that the DIV tag is getting set to > style.display = 'none', as that is being controlled by the > autogenerated GWT code, so I can't take the route of playing some > games of setting transparency or shrinking it down. Is there some > setting perhaps in the Flex/Flash development to allow it to do this? > Or maybe in the Embed tag? Or even at the JavaScript level? > > It seems that a side effect of the unloading/reloading is that the API > that I export from my Flash component via ExternalInterface is not > available when the component is not visible. > > I know there are plenty of GWT Flash based components out there? How > have you folks solved this problem in those and similar components? > > Thanks, > Darren > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] GWT Flash components and toggling visibility issue
I have a GWT application that utilizes a Flash/PaperVision3D component that I have created. The GWT app places creates instances of the Flash component on different tabs in a tab panel. During execution of the app, everything works great until the user starts clicking in between tabs. At the GWT level, the generated JavaScript is changing the style.display attribute to hide and show the contents of the tabs. It appears that the Flash component (included in the page by natively scripting an 'embed' tag) is reloading/restarting each time that it is made visible. How can I prevent it from restarting/reloading? I don't have much control at all over the fact that the DIV tag is getting set to style.display = 'none', as that is being controlled by the autogenerated GWT code, so I can't take the route of playing some games of setting transparency or shrinking it down. Is there some setting perhaps in the Flex/Flash development to allow it to do this? Or maybe in the Embed tag? Or even at the JavaScript level? It seems that a side effect of the unloading/reloading is that the API that I export from my Flash component via ExternalInterface is not available when the component is not visible. I know there are plenty of GWT Flash based components out there? How have you folks solved this problem in those and similar components? Thanks, Darren --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Just what the heck is the "document root", anyway?
Fred, I just listed you as a reviewer on this code-review thread: http://gwt-code-reviews.appspot.com/12802 Bruce has been reviewing most of the details, but would you mind having a look to see if these APIs are sufficient to deal with the problems you've run into in Drag&Drop and GlassPanel? Many thanks, joel. On Tue, Mar 10, 2009 at 12:25 PM, Fred Sauer wrote: > Joel, > I like the new proposed methods and I have no issues with the proposed > enable*Scrolling() methods. > > I've never had a need for both document.documentElement and document.body > at the same time. In fact whenever I've needed one, I *generally* need the > other when the rendering mode is toggled. That's hardly ever a complete > picture though. Here are the three ingredients I've found myself needing: > >- Need to access document.documentElement or document.body, depending >on rendering mode >- Other things also depend on rendering mode so accessing >$doc.compatMode is still necessary, which also has subtle issues, see >http://code.google.com/p/google-web-toolkit/issues/detail?id=1981 >- Cross browser differences as you point out; as part of this also >older flavors of our supported browsers behaving slightly differently > > > I was just looking at some of the crazy stuff I had to put in GlassPanel. > Below are a few use cases that pretty much cover my needs. You'll find a > number of TODOs and weird hacks: > > http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplMozilla.java > > http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImpl.java > > http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplIE6.java > > http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplSafari.java > > On a side note, I see that the patch that ultimately went in for issues > 1400 (http://code.google.com/p/google-web-toolkit/issues/detail?id=1400) > doesn't actually expose "document root" to Java land, which results in the > necessity to use the violator pattern in > http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImpl.java > > Thanks > Fred > > > > On Tue, Mar 10, 2009 at 8:55 AM, Joel Webber 𐑯(ټ)𐑥 wrote: > >> I've done a bit more digging, and it looks like "document root" is even >> less useful than I originally thought. In my research, I missed the fact >> that all Safari versions report the document's scrollLeft/Top on the >> element, even in strict mode. So this seems to imply that we *do* need >> explicit methods on the document for all these operations, because they can >> be different in subtle ways. So my new proposal is this: >> Document. >> get/setScrollLeft/Top() >> getClientWidth/Height() >> enableHorizontal/VerticalScrolling() >> >> I really don't like the "enable scrolling" method very much, but I can't >> think of an obvious alternative that doesn't expose a magically-invented >> "viewport" element that has no standard corollary, and which invites >> developers to mess with it in ways that will probably just behave oddly. >> >> On Tue, Mar 10, 2009 at 10:43 AM, Joel Webber 𐑯(ټ)𐑥 wrote: >> >>> All, >>> I'm in the process of cleaning up the code in c.g.g.dom that depends upon >>> $doc (which it shouldn't, as this code is all intended to work with multiple >>> documents) and upon DocumentRootImpl (which it *really* shouldn't, for the >>> same reason). This is forcing me to answer the question "just what the heck >>> *is* this document root element, anyway?". The best characterization I can >>> come up with is something like: >>> >>> "the element, which is either document.body or >>> document.documentElement, which you need to >>> use if you want to work with document scrolling, client size (i.e. the >>> window's client area), and the >>> magic 'body offset' on some browsers". >>> >>> It's not a standard DOM element or property, but it's definitely needed. >>> I originally created the method Document.getDocumentRootElement(), but this >>> just feels kind of wrong. The only alternative approach I can think of would >>> be to explicitly define methods such as Document.scrollLeft/Top, >>> Document.clientLeft/Top/Width/Height, and Document.getBodyOffsetLeft/Top() >>> (the last of which already exists). However, this still leaves the element's >>> CSS properties -- so, for example, if you want to turn off document >>> scrolling, you have to set the "document root" element's overflow style. To >>> do this using the same pattern, I would have to add something ugly like >>> Document.enableScrolling() (like the existing Window.enableScrolling()), or >>> perhaps Document.getStyle() (the former of which feels really weirdly >>> special-cased, and the latter of which feels wrong, because the Document
[gwt-contrib] Re: Just what the heck is the "document root", anyway?
Joel, I like the new proposed methods and I have no issues with the proposed enable*Scrolling() methods. I've never had a need for both document.documentElement and document.body at the same time. In fact whenever I've needed one, I *generally* need the other when the rendering mode is toggled. That's hardly ever a complete picture though. Here are the three ingredients I've found myself needing: - Need to access document.documentElement or document.body, depending on rendering mode - Other things also depend on rendering mode so accessing $doc.compatMode is still necessary, which also has subtle issues, see http://code.google.com/p/google-web-toolkit/issues/detail?id=1981 - Cross browser differences as you point out; as part of this also older flavors of our supported browsers behaving slightly differently I was just looking at some of the crazy stuff I had to put in GlassPanel. Below are a few use cases that pretty much cover my needs. You'll find a number of TODOs and weird hacks: http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplMozilla.java http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImpl.java http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplIE6.java http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImplSafari.java On a side note, I see that the patch that ultimately went in for issues 1400 (http://code.google.com/p/google-web-toolkit/issues/detail?id=1400) doesn't actually expose "document root" to Java land, which results in the necessity to use the violator pattern in http://google-web-toolkit-incubator.googlecode.com/svn/trunk/src/com/google/gwt/widgetideas/client/impl/GlassPanelImpl.java Thanks Fred On Tue, Mar 10, 2009 at 8:55 AM, Joel Webber 𐑯(ټ)𐑥 wrote: > I've done a bit more digging, and it looks like "document root" is even > less useful than I originally thought. In my research, I missed the fact > that all Safari versions report the document's scrollLeft/Top on the > element, even in strict mode. So this seems to imply that we *do* need > explicit methods on the document for all these operations, because they can > be different in subtle ways. So my new proposal is this: > Document. > get/setScrollLeft/Top() > getClientWidth/Height() > enableHorizontal/VerticalScrolling() > > I really don't like the "enable scrolling" method very much, but I can't > think of an obvious alternative that doesn't expose a magically-invented > "viewport" element that has no standard corollary, and which invites > developers to mess with it in ways that will probably just behave oddly. > > On Tue, Mar 10, 2009 at 10:43 AM, Joel Webber 𐑯(ټ)𐑥 wrote: > >> All, >> I'm in the process of cleaning up the code in c.g.g.dom that depends upon >> $doc (which it shouldn't, as this code is all intended to work with multiple >> documents) and upon DocumentRootImpl (which it *really* shouldn't, for the >> same reason). This is forcing me to answer the question "just what the heck >> *is* this document root element, anyway?". The best characterization I can >> come up with is something like: >> >> "the element, which is either document.body or document.documentElement, >> which you need to >> use if you want to work with document scrolling, client size (i.e. the >> window's client area), and the >> magic 'body offset' on some browsers". >> >> It's not a standard DOM element or property, but it's definitely needed. I >> originally created the method Document.getDocumentRootElement(), but this >> just feels kind of wrong. The only alternative approach I can think of would >> be to explicitly define methods such as Document.scrollLeft/Top, >> Document.clientLeft/Top/Width/Height, and Document.getBodyOffsetLeft/Top() >> (the last of which already exists). However, this still leaves the element's >> CSS properties -- so, for example, if you want to turn off document >> scrolling, you have to set the "document root" element's overflow style. To >> do this using the same pattern, I would have to add something ugly like >> Document.enableScrolling() (like the existing Window.enableScrolling()), or >> perhaps Document.getStyle() (the former of which feels really weirdly >> special-cased, and the latter of which feels wrong, because the Document >> object doesn't technically have a style). >> >> One other completely simplifying possibility would be to *only* provide >> document.getDocumentElement(), and simply redefine it to return the >> element in quirks-mode. Does anyone know if the "real" >> document.documentElement serves any purpose in quirks mode? If not, I'm >> inclined to simply redefine it, which would make all these problems go away. >> >> @Fred: I seem to recall discussing some of the ins and outs of this with
[gwt-contrib] [google-web-toolkit commit] r4971 - releases/1.6
Author: sco...@google.com Date: Tue Mar 10 09:29:13 2009 New Revision: 4971 Modified: releases/1.6/branch-info.txt Log: Tweak/normalize branch info log. Modified: releases/1.6/branch-info.txt == --- releases/1.6/branch-info.txt(original) +++ releases/1.6/branch-info.txtTue Mar 10 09:29:13 2009 @@ -23,17 +23,17 @@ /releases/1.6/@r4198:4268 was merged (r4367,r4368) into trunk /releases/1.6/@r4269:4297 was merged (r4367,r4368) into trunk, skipping c4269 (already merged, c4314) /releases/1.6/@r4299:4320 was merged (r4367,r4368) into trunk, skipping c4298, c4299 (already merged, c4314) -/releases/1.6/@r4321:4366 was merged (r4367,r4368) into trunk, skipping c4321 (was a backmerge from trunk) +/releases/1.6/@r4321:4366 was merged (r4367,r4368) into trunk, skipping c4321 (backmerge from trunk) /releases/1.6/@r4366:4385 was merged (r4386) into trunk /releases/1.6/@r4385:4459 was merged (r4488) into trunk /releases/1.6/@r4359:4490 was merged (r4491) into trunk -/releases/1.6/@c4498 was merged (r4499) into trunk +/releases/1.6/@c4498 was merged (r4499) into trunk (cherry pick) /releases/1.6/@r4490:4497,4498:4511 was merged (r4512) into trunk, skipping c4498 (cherry picked above) -/tr...@c4603 was merged (r4605) into /releases/1.6 -/releases/1.6/@r4511:4604,4605:4657 was merged (r4659) into trunk, skipping c4605 (cherry picked above) +/trunk revision c4603 was merged (r4605) into this branch +/releases/1.6/@r4511:4604,4605:4657 was merged (r4659) into trunk, skipping c4605 (backmerge from trunk) /releases/1.6/@r4657:4658 was merged (r4662) into trunk /releases/1.6/@r4658:4669 was merged (r4670) into trunk -/tr...@c4873 was merged (r4878) into /releases/1.6 +/trunk revision c4873 was merged (r4878) into this branch /trunk revision c4889 was merged (r4892) into this branch /releases/1.6/@r4669:4694 was merged (r4919) into trunk /releases/1.6/@r4695:4874 was merged (r4919) into trunk, skipping c4695 (1.6-only change) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4972 - releases/1.6
Author: sco...@google.com Date: Tue Mar 10 09:29:57 2009 New Revision: 4972 Modified: releases/1.6/branch-info.txt Log: Recording cherry-pick of c4963 into trunk. Modified: releases/1.6/branch-info.txt == --- releases/1.6/branch-info.txt(original) +++ releases/1.6/branch-info.txtTue Mar 10 09:29:57 2009 @@ -38,8 +38,10 @@ /releases/1.6/@r4669:4694 was merged (r4919) into trunk /releases/1.6/@r4695:4874 was merged (r4919) into trunk, skipping c4695 (1.6-only change) /releases/1.6/@r4875:4877 was merged (r4919) into trunk, skipping c4875 (different trunk change) -/releases/1.6/@r4878:4891 was merged (r4919) into trunk, skipping c4878 (cherry picked above) -/releases/1.6/@r4892:4911 was merged (r4919) into trunk, skipping c4892 (cherry picked above) +/releases/1.6/@r4878:4891 was merged (r4919) into trunk, skipping c4878 (backmerge from trunk) +/releases/1.6/@r4892:4911 was merged (r4919) into trunk, skipping c4892 (backmerge from trunk) +/releases/1.6/@c4963 was merged (r4970 into trunk (cherry pick) -The next merge into trunk will be: -svn merge -r4911: https://google-web-toolkit.googlecode.com/svn/releases/1.6 . +The next merge into trunk will be (skipping c4963: +svn merge -r4911:4962 https://google-web-toolkit.googlecode.com/svn/releases/1.6 . +svn merge -r4963: https://google-web-toolkit.googlecode.com/svn/releases/1.6 . --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4973 - trunk/user/test/com/google/gwt/user/client/rpc
Author: sco...@google.com
Date: Tue Mar 10 09:57:45 2009
New Revision: 4973
Modified:
trunk/user/test/com/google/gwt/user/client/rpc/InheritanceTest.java
Log:
Adds a new test to verify that a client SerializationException prevents a
server invocation.
Review by: bruce (desk)
Modified:
trunk/user/test/com/google/gwt/user/client/rpc/InheritanceTest.java
==
--- trunk/user/test/com/google/gwt/user/client/rpc/InheritanceTest.java
(original)
+++ trunk/user/test/com/google/gwt/user/client/rpc/InheritanceTest.java Tue
Mar 10 09:57:45 2009
@@ -17,6 +17,7 @@
import com.google.gwt.core.client.GWT;
import com.google.gwt.junit.client.GWTTestCase;
+import com.google.gwt.user.client.Timer;
import
com.google.gwt.user.client.rpc.InheritanceTestSetFactory.AnonymousClassInterface;
import com.google.gwt.user.client.rpc.InheritanceTestSetFactory.Circle;
import
com.google.gwt.user.client.rpc.InheritanceTestSetFactory.SerializableClass;
@@ -174,6 +175,37 @@
finishTest();
}
});
+ }
+
+ public void testSerializationExceptionPreventsCall() {
+final boolean serializationExceptionCaught[] = new boolean[1];
+new Timer() {
+ @Override
+ public void run() {
+assertTrue("serializationExceptionCaught was not true",
+serializationExceptionCaught[0]);
+finishTest();
+ }
+}.schedule(TEST_DELAY / 2);
+delayTestFinish(TEST_DELAY);
+
+InheritanceTestServiceAsync service = getServiceAsync();
+service.echo(new AnonymousClassInterface() {
+ public void foo() {
+// purposely empty
+ }
+}, new AsyncCallback() {
+ public void onFailure(Throwable caught) {
+assertTrue(
+"onFailure: got something other than a SerializationException",
+caught instanceof SerializationException);
+serializationExceptionCaught[0] = true;
+ }
+
+ public void onSuccess(Object result) {
+fail("onSuccess: call should not have succeeded");
+ }
+});
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4970 - in trunk: . user/src/com/google/gwt/user/rebind/rpc
Author: sco...@google.com
Date: Tue Mar 10 09:25:10 2009
New Revision: 4970
Modified:
trunk/ (props changed)
trunk/user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java
Log:
Cherry-pick merging /releases/1.6 c4963 into trunk.
svn merge -c4963 https://google-web-toolkit.googlecode.com/svn/releases/1.6
Modified: trunk/user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java
==
--- trunk/user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java
(original)
+++ trunk/user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java Tue Mar
10 09:25:10 2009
@@ -445,21 +445,6 @@
w.println("(" + asyncParam.getName() + ");");
}
-JParameter callbackParam = asyncParams[asyncParams.length - 1];
-String callbackName = callbackParam.getName();
-if (needsTryCatchBlock) {
- w.outdent();
- w.print("} catch (SerializationException ");
- String exceptionName = nameFactory.createName("ex");
- w.println(exceptionName + ") {");
- w.indent();
- w.println(callbackName + ".onFailure(" + exceptionName + ");");
- w.outdent();
- w.println("}");
-}
-
-w.println();
-
String payloadName = nameFactory.createName("payload");
w.println("String " + payloadName + " = " + streamWriterName
+ ".toString();");
@@ -486,11 +471,24 @@
+ asyncReturnType.getQualifiedSourceName());
}
+JParameter callbackParam = asyncParams[asyncParams.length - 1];
+String callbackName = callbackParam.getName();
JType returnType = syncMethod.getReturnType();
w.print("ResponseReader." + getResponseReaderFor(returnType).name());
w.println(", \"" + getProxySimpleName() + "." + syncMethod.getName()
+ "\", " + requestIdName + ", " + payloadName + ", " + callbackName
+ ");");
+
+if (needsTryCatchBlock) {
+ w.outdent();
+ w.print("} catch (SerializationException ");
+ String exceptionName = nameFactory.createName("ex");
+ w.println(exceptionName + ") {");
+ w.indent();
+ w.println(callbackName + ".onFailure(" + exceptionName + ");");
+ w.outdent();
+ w.println("}");
+}
w.outdent();
w.println("}");
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4969 - in changes/bobv/rpc_request_builder/user/src/com/google/gwt/user: client/rpc client/rpc/i...
Author: b...@google.com
Date: Tue Mar 10 09:06:00 2009
New Revision: 4969
Added:
changes/bobv/rpc_request_builder/user/src/com/google/gwt/user/client/rpc/RpcRequestBuilder.java
(contents, props changed)
Modified:
changes/bobv/rpc_request_builder/user/src/com/google/gwt/user/client/rpc/ServiceDefTarget.java
changes/bobv/rpc_request_builder/user/src/com/google/gwt/user/client/rpc/impl/RemoteServiceProxy.java
changes/bobv/rpc_request_builder/user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java
Log:
Add the RpcRequestBuilder type to clearly enumerate the API requirements
that RemoteServiceProxy has and to allow for arbitrary configuration of the
HTTP request.
Added:
changes/bobv/rpc_request_builder/user/src/com/google/gwt/user/client/rpc/RpcRequestBuilder.java
==
--- (empty file)
+++
changes/bobv/rpc_request_builder/user/src/com/google/gwt/user/client/rpc/RpcRequestBuilder.java
Tue Mar 10 09:06:00 2009
@@ -0,0 +1,212 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+package com.google.gwt.user.client.rpc;
+
+import com.google.gwt.core.client.GWT;
+import com.google.gwt.http.client.RequestBuilder;
+import com.google.gwt.http.client.RequestCallback;
+
+/**
+ * This class encapsulates the logic necessary to configure a
RequestBuilder for
+ * use with an RPC proxy object. Users who wish to alter the specifics of
the
+ * HTTP requests issued by RPC proxy objects may override the protected
+ * doXyz methods and pass an instance of the subclass to
+ * {...@link ServiceDefTarget#setRpcRequestBuilder}.
+ */
+public class RpcRequestBuilder {
+ /**
+ * Used by {...@link #doSetContentType}.
+ */
+ public static final String CONTENT_TYPE_HEADER = "Content-Type";
+
+ /**
+ * Used by {...@link #doFinish}.
+ */
+ /*
+ * NB: Keep in sync with RemoteServiceServlet.
+ */
+ public static final String STRONG_NAME_HEADER = "X-GWT-Permutation";
+
+ /**
+ * Not exposed directly to the subclass.
+ */
+ private RequestBuilder builder;
+
+ /**
+ * Initialize the RpcRequestBuilder. This method must be called before
any of
+ * the other methods in this class may be called. Calling
create
+ * before calling {...@link #finish()} will reset the state of the
+ * RpcRequestBuilder.
+ *
+ * This method delegates to {...@link #doCreate} to instantiate the
+ * RequestBuilder.
+ *
+ * @param serviceEntryPoint The URL entry point
+ * @return this
+ * @see ServiceDefTarget#setServiceEntryPoint(String)
+ */
+ public final RpcRequestBuilder create(String serviceEntryPoint) {
+builder = doCreate(serviceEntryPoint);
+assert builder != null : "doCreate failed to return a RequestBuilder";
+return this;
+ }
+
+ /**
+ * This method must be called to return the RequestBuilder that the RPC
+ * request will be made with.
+ *
+ * This method will call {...@link #doFinish} before returning the current
+ * RequestBuilder.
+ */
+ public final RequestBuilder finish() {
+try {
+ assert builder != null : "Call create() first";
+ doFinish(builder);
+ return builder;
+} finally {
+ builder = null;
+}
+ }
+
+ /**
+ * Sets the RequestCallback to be used by the RequestBuilder. Delegates
to
+ * {...@link #doSetCallback}.
+ *
+ * @param callback the RequestCallback to be used by the RequestBuilder
+ * @return this
+ */
+ public final RpcRequestBuilder setCallback(RequestCallback callback) {
+assert builder != null : "Call create() first";
+doSetCallback(builder, callback);
+return this;
+ }
+
+ /**
+ * Sets the MIME content type to be used by the RequestBuilder.
Delegates to
+ * {...@link #doSetContentType}.
+ *
+ * @param contentType the MIME content type to be used in the request
+ * @return this
+ */
+ public final RpcRequestBuilder setContentType(String contentType) {
+assert builder != null : "Call create() first";
+doSetContentType(builder, contentType);
+return this;
+ }
+
+ /**
+ * Sets the request data to be sent in the request. Delegates to
+ * {...@link #doSetRequestData}.
+ *
+ * @param data the data to send
+ * @return this
+ */
+ public final RpcRequestBuilder setRequestData(String data) {
+assert builder != null : "Call create() first";
+doSetRequestData(builder, data);
+
[gwt-contrib] [google-web-toolkit commit] r4968 - changes/bobv/rpc_request_builder
Author: b...@google.com Date: Tue Mar 10 09:01:29 2009 New Revision: 4968 Added: changes/bobv/rpc_request_builder/ (props changed) - copied from r4963, /trunk/ Log: Create a change branch to play with an API to allow arbitrary configuration of RPC request builders. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Review: update oophm .classpath
Hi John, I wanted to bring the oophm classpath file up to date against the other gwt-dev's. I wasn't sure if there was a particular reason for exporting everything, or for having Xerces in there. Thanks, Scott --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- oophm-cp.patch Description: Binary data
[gwt-contrib] Re: Just what the heck is the "document root", anyway?
I like this new formulation; it's probably a lot safer to denormalize like this. On Tue, Mar 10, 2009 at 11:55 AM, Joel Webber 𐑯(ټ)𐑥 wrote: > I've done a bit more digging, and it looks like "document root" is even > less useful than I originally thought. In my research, I missed the fact > that all Safari versions report the document's scrollLeft/Top on the > element, even in strict mode. So this seems to imply that we *do* need > explicit methods on the document for all these operations, because they can > be different in subtle ways. So my new proposal is this: > Document. > get/setScrollLeft/Top() > getClientWidth/Height() > enableHorizontal/VerticalScrolling() > > I really don't like the "enable scrolling" method very much, but I can't > think of an obvious alternative that doesn't expose a magically-invented > "viewport" element that has no standard corollary, and which invites > developers to mess with it in ways that will probably just behave oddly. > > On Tue, Mar 10, 2009 at 10:43 AM, Joel Webber 𐑯(ټ)𐑥 wrote: > >> All, >> I'm in the process of cleaning up the code in c.g.g.dom that depends upon >> $doc (which it shouldn't, as this code is all intended to work with multiple >> documents) and upon DocumentRootImpl (which it *really* shouldn't, for the >> same reason). This is forcing me to answer the question "just what the heck >> *is* this document root element, anyway?". The best characterization I can >> come up with is something like: >> >> "the element, which is either document.body or document.documentElement, >> which you need to >> use if you want to work with document scrolling, client size (i.e. the >> window's client area), and the >> magic 'body offset' on some browsers". >> >> It's not a standard DOM element or property, but it's definitely needed. I >> originally created the method Document.getDocumentRootElement(), but this >> just feels kind of wrong. The only alternative approach I can think of would >> be to explicitly define methods such as Document.scrollLeft/Top, >> Document.clientLeft/Top/Width/Height, and Document.getBodyOffsetLeft/Top() >> (the last of which already exists). However, this still leaves the element's >> CSS properties -- so, for example, if you want to turn off document >> scrolling, you have to set the "document root" element's overflow style. To >> do this using the same pattern, I would have to add something ugly like >> Document.enableScrolling() (like the existing Window.enableScrolling()), or >> perhaps Document.getStyle() (the former of which feels really weirdly >> special-cased, and the latter of which feels wrong, because the Document >> object doesn't technically have a style). >> >> One other completely simplifying possibility would be to *only* provide >> document.getDocumentElement(), and simply redefine it to return the >> element in quirks-mode. Does anyone know if the "real" >> document.documentElement serves any purpose in quirks mode? If not, I'm >> inclined to simply redefine it, which would make all these problems go away. >> >> @Fred: I seem to recall discussing some of the ins and outs of this with >> you in the past. Any opinions? >> >> Thanks, >> joel. >> > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Just what the heck is the "document root", anyway?
I've done a bit more digging, and it looks like "document root" is even less useful than I originally thought. In my research, I missed the fact that all Safari versions report the document's scrollLeft/Top on the element, even in strict mode. So this seems to imply that we *do* need explicit methods on the document for all these operations, because they can be different in subtle ways. So my new proposal is this: Document. get/setScrollLeft/Top() getClientWidth/Height() enableHorizontal/VerticalScrolling() I really don't like the "enable scrolling" method very much, but I can't think of an obvious alternative that doesn't expose a magically-invented "viewport" element that has no standard corollary, and which invites developers to mess with it in ways that will probably just behave oddly. On Tue, Mar 10, 2009 at 10:43 AM, Joel Webber 𐑯(ټ)𐑥 wrote: > All, > I'm in the process of cleaning up the code in c.g.g.dom that depends upon > $doc (which it shouldn't, as this code is all intended to work with multiple > documents) and upon DocumentRootImpl (which it *really* shouldn't, for the > same reason). This is forcing me to answer the question "just what the heck > *is* this document root element, anyway?". The best characterization I can > come up with is something like: > > "the element, which is either document.body or document.documentElement, > which you need to > use if you want to work with document scrolling, client size (i.e. the > window's client area), and the > magic 'body offset' on some browsers". > > It's not a standard DOM element or property, but it's definitely needed. I > originally created the method Document.getDocumentRootElement(), but this > just feels kind of wrong. The only alternative approach I can think of would > be to explicitly define methods such as Document.scrollLeft/Top, > Document.clientLeft/Top/Width/Height, and Document.getBodyOffsetLeft/Top() > (the last of which already exists). However, this still leaves the element's > CSS properties -- so, for example, if you want to turn off document > scrolling, you have to set the "document root" element's overflow style. To > do this using the same pattern, I would have to add something ugly like > Document.enableScrolling() (like the existing Window.enableScrolling()), or > perhaps Document.getStyle() (the former of which feels really weirdly > special-cased, and the latter of which feels wrong, because the Document > object doesn't technically have a style). > > One other completely simplifying possibility would be to *only* provide > document.getDocumentElement(), and simply redefine it to return the > element in quirks-mode. Does anyone know if the "real" > document.documentElement serves any purpose in quirks mode? If not, I'm > inclined to simply redefine it, which would make all these problems go away. > > @Fred: I seem to recall discussing some of the ins and outs of this with > you in the past. Any opinions? > > Thanks, > joel. > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4967 - releases/1.6/user/src/com/google/gwt/user/tools
Author: sco...@google.com
Date: Tue Mar 10 08:41:08 2009
New Revision: 4967
Modified:
releases/1.6/user/src/com/google/gwt/user/tools/RpcServerTemplate.javasrc
Log:
Remove serialization UID warning from generated webAppCreator project.
Suggested by: mmendez
Review by: bruce (desk)
Modified:
releases/1.6/user/src/com/google/gwt/user/tools/RpcServerTemplate.javasrc
==
---
releases/1.6/user/src/com/google/gwt/user/tools/RpcServerTemplate.javasrc
(original)
+++
releases/1.6/user/src/com/google/gwt/user/tools/RpcServerTemplate.javasrc
Tue Mar 10 08:41:08 2009
@@ -6,6 +6,7 @@
/**
* The server side implementation of the RPC service.
*/
+...@suppresswarnings("serial")
public class GreetingServiceImpl extends RemoteServiceServlet implements
GreetingService {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4966 - changes/spoon/soyc-withdeps
Author: sp...@google.com Date: Tue Mar 10 08:26:31 2009 New Revision: 4966 Added: changes/spoon/soyc-withdeps/branch-info.txt (contents, props changed) Log: Adding a branch-info.txt file to this changes branch. Added: changes/spoon/soyc-withdeps/branch-info.txt == --- (empty file) +++ changes/spoon/soyc-withdeps/branch-info.txt Tue Mar 10 08:26:31 2009 @@ -0,0 +1,9 @@ +Initial copy from trunk: + +(r4965) +svn cp https://google-web-toolkit.googlecode.com/svn/tr...@4693 https://google-web-toolkit.googlecode.com/svn/changes/spoon/soyc-withdeps + + +To merge back into a working copy of the trunk: + +svn merge -r4966:??? https://google-web-toolkit.googlecode.com/svn/changes/spoon/soyc-withdeps . --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4965 - changes/spoon/soyc-withdeps
Author: sp...@google.com Date: Tue Mar 10 08:18:43 2009 New Revision: 4965 Added: changes/spoon/soyc-withdeps/ (props changed) - copied from r4693, /trunk/ Log: Making a changes branch for kprobst's extension to SOYC to report code-splitting dependencies. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4964 - changes/spoon/soyc-withdeps
Author: sp...@google.com Date: Tue Mar 10 08:17:22 2009 New Revision: 4964 Removed: changes/spoon/soyc-withdeps/ Log: Removing a stale changes branch. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Just what the heck is the "document root", anyway?
All, I'm in the process of cleaning up the code in c.g.g.dom that depends upon $doc (which it shouldn't, as this code is all intended to work with multiple documents) and upon DocumentRootImpl (which it *really* shouldn't, for the same reason). This is forcing me to answer the question "just what the heck *is* this document root element, anyway?". The best characterization I can come up with is something like: "the element, which is either document.body or document.documentElement, which you need to use if you want to work with document scrolling, client size (i.e. the window's client area), and the magic 'body offset' on some browsers". It's not a standard DOM element or property, but it's definitely needed. I originally created the method Document.getDocumentRootElement(), but this just feels kind of wrong. The only alternative approach I can think of would be to explicitly define methods such as Document.scrollLeft/Top, Document.clientLeft/Top/Width/Height, and Document.getBodyOffsetLeft/Top() (the last of which already exists). However, this still leaves the element's CSS properties -- so, for example, if you want to turn off document scrolling, you have to set the "document root" element's overflow style. To do this using the same pattern, I would have to add something ugly like Document.enableScrolling() (like the existing Window.enableScrolling()), or perhaps Document.getStyle() (the former of which feels really weirdly special-cased, and the latter of which feels wrong, because the Document object doesn't technically have a style). One other completely simplifying possibility would be to *only* provide document.getDocumentElement(), and simply redefine it to return the element in quirks-mode. Does anyone know if the "real" document.documentElement serves any purpose in quirks mode? If not, I'm inclined to simply redefine it, which would make all these problems go away. @Fred: I seem to recall discussing some of the ins and outs of this with you in the past. Any opinions? Thanks, joel. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] DatePicker extensibility ?
Hi,
I'm trying to customize DatPicker for custom use-cases.
I had to use some visibility hacks using new classes declared in
package com.google.gwt.user.datepicker.client to access some package-visible
types and methods.
Is there any reason the DatePicker is so ... package restricted ? This makes
customisation very difficult :
CalendarUtil.isWeekend is not public. Why ?
DatePicker.StandardCss is not a public class, and DatePickerComponent.css()
is only package visible. This makes creating custom DatePickerComponent
difficult as we can't reuse the DatePicker defined CSS styles names.
CalendarView may at least provide delegate methods to access day-related
style :
public String dayIsValueAndHighlighted()
{
return css().dayIsValueAndHighlighted();
}
CellGridImpl is package visible. I can understand the doc about
DefaultCalendarView not beeing extensible to allow free changes in future,
but maybe the Grid implmentation could be made public for reuse ?
Cheers,
Nicolas
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Jetty resources encoding
I'm not used to configure Jetty, but maybe the web-jetty.xml file can be used to set the default Content-type header charset to use ? Nicolas On Mon, Mar 9, 2009 at 6:22 PM, John Tamplin wrote: > On Mon, Mar 9, 2009 at 12:39 PM, nicolas de loof > wrote: > >> As you can see, the Jetty server does not specify any encoding in the >> content-type header, so I suppose my browser is using the platform native >> one : Windows CP1252 >> > > I believe HTTP specifies that the default is ISO-Latin-8859-1 if no charset > is specified. > > >> Is there any simple way to force Jetty to include such encoding header ? >> As GWT resources are required AFAIK to be UTF-8, what about this to be the >> default configuration for hosted mode server ? >> > > GWT resources are required to be UTF8, but that doesn't mean that all your > web-served content has to be. Ideally, it would user configurable, but I > think once you start to need to mix encodings you need to run your own > server and use -noserver. So, I would be happy with UTF8 as a default, > preferably with a way to override it for all served content. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
