[gwt-contrib] Re: weak listener in GWT?
Another option to assist with mass one step removal is to add said listeners to a container class that also implements the listener. Then add the listener to the widget. To remove all listeners in one operation simply remove the container. This and similar types of organisation do not require changes to widgets but rather benefit from other strategies. Hth On 07/04/2009, at 5:00 AM, Ed wrote: > > The solution that I suggest above, seem to work fine. > > BTW: I also had another look at the solution suggested by MiroSlav, > but that is a technical soution that isn't correct in my case. His > solution was to remove the global model listeners when the widget got > detached. However, I can easily detach a widget/panel from one form > and connect it to another form, which in my case is completely legal, > but will result in correct behavior as the listeners are removed :(. > So I solved it in a functional way by adding listeners to my Form > Fields that are informed about form field removal/insertions. These > listeners are added to the Form Field. > I also have a Form listener that receives these kind of notifications, > but couldn't be used in the form field builder as Form isn't know > there, where as the Form field is. > > I hope it's of some use to others. > > -- Ed > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: FastTree Focus Issue
It looks like the movable focus element was previously placed relative to
the outer element of FastTree and is now placed relative to the document
body. However, the movable element is physically within the FastTree, so
there is no way to know what its offset parent will be unless we force it to
be the FastTree. I think we need to make the FastTree have position
relative, and then position the movable element relative to it. In fact, I
wonder if doing so wouldn't fix the jumpiness issues.
The "top" position of an element is always relative to its offset parent,
which is usually the first parent with a position attribute set to relative
or absolute. Since you can't assume the user's layout, the only safe option
is to set the position attribute of an element that the widget controls,
such as its outer element.
Thanks,
John LaBanca
jlaba...@google.com
On Mon, Apr 6, 2009 at 8:37 PM, wrote:
> Reviewers: jlabanca, minz,
>
> Description:
> There was a focus issue with the fasttree when the size of the tree was
> larger than the viewport, this was especially manifested with very large
> trees.
>
> Please review this at http://gwt-code-reviews.appspot.com/18801
>
> Affected files:
> com/google/gwt/gen2/complexpanel/client/FastTree.java
>
>
> Index: com/google/gwt/gen2/complexpanel/client/FastTree.java
> ===
> --- com/google/gwt/gen2/complexpanel/client/FastTree.java (revision
> 1594)
> +++ com/google/gwt/gen2/complexpanel/client/FastTree.java (working
> copy)
> @@ -53,6 +53,7 @@
> import com.google.gwt.user.client.DOM;
> import com.google.gwt.user.client.Element;
> import com.google.gwt.user.client.Event;
> +import com.google.gwt.user.client.Window;
> import com.google.gwt.user.client.ui.Accessibility;
> import com.google.gwt.user.client.ui.Focusable;
> import com.google.gwt.user.client.ui.Panel;
> @@ -849,15 +850,26 @@
> }
>
> private void moveElementOverTarget(Element movable, Element target) {
> -int containerTop = getAbsoluteTop();
> -
> -int top = DOM.getAbsoluteTop(target) - containerTop;
> +int top = DOM.getAbsoluteTop(target);
> int height = DOM.getElementPropertyInt(target, "offsetHeight");
> +int left = DOM.getAbsoluteLeft(target) + getAbsoluteLeft();
> +int width = DOM.getElementPropertyInt(target, "offsetWidth");
> +
> +int maxBottom = Window.getScrollTop() + Window.getClientHeight();
>
> +if (top + target.getOffsetHeight() > maxBottom) {
> + top = maxBottom - target.getOffsetHeight();
> +}
> +
> // Set the element's position and size to exactly underlap the
> // item's content element.
> DOM.setStyleAttribute(movable, "height", height + "px");
> -DOM.setStyleAttribute(movable, "top", top + "px");
> +
> +if (top > 0) {
> + DOM.setStyleAttribute(movable, "top", top + "px");
> +}
> +DOM.setStyleAttribute(movable, "left", left + "px");
> +DOM.setStyleAttribute(movable, "width", width + "px");
> }
>
> /**
>
>
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: review request: clean up the RPC compile-time noise
Thanks, Lex! On Tue, Apr 7, 2009 at 8:01 AM, Lex Spoon wrote: > This is a big improvement on the logging. I really like the > gist of it. I think it should have a second iteration, though. > > I reluctantly agree about dropping most all warnings. Once we have a > way to suppress warnings, then we can talk about how to put them back > in. > The big thing here was the "expected" warnings, for example from the nonserializable subtypes of list. I wanted to differentiate user from non-user code (which may be a suppression regexp, for example), but deferred that for now. > The main thing is that many problems are still logged via TreeLogger > and not stored in the ProblemReport. Shouldn't we jump over > consistently to the new system rather than have a mix? Are there any Probably; I was worried that I might lose something valuable (for example, if we put a log message in ProblemReport and then drop it as above). That shouldn't be an issue if we're selective about which TreeLogger logs migrate; I just wanted to get the focal thing working first. Happy to do a second revision. > Also, the new "visited" field is redundant with the typeToTyeInfoComputed > map. > It looks like you ran into some recursion issue somewhere. We should > fix that problem by improving the existing short-circuiting via TICs, not > by adding a new and subtly different field. > Yeah, I suspected this would come up. I'll take a closer look at using TIC instead. There's no special recursion I had to provoke; if you put logging in instead of my short circuit, I think DynaTable reconsiders java.lang.String something like 23 times before reaching TIC shortcircuits. My patch saved almost 10% time for DynaTable, I think due to this earlier shortcircuit. (Sorry, should have bragged on that in the first posting.) > Error message content: > > I have not looked at the output carefully, but it looks like we are > losing dependency information between types. This could be improved > greatly by adding link-up messages to any type that fails due to a > separate type from failing. In particular: > > 1. In checkSubtypes(), add a problem for each candidate that is > rejected. For example, "tried subtype Foo but it was not > instantiable". > This one I think we don't lose, because of the context in the ProblemReport. We get messages like "com.foocorp.SubFoo had no default instructor (reached via com.foocorp.Foo)". The complete chain of subtypes, yes, you'd need debug logging to see. > 2. In checkSubtype(), log messages for recursing to a supertype and > recursing into a field's type. For example, "superclass Foo is not > instantiable". "Field x of type Foo is not instantiable". > You similarly get the context type from your actual interface here, but yes, in these cases it might be more confusing how you got from here to there. > It would greatly help if the report sorted the types by their fully > qualified name. > Ok. Nits: > > To simplify the code and help with future developments, the errors > could be stored in the TIC class instead of in ProblemReport. Simply > add a field "List problems". The two static methods that take > a ProblemReport as an argument could instead take a List as an > argument. The general rule is that TIC holds the information STOB > deduces about a particular type. Surely it will work well to log > the errors there directly. > The reason I was hesitant here was memory pressure... I wasn't sure how long-lived the STOB and TIC info was (yes, I should have worked it out). The purpose to ProblemReport is to become garbage relatively quickly. > You should delete > it, revive it, and delete it again, and then upload the video to > YouTube. I never taunt dead code, for fear it will come back to haunt me... --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] FastTree Focus Issue
Reviewers: jlabanca, minz,
Description:
There was a focus issue with the fasttree when the size of the tree was
larger than the viewport, this was especially manifested with very large
trees.
Please review this at http://gwt-code-reviews.appspot.com/18801
Affected files:
com/google/gwt/gen2/complexpanel/client/FastTree.java
Index: com/google/gwt/gen2/complexpanel/client/FastTree.java
===
--- com/google/gwt/gen2/complexpanel/client/FastTree.java (revision 1594)
+++ com/google/gwt/gen2/complexpanel/client/FastTree.java (working copy)
@@ -53,6 +53,7 @@
import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.Event;
+import com.google.gwt.user.client.Window;
import com.google.gwt.user.client.ui.Accessibility;
import com.google.gwt.user.client.ui.Focusable;
import com.google.gwt.user.client.ui.Panel;
@@ -849,15 +850,26 @@
}
private void moveElementOverTarget(Element movable, Element target) {
-int containerTop = getAbsoluteTop();
-
-int top = DOM.getAbsoluteTop(target) - containerTop;
+int top = DOM.getAbsoluteTop(target);
int height = DOM.getElementPropertyInt(target, "offsetHeight");
+int left = DOM.getAbsoluteLeft(target) + getAbsoluteLeft();
+int width = DOM.getElementPropertyInt(target, "offsetWidth");
+
+int maxBottom = Window.getScrollTop() + Window.getClientHeight();
+if (top + target.getOffsetHeight() > maxBottom) {
+ top = maxBottom - target.getOffsetHeight();
+}
+
// Set the element's position and size to exactly underlap the
// item's content element.
DOM.setStyleAttribute(movable, "height", height + "px");
-DOM.setStyleAttribute(movable, "top", top + "px");
+
+if (top > 0) {
+ DOM.setStyleAttribute(movable, "top", top + "px");
+}
+DOM.setStyleAttribute(movable, "left", left + "px");
+DOM.setStyleAttribute(movable, "width", width + "px");
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: new test which demonstrates the infinite recursion bug
Right ... Stupid me. I knew I was missing something obvious.
On Mon, Apr 6, 2009 at 8:08 PM, Ray Cromwell wrote:
>
> callSuper() is private, so B's invocation is not polymorphic, and should
> not reference C's callSuper()
>
>
> On Mon, Apr 6, 2009 at 4:50 PM, Vitali Lovich wrote:
>
>>
>>
>> On Mon, Apr 6, 2009 at 7:13 PM, John Tamplin wrote:
>>
>>> The attached patch, relative to trunk r5191, adds a new tests which fails
>>> only in web mode and only for the JsniSuper case. It appears the problem
>>> isn't directly related to super, but rather with making calls to private
>>> methods polymorphic rather than virtual dispatch. This is the bug I ran
>>> into with the CurrencyListGenerator changes I committed and then had to roll
>>> back.
>>>
>>> Ie:
>>>
>>> public class A {
>>> public void foo() {}
>>> }
>>>
>>> public class B extends A {
>>> public void foo() { callSuper(); }
>>> private void callSuper() { super.foo(); }
>>> }
>>>
>>> public class C extends B {
>>> public void foo() { callSuper(); }
>>> private void callSuper() { super.foo(); }
>>> }
>>>
>>> B's foo will always call B's callSuper, even when this is actually a C.
>>> We handle this properly for Java code, but not when foo is a JSNI
>>> method.
>>
>> Woudn't this cause infinite recursion when this is actually a C & using
>> virtual dispatch?
>>
>> c.foo -> c.callSuper -> b.foo -> c.callSuper -> b.foo -> c.callSuper etc.
>>
>> If it's a polymorphic call, I believe the call graph looks like:
>> c.foo -> c.callSuper -> b.foo -> b.callSuper -> a.foo
>>
>>>
>>>
>>> --
>>> John A. Tamplin
>>> Software Engineer (GWT), Google
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: new test which demonstrates the infinite recursion bug
callSuper() is private, so B's invocation is not polymorphic, and should not
reference C's callSuper()
On Mon, Apr 6, 2009 at 4:50 PM, Vitali Lovich wrote:
>
>
> On Mon, Apr 6, 2009 at 7:13 PM, John Tamplin wrote:
>
>> The attached patch, relative to trunk r5191, adds a new tests which fails
>> only in web mode and only for the JsniSuper case. It appears the problem
>> isn't directly related to super, but rather with making calls to private
>> methods polymorphic rather than virtual dispatch. This is the bug I ran
>> into with the CurrencyListGenerator changes I committed and then had to roll
>> back.
>>
>> Ie:
>>
>> public class A {
>> public void foo() {}
>> }
>>
>> public class B extends A {
>> public void foo() { callSuper(); }
>> private void callSuper() { super.foo(); }
>> }
>>
>> public class C extends B {
>> public void foo() { callSuper(); }
>> private void callSuper() { super.foo(); }
>> }
>>
>> B's foo will always call B's callSuper, even when this is actually a C.
>> We handle this properly for Java code, but not when foo is a JSNI method.
>
> Woudn't this cause infinite recursion when this is actually a C & using
> virtual dispatch?
>
> c.foo -> c.callSuper -> b.foo -> c.callSuper -> b.foo -> c.callSuper etc.
>
> If it's a polymorphic call, I believe the call graph looks like:
> c.foo -> c.callSuper -> b.foo -> b.callSuper -> a.foo
>
>>
>>
>> --
>> John A. Tamplin
>> Software Engineer (GWT), Google
>>
>>
>>
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: new test which demonstrates the infinite recursion bug
On Mon, Apr 6, 2009 at 7:13 PM, John Tamplin wrote:
> The attached patch, relative to trunk r5191, adds a new tests which fails
> only in web mode and only for the JsniSuper case. It appears the problem
> isn't directly related to super, but rather with making calls to private
> methods polymorphic rather than virtual dispatch. This is the bug I ran
> into with the CurrencyListGenerator changes I committed and then had to roll
> back.
>
> Ie:
>
> public class A {
> public void foo() {}
> }
>
> public class B extends A {
> public void foo() { callSuper(); }
> private void callSuper() { super.foo(); }
> }
>
> public class C extends B {
> public void foo() { callSuper(); }
> private void callSuper() { super.foo(); }
> }
>
> B's foo will always call B's callSuper, even when this is actually a C.
> We handle this properly for Java code, but not when foo is a JSNI method.
Woudn't this cause infinite recursion when this is actually a C & using
virtual dispatch?
c.foo -> c.callSuper -> b.foo -> c.callSuper -> b.foo -> c.callSuper etc.
If it's a polymorphic call, I believe the call graph looks like:
c.foo -> c.callSuper -> b.foo -> b.callSuper -> a.foo
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] code review requested - add JSONP suport
The attached patch for trunk adds JSONP support, for use with cross-site
data retrieval, such as GData APIs.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: user/src/com/google/gwt/jsonp/Jsonp.gwt.xml
===
--- user/src/com/google/gwt/jsonp/Jsonp.gwt.xml (revision 0)
+++ user/src/com/google/gwt/jsonp/Jsonp.gwt.xml (revision 0)
@@ -0,0 +1,18 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Index: user/src/com/google/gwt/jsonp/client/JsonpRequest.java
===
--- user/src/com/google/gwt/jsonp/client/JsonpRequest.java (revision 0)
+++ user/src/com/google/gwt/jsonp/client/JsonpRequest.java (revision 0)
@@ -0,0 +1,215 @@
+/*
+ * 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.jsonp.client;
+
+import com.google.gwt.dom.client.Document;
+import com.google.gwt.dom.client.Node;
+import com.google.gwt.dom.client.ScriptElement;
+import com.google.gwt.user.client.Command;
+import com.google.gwt.user.client.DeferredCommand;
+import com.google.gwt.user.client.Timer;
+import com.google.gwt.user.client.rpc.AsyncCallback;
+
+/**
+ * A JSONP request that is waiting for a response. The request can be cancelled.
+ *
+ * @param the type of the response object.
+ */
+public class JsonpRequest {
+
+ /**
+ * Each request will be assigned a new id.
+ */
+ private static int callbackCounter = 0;
+
+ private static native Node getDocumentElement() /*-{
+return $doc.documentElement;
+ }-*/;
+
+ private static String nextCallbackId() {
+return "__jsonp" + (callbackCounter++) + "__";
+ }
+
+ private final String callbackId;
+
+ private final int timeout;
+
+ private final AsyncCallback callback;
+
+ /**
+ * Whether the result is expected to be an integer or not
+ */
+ @SuppressWarnings("unused") // used by JSNI
+ private final boolean expectInteger;
+
+ private final String callbackParam;
+
+ private final String failureCallbackParam;
+
+ /**
+ * Timer which keeps track of timeouts.
+ */
+ private Timer timer;
+
+ /**
+ * Create a new JSONP request.
+ *
+ * @param callback The callback instance to notify when the response comes
+ * back
+ * @param timeout Time in ms after which a {...@link TimeoutException} will be
+ * thrown
+ * @param expectInteger Should be true if T is {...@link Integer}, false
+ * otherwise
+ * @param callbackParam Name of the url param of the callback function name
+ * @param failureCallbackParam Name of the url param containing the the
+ * failure callback function name, or null for no failure callback
+ */
+ JsonpRequest(AsyncCallback callback, int timeout, boolean expectInteger,
+ String callbackParam, String failureCallbackParam) {
+callbackId = nextCallbackId();
+this.callback = callback;
+this.timeout = timeout;
+this.expectInteger = expectInteger;
+this.callbackParam = callbackParam;
+this.failureCallbackParam = failureCallbackParam;
+ }
+
+ /**
+ * Cancels a pending request.
+ */
+ public void cancel() {
+timer.cancel();
+unload();
+ }
+
+ public AsyncCallback getCallback() {
+return callback;
+ }
+
+ public int getTimeout() {
+return timeout;
+ }
+
+ /**
+ * Sends a request using the JSONP mechanism.
+ *
+ * @param baseUri To be sent to the server.
+ */
+ void send(final String baseUri) {
+registerCallbacks();
+StringBuffer uri = new StringBuffer(baseUri);
+uri.append(baseUri.contains("?") ? "&" : "?");
+uri.append(callbackParam).append("=").append(callbackId).append(
+".onSuccess");
+if (failureCallbackParam != null) {
+ uri.append("&");
+ uri.append(failureCallbackParam).append("=").append(callbackId).append(
+ ".onFailure");
+}
+ScriptElement script = Document.get().createScriptElement();
+script.setType("text/javascript");
+script.setId(callbackId);
+script.setSrc(uri.toString());
+getDocumentElement().getFirstChild().appendChild(script);
+timer = new Timer() {
+ @Override
+ public void run() {
+onFailure(new TimeoutException("Timeout while calling " + baseUri));
+ }
+
[gwt-contrib] new test which demonstrates the infinite recursion bug
The attached patch, relative to trunk r5191, adds a new tests which fails
only in web mode and only for the JsniSuper case. It appears the problem
isn't directly related to super, but rather with making calls to private
methods polymorphic rather than virtual dispatch. This is the bug I ran
into with the CurrencyListGenerator changes I committed and then had to roll
back.
Ie:
public class A {
public void foo() {}
}
public class B extends A {
public void foo() { callSuper(); }
private void callSuper() { super.foo(); }
}
public class C extends B {
public void foo() { callSuper(); }
private void callSuper() { super.foo(); }
}
B's foo will always call B's callSuper, even when this is actually a C. We
handle this properly for Java code, but not when foo is a JSNI method.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: user/test/com/google/gwt/dev/jjs/test/CompilerTest.java
===
--- user/test/com/google/gwt/dev/jjs/test/CompilerTest.java (revision 5191)
+++ user/test/com/google/gwt/dev/jjs/test/CompilerTest.java (working copy)
@@ -28,6 +28,62 @@
@SuppressWarnings("unused")
public class CompilerTest extends GWTTestCase {
+ public static class JsniSuperChild extends JsniSuperParent {
+@Override
+public native int foo() /*-{
+ return th...@com.google.gwt.dev.jjs.test.compilertest$jsnisuperchild::callSuper()();
+}-*/;
+
+private int callSuper() {
+ return super.foo();
+}
+ }
+
+ public static class JsniSuperGrandparent {
+public int foo() {
+ return 0;
+}
+ }
+
+ public static class JsniSuperParent extends JsniSuperGrandparent {
+@Override
+public native int foo() /*-{
+ return th...@com.google.gwt.dev.jjs.test.compilertest$jsnisuperparent::callSuper()();
+}-*/;
+
+private int callSuper() {
+ return super.foo();
+}
+ }
+
+ public static class SuperChild extends SuperParent {
+@Override
+public int foo() {
+ return callSuper();
+}
+
+private int callSuper() {
+ return super.foo();
+}
+ }
+
+ public static class SuperGrandparent {
+public int foo() {
+ return 0;
+}
+ }
+
+ public static class SuperParent extends SuperGrandparent {
+@Override
+public int foo() {
+ return callSuper();
+}
+
+private int callSuper() {
+ return super.foo();
+}
+ }
+
interface MyMap {
Object get(String key);
}
@@ -952,6 +1008,15 @@
new CheckSubclassStaticInnerAndClinitOrdering();
}
+ /**
+ * Test that super calls work properly, including private bridge methods
+ * needed since JSNI can't call super methods.
+ */
+ public void testSuper() {
+assertEquals(0, new SuperChild().foo());
+assertEquals(0, new JsniSuperChild().foo());
+ }
+
public void testSwitchStatement() {
switch (0) {
case 0:
[gwt-contrib] Re: Review: JsArrays patch
Ping. (This is supposed to be just the non-contentious stuff.) On Tue, Mar 31, 2009 at 9:55 PM, Freeland Abbott wrote: > Okay. I'll look into sort and toSource tomorrow; right now I'm away from > that project code to see whether I want to try to fight for sort. > So this patch should, I hope, be just the easy stuff. Usually when I say > something rash like that it turns out I'm very wrong, but we'll see. > > Regarding JSO, I pulled toSource, but left the I-think-helpful toString(). > I know Scott worried about "pulling in" other types' toString(), but in > separate private email I think his worry is unfounded---best I know, we > don't analyze JSNI bodies, so while this implementation references > toString() if available, it can't change code size by pulling anything in > that wasn't already coming for the ride. I think; I'm sure he or someone > will correct me if I'm wrong on that! > > > > On Tue, Mar 31, 2009 at 5:44 AM, Kelly Norton wrote: > >> Few things: >> Overall, I'd like to be more conservative landing things in >> JavaScriptObject for a couple of reasons: (1) It's hard to take a mulligan >> with these because of their constraints (2) there is always a trivial work >> around to create application specific subclasses (with toll free casting). >> >> >> From r5082: I don't think toSource is appropriate for JavaScriptObject. >> It only works on mozilla browsers. >> >> JsArray.push: As I recall, this[this.length] = value is faster than >> this.push(value) on all browsers. It's not a complexity change like >> array.pop() is, but it can be significant. (How I do wish we had continuous >> perf testing). >> >> >> javadoc: The javadoc for these should be written to describe what the >> function does. "Direct mapping to underlying sort" is a good implementation >> note, but we should actually way what it does and not rely on developers >> having an understanding of the JavaScript equivalent. >> >> >> sort(JavaScriptObject): I'd like to avoid this one if we can. It just >> opens up larger questions about the right way to do this. We don't currently >> have a convention for representing JavaScript functions in Java. Someone >> should probably have a good story there before we add something like this to >> JavaScriptObject. >> >> /kel >> >> On Fri, Mar 27, 2009 at 2:15 PM, Freeland Abbott wrote: >> >>> I think the argument is more for "unnecessary" rather than "bad"... >>> although without JsArrayBase (we can make it package-protected, and call it >>> JsArrayImpl if anyone cares), we duplicate the JSNI implementation for a >>> couple trivial methods. I thought refactoring them into one place was nice, >>> but trivial enough that I'm not fighting over it. Revised patch attached; I >>> can go either way on this. >>> >>> >>> >>> >>> >>> On Fri, Mar 27, 2009 at 2:06 PM, Scott Blum wrote: >>> I'm going to punt this review to Bruce & Kelly, 'cause I have no idea why having JsArrayBase would be bad. :) On Fri, Mar 27, 2009 at 1:28 PM, Freeland Abbott < gwt.team.fabb...@gmail.com> wrote: > Scott, we already talked about this, but here's the patch for public > review. > > The basic goal is to surface the native length, sort, push, and shift > operators for JsArrays... I know you mentioned that IE6's push may be > slower > than indexed extension, and thus a candidate for deferred binding, but I > wanted to get a basic implementation in first. > > There should be only checkstyle changes from what we discussed (though > that obviously doesn't help the rest GWTC). I also added some checkstyle > fixes to JavaScriptObject, introduced by my c5082. > >>> >> >> >> -- >> If you received this communication by mistake, you are entitled to one >> free ice cream cone on me. Simply print out this email including all >> relevant SMTP headers and present them at my desk to claim your creamy >> treat. We'll have a laugh at my emailing incompetence, and play a game of >> ping pong. (offer may not be valid in all States). >> > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: review request: clean up the RPC compile-time noise
This is a big improvement on the logging. I really like the gist of it. I think it should have a second iteration, though. I reluctantly agree about dropping most all warnings. Once we have a way to suppress warnings, then we can talk about how to put them back in. The main thing is that many problems are still logged via TreeLogger and not stored in the ProblemReport. Shouldn't we jump over consistently to the new system rather than have a mix? Are there any particular cases you ran into where it was hard to assign the problem to a particular type? In particular, the four callers to getLogLevel() look like they should be updated. Also, the new "visited" field is redundant with the typeToTyeInfoComputed map. It looks like you ran into some recursion issue somewhere. We should fix that problem by improving the existing short-circuiting via TICs, not by adding a new and subtly different field. Error message content: I have not looked at the output carefully, but it looks like we are losing dependency information between types. This could be improved greatly by adding link-up messages to any type that fails due to a separate type from failing. In particular: 1. In checkSubtypes(), add a problem for each candidate that is rejected. For example, "tried subtype Foo but it was not instantiable". 2. In checkSubtype(), log messages for recursing to a supertype and recursing into a field's type. For example, "superclass Foo is not instantiable". "Field x of type Foo is not instantiable". It could be that I misunderstand what the output will look like, though. If you think these messages would be overkill, could you post some error traces for cases like these? It would greatly help if the report sorted the types by their fully qualified name. Nits: To simplify the code and help with future developments, the errors could be stored in the TIC class instead of in ProblemReport. Simply add a field "List problems". The two static methods that take a ProblemReport as an argument could instead take a List as an argument. The general rule is that TIC holds the information STOB deduces about a particular type. Surely it will work well to log the errors there directly. STOB.canBeInstantiated should lose its logLevel parameter, because it's no longer used. Yay! I didn't scan carefully, but perhaps some other methods could lose a similar parameter. Maybe even some loggers can go away. Likewise, you HAVE to delete the isSpeculative parameter from all methods that have one. This is this patch's greatest accomplishment, and is why it generates such better error messages. You should delete it, revive it, and delete it again, and then upload the video to YouTube. I see four calls still to getLogLevel(), but it looks like all of them should go away in favor of recording into ProblemReport. STOB.build needs formatting Style things, up to you: The first variant of shouldConsiderFieldsForSerialization invites callers to discard problem messages. IMHO, delete it and force people to supply an empty list if they really want to ignore the problems. Returning an empty list from getProblemsForType looks safer and more convenient than returning null. It's as easy to call isEmpty() as to check for null, and there are many idioms where having an empty list is more convenient than having a list-or-null. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 1:47 PM, Bruce Johnson wrote: > (BTW, I could be wrong about the whole "let's not have freeform text". It > was just one guy's opinion that it makes things too inconsistent. I'd like > to hear if other people agree/disagree.) > > @Other people: agree/disagree? > > Assuming people do agree that it's a bit better to avoid freeform text, then > Bob, I like your most recent suggestion with John's addendum. The option to document the deprecation seems useful to me. Especially in the case that John mentioned--you may need to explain which parts of the big module got split into which chunk. I don't really like the idea that you have to provide a URL because it moves the documentation out of the module. I think one of the strengths of JavaDoc is that the doc is right there in the code. I'd like to suggest this format: Optional free-form text explaining this change I think it's cleaner than a comma-separated superceded-by attribute and it allows you to document each replacement in-line. If people generally don't like the free-form text in line, then I'd vote for Bob's solution--an external file is likely to explain the whole change so it wouldn't make sense to replace my in-line text with an href on each superceded-by element. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 4:51 PM, John Tamplin wrote: > On Mon, Apr 6, 2009 at 4:47 PM, Bruce Johnson wrote: > >> (BTW, I could be wrong about the whole "let's not have freeform text". It >> was just one guy's opinion that it makes things too inconsistent. I'd like >> to hear if other people agree/disagree.) >> >> @Other people: agree/disagree? >> > > I think there may be some case where you want/need more explanation, > especially if it is of the form "If you were doing X, use module A -- if you > were doing Y, use module B". However, I think the URL will address most of > that and it is easy enough to extend it later for free-form text if it > becomes useful to do so -- it is harder to remove it if we add it now but it > isn't useful. > > The one question I have is where will the URL point for an unreleased > version? Ie, say we deprecate something in trunk, where would we make the > URL point for more information? > The compiler does this already by including reference to HTML files that are included in the distro. It is important that this could work (i.e. file URLs). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 4:47 PM, Bruce Johnson wrote: > (BTW, I could be wrong about the whole "let's not have freeform text". It > was just one guy's opinion that it makes things too inconsistent. I'd like > to hear if other people agree/disagree.) > > @Other people: agree/disagree? > I think there may be some case where you want/need more explanation, especially if it is of the form "If you were doing X, use module A -- if you were doing Y, use module B". However, I think the URL will address most of that and it is easy enough to extend it later for free-form text if it becomes useful to do so -- it is harder to remove it if we add it now but it isn't useful. The one question I have is where will the URL point for an unreleased version? Ie, say we deprecate something in trunk, where would we make the URL point for more information? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
(BTW, I could be wrong about the whole "let's not have freeform text". It was just one guy's opinion that it makes things too inconsistent. I'd like to hear if other people agree/disagree.) @Other people: agree/disagree? Assuming people do agree that it's a bit better to avoid freeform text, then Bob, I like your most recent suggestion with John's addendum. On Mon, Apr 6, 2009 at 4:37 PM, John Tamplin wrote: > On Mon, Apr 6, 2009 at 4:26 PM, BobV wrote: > >> >> > How does that manifest as XML? >> >> http://google.com/something"; >> /> >> >> where both attributes are optional. The URL will be presented by >> using the AbstractTreeLogger.log() method that takes a HelpInfo >> object. >> > > superceded-by should probably accept a comma-separated list of modules in > case the functionality gets split up. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 4:26 PM, BobV wrote: > > > How does that manifest as XML? > > http://google.com/something"; > /> > > where both attributes are optional. The URL will be presented by > using the AbstractTreeLogger.log() method that takes a HelpInfo > object. > superceded-by should probably accept a comma-separated list of modules in case the functionality gets split up. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
> How does that manifest as XML? http://google.com/something"; /> where both attributes are optional. The URL will be presented by using the AbstractTreeLogger.log() method that takes a HelpInfo object. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 4:17 PM, BobV wrote: > I'm thinking of the case that I have where transitioning from > ImmutableResourceBundle to ClientBundle could use some documentation > to indicate where there have been changes. > > So how about "use this instead" and "more information here" and lose > the free-form data? How does that manifest as XML? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
> I don't think that handles the most common use case, though. Wouldn't the > most common thing be, "Don't use this; use "? Most people will go to > the absolute minimum trouble necessary, so it's unlikely people would be > included to create an actual URL to point to. (IMHO) I'm thinking of the case that I have where transitioning from ImmutableResourceBundle to ClientBundle could use some documentation to indicate where there have been changes. So how about "use this instead" and "more information here" and lose the free-form data? -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5191 - Adds more bridge methods so as to simplify and make more robust
Author: sp...@google.com
Date: Mon Apr 6 12:48:03 2009
New Revision: 5191
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardMethodMember.java
trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JMethod.java
trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
trunk/user/test/com/google/gwt/dev/jjs/test/CompilerTest.java
Log:
Adds more bridge methods so as to simplify and make more robust
virtual-method dispatch in the face of tricky generics cases.
Fixes issue 3517.
Patch by: scottb
Review by: spoon
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardMethodMember.java
==
---
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardMethodMember.java
(original)
+++
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardMethodMember.java
Mon Apr 6 12:48:03 2009
@@ -51,6 +51,7 @@
sb.append(type.getJsniSignatureName());
}
sb.append(")");
+sb.append(method.getOriginalReturnType().getJsniSignatureName());
this.sourceName = sb.toString();
SortedSet aliases = new TreeSet();
Modified: trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JMethod.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JMethod.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JMethod.java Mon Apr 6
12:48:03 2009
@@ -47,6 +47,7 @@
private final boolean isStatic;
private final String name;
private List originalParamTypes;
+ private JType originalReturnType;
/**
* References to any methods which this method overrides. This should be
an
@@ -102,7 +103,7 @@
for (JParameter param : params) {
paramTypes.add(param.getType());
}
-setOriginalParamTypes(paramTypes);
+setOriginalTypes(returnType, paramTypes);
}
public JAbstractMethodBody getBody() {
@@ -124,6 +125,10 @@
return originalParamTypes;
}
+ public JType getOriginalReturnType() {
+return originalReturnType;
+ }
+
/**
* Returns the transitive closure of all the methods this method
overrides.
*/
@@ -189,10 +194,11 @@
isFinal = true;
}
- public void setOriginalParamTypes(List paramTypes) {
+ public void setOriginalTypes(JType returnType, List paramTypes) {
if (originalParamTypes != null) {
throw new InternalCompilerException("Param types already frozen");
}
+originalReturnType = returnType;
originalParamTypes = Lists.normalize(paramTypes);
// Determine if we should trace this method.
Modified: trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java Mon Apr 6
12:48:03 2009
@@ -124,6 +124,7 @@
sb.append(type.getJsniSignatureName());
}
sb.append(")");
+sb.append(method.getOriginalReturnType().getJsniSignatureName());
return sb.toString();
}
Modified: trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java Mon Apr
6 12:48:03 2009
@@ -156,6 +156,11 @@
return false;
}
+// original return type must be identical
+if (method1.getOriginalReturnType() !=
method2.getOriginalReturnType()) {
+ return false;
+}
+
// original parameter types must be identical
List params1 = method1.getOriginalParamTypes();
List params2 = method2.getOriginalParamTypes();
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 Mon
Apr 6 12:48:03 2009
@@ -309,8 +309,8 @@
*
*/
public void addBridgeMethods(SourceTypeBinding clazzBinding) {
- if (clazzBinding.isInterface() || clazzBinding.isAbstract()) {
-// Only add bridges in concrete classes, to simplify matters.
+ if (clazzBinding.isInterface()) {
+// Only add bridges in classes, to simplify matters.
return;
}
@@ -322,7 +322,8 @@
*/
if (clazzBinding.syntheticMethods(
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 1:35 PM, BobV wrote: > > On Mon, Apr 6, 2009 at 1:28 PM, Bruce Johnson wrote: > > Sounds pretty useful. We should lock its behavior down more, though. > Maybe > > Locking it down is just going to get in the way because we can't cover > all of the types of messages that you'd necessarily want to be able to > convey in tag attributes. I may not be thinking about the spectrum clearly enough. Do you have some examples in mind? It seems like the 99% case is people saying "Don't use this anymore; use instead." > Developers will just have to be judicious > in their use of a free-form message; it more-or-less works for > JavaDoc. (tangent: ModuleDoc?) In javadoc, it has always seemed like an un-usefully underconstrained tag. Everbody says exactly the same things, phrased every-so-slightly differently. > If you want to lock it down, the most useful thing to be able to > specify is a URL with additional information. I don't think that handles the most common use case, though. Wouldn't the most common thing be, "Don't use this; use "? Most people will go to the absolute minimum trouble necessary, so it's unlikely people would be included to create an actual URL to point to. (IMHO) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: weak listener in GWT?
The solution that I suggest above, seem to work fine. BTW: I also had another look at the solution suggested by MiroSlav, but that is a technical soution that isn't correct in my case. His solution was to remove the global model listeners when the widget got detached. However, I can easily detach a widget/panel from one form and connect it to another form, which in my case is completely legal, but will result in correct behavior as the listeners are removed :(. So I solved it in a functional way by adding listeners to my Form Fields that are informed about form field removal/insertions. These listeners are added to the Form Field. I also have a Form listener that receives these kind of notifications, but couldn't be used in the form field builder as Form isn't know there, where as the Form field is. I hope it's of some use to others. -- Ed --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5190 - Lower the memory usage of -soyc by using an array in place of an EnumMap.
Author: sp...@google.com
Date: Mon Apr 6 11:34:59 2009
New Revision: 5190
Modified:
trunk/dev/core/src/com/google/gwt/dev/jjs/SourceInfoCorrelation.java
Log:
Lower the memory usage of -soyc by using an array in place of an EnumMap.
Patch by: kprobst
Review by: spoon
Modified:
trunk/dev/core/src/com/google/gwt/dev/jjs/SourceInfoCorrelation.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/SourceInfoCorrelation.java
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/SourceInfoCorrelation.java
Mon Apr 6 11:34:59 2009
@@ -19,7 +19,6 @@
import java.io.Serializable;
import java.util.ArrayList;
-import java.util.EnumMap;
import java.util.EnumSet;
import java.util.HashSet;
import java.util.Iterator;
@@ -38,6 +37,10 @@
*/
private static final SourceInfo[] EMPTY_SOURCEINFO_ARRAY = new
SourceInfo[0];
+ private static int numCorrelationAxes() {
+return Axis.values().length;
+ }
+
/**
* Any Correlation associated with the SourceInfo.
*/
@@ -50,13 +53,15 @@
/**
* Records the first Correlation on any given Axis applied to the
SourceInfo.
+ * Each index of this array corresponds to the Correlation.Axis with the
same
+ * ordinal().
*/
- private final EnumMap primaryCorrelations;
+ private final Correlation[] primaryCorrelations;
public SourceInfoCorrelation(SourceOrigin origin) {
this.origin = origin;
allCorrelations = new ArrayList();
-primaryCorrelations = new EnumMap(Axis.class);
+primaryCorrelations = new Correlation[numCorrelationAxes()];
}
private SourceInfoCorrelation(SourceInfoCorrelation parent, String
mutation,
@@ -66,8 +71,10 @@
this.origin = parent.origin;
this.allCorrelations = new
ArrayList(parent.allCorrelations);
-this.primaryCorrelations = new EnumMap(
-parent.primaryCorrelations);
+primaryCorrelations = new Correlation[numCorrelationAxes()];
+for (int i = 0; i < numCorrelationAxes(); i++) {
+ primaryCorrelations[i] = parent.primaryCorrelations[i];
+}
merge(additionalAncestors);
}
@@ -79,8 +86,10 @@
if (!isAlreadyInAllCorrelations(c)) {
allCorrelations.add(c);
}
-if (!primaryCorrelations.containsKey(c.getAxis())) {
- primaryCorrelations.put(c.getAxis(), c);
+
+int index = c.getAxis().ordinal();
+if (primaryCorrelations[index] == null) {
+ primaryCorrelations[index] = c;
}
}
@@ -140,7 +149,7 @@
* null if no Correlation has been set on the given axis.
*/
public Correlation getPrimaryCorrelation(Axis axis) {
-return primaryCorrelations.get(axis);
+return primaryCorrelations[axis.ordinal()];
}
/**
@@ -148,7 +157,13 @@
* has been set.
*/
public Set getPrimaryCorrelations() {
-return new HashSet(primaryCorrelations.values());
+HashSet toReturn = new HashSet();
+for (Correlation c : primaryCorrelations) {
+ if (c != null) {
+toReturn.add(c);
+ }
+}
+return toReturn;
}
public int getStartLine() {
@@ -197,12 +212,12 @@
allCorrelations.add(c);
}
}
- if (primaryCorrelations.size() < Axis.values().length
- && info instanceof SourceInfoCorrelation) {
-EnumMap copy = new EnumMap(
-((SourceInfoCorrelation) info).primaryCorrelations);
-copy.keySet().removeAll(primaryCorrelations.keySet());
-primaryCorrelations.putAll(copy);
+
+ for (Correlation c : info.getPrimaryCorrelations()) {
+int i = c.getAxis().ordinal();
+if (primaryCorrelations[i] == null) {
+ primaryCorrelations[i] = c;
+}
}
}
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 1:28 PM, Bruce Johnson wrote: > Sounds pretty useful. We should lock its behavior down more, though. Maybe Locking it down is just going to get in the way because we can't cover all of the types of messages that you'd necessarily want to be able to convey in tag attributes. Developers will just have to be judicious in their use of a free-form message; it more-or-less works for JavaDoc. (tangent: ModuleDoc?) If you want to lock it down, the most useful thing to be able to specify is a URL with additional information. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DOMImplIE6.getZoomMultiple() divide by zero error
LGTM And I agree with putting this on the 1.6 branch, but it's Bruce's call http://gwt-code-reviews.appspot.com/17801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
Sounds pretty useful. We should lock its behavior down more, though. Maybe just where superceded-by is optional. It would be helpful to have consistent-looking deprecation messages, so we probably shouldn't leave the text open-ended. On Mon, Apr 6, 2009 at 11:57 AM, BobV wrote: > > I'm in the process of migrating ClientBundle into trunk and it > occurred to me that even if you remove the use of all deprecated types > from your code, your module might still inherit an otherwise-unused > module. > > What do you think about adding another tag to gwt.xml as follows? > > > http://google.com/more_info"; >This module has been > replaced by blah-blah-blah. > > > -- > Bob Vawter > Google Web Toolkit Team > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5189 - Updated release notes and doc links.
Author: br...@google.com Date: Mon Apr 6 09:57:48 2009 New Revision: 5189 Modified: releases/1.6/distro-source/core/src/index.html releases/1.6/distro-source/core/src/release_notes.html Log: Updated release notes and doc links. Modified: releases/1.6/distro-source/core/src/index.html == --- releases/1.6/distro-source/core/src/index.html (original) +++ releases/1.6/distro-source/core/src/index.html Mon Apr 6 09:57:48 2009 @@ -40,9 +40,9 @@ Ajax is hard. But you're not alone! -http://code.google.com/docreader/?p(google-web-toolkit-doc-1-6)s(google-web-toolkit-doc-1-6)t(ReleaseNotes_1_6)">What's new in GWT 1.6? (online) +http://code.google.com/webtoolkit/doc/1.6/ReleaseNotes_1_6.html";>What's new in GWT 1.6? (online) - Point releases notes are also available locally. + Point releases notes are also included in the distribution. @@ -67,7 +67,7 @@ -http://code.google.com/docreader/?p=google-web-toolkit-doc-1-6&s=google-web-toolkit-doc-1-6&t=FAQ";>Frequently Asked Questions (online) +http://code.google.com/webtoolkit/doc/1.6/FAQ.html";>Frequently Asked Questions (online) Answers to the initial questions developers have about using GWT, including licensing, upgrades, and so on. @@ -82,20 +82,20 @@ -http://code.google.com/docreader/?p=google-web-toolkit-doc-1-6&s=google-web-toolkit-doc-1-6&t=DevGuideDeveloperGuide";>Developer Guide (online) +http://code.google.com/webtoolkit/doc/1.6/DevGuide.html";>Developer Guide (online) The Developer Guide explains the key concepts in GWT. -http://code.google.com/docreader/?p=google-web-toolkit-doc-1-6&s=google-web-toolkit-doc-1-6&t=DevGuideWidgetGallery";> +http://code.google.com/webtoolkit/doc/1.6/RefWidgetGallery.html";> Widget Gallery (online) Browse some of the built-in GWT widgets and panels. -http://code.google.com/docreader/?p=google-web-toolkit-doc-1-6&s=google-web-toolkit-doc-1-6&t=DevGuideCommandLineTools";>Command-line +http://code.google.com/webtoolkit/doc/1.6/RefCommandLineTools.html";>Command-line Tools (online) Scripts to help you get started with GWT projects. Modified: releases/1.6/distro-source/core/src/release_notes.html == --- releases/1.6/distro-source/core/src/release_notes.html (original) +++ releases/1.6/distro-source/core/src/release_notes.html Mon Apr 6 09:57:48 2009 @@ -29,6 +29,7 @@ Google Web Toolkit Release Notes @GWT_VERSION@ +1.6.3 1.6.2 1.5.3 1.5.2 @@ -51,6 +52,14 @@ Release Notes for @GWT_VERSION@ Fixed Issues +The classpath in the scripts created by junitCreator was updated to refer to /war/WEB-INF/classes rather than /bin. + + + + + Release Notes for 1.6.3 (RC2) + Fixed Issues + Various http://code.google.com/p/google-web-toolkit/issues/detail?id=3496";>servlet classpath issues introduced in 1.6.2 are resolved. JSP compilation should work out of the box in hosted mode. @@ -59,7 +68,7 @@ Release Notes for 1.6.2 (RC) - Please see http://code.google.com/docreader/?p(google-web-toolkit-doc-1-6)s(google-web-toolkit-doc-1-6)t(ReleaseNotes_1_6)">What's new in GWT 1.6? (online) + Please see http://code.google.com/webtoolkit/doc/1.6/ReleaseNotes_1_6.html";>What's new in GWT 1.6? (online) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5188 - Updated junitCreator templates to find bytecode in /war/WEB-INF/classes rather than /bin.
Author: br...@google.com Date: Mon Apr 6 09:50:04 2009 New Revision: 5188 Modified: releases/1.6/user/src/com/google/gwt/junit/tools/junit-hosted.cmdsrc releases/1.6/user/src/com/google/gwt/junit/tools/junit-hostedsrc releases/1.6/user/src/com/google/gwt/junit/tools/junit-web.cmdsrc releases/1.6/user/src/com/google/gwt/junit/tools/junit-websrc Log: Updated junitCreator templates to find bytecode in /war/WEB-INF/classes rather than /bin. Modified: releases/1.6/user/src/com/google/gwt/junit/tools/junit-hosted.cmdsrc == --- releases/1.6/user/src/com/google/gwt/junit/tools/junit-hosted.cmdsrc (original) +++ releases/1.6/user/src/com/google/gwt/junit/tools/junit-hosted.cmdsrc Mon Apr 6 09:50:04 2009 @@ -1 +1 @@ -...@java -Dgwt.args="-out www-test" -Xmx256M -cp "%~dp0\src;%~dp0\test;%~dp0\bin;@junitPath;@gwtUserPath;@gwtdevp...@extraclasspathssemicolon" junit.textui.TestRunner @clientpacka...@classname %* \ No newline at end of file +...@java -Dgwt.args="-out www-test" -Xmx256M -cp "%~dp0\src;%~dp0\test;%~dp0\war\WEB-INF\classes;@junitPath;@gwtUserPath;@gwtdevp...@extraclasspathssemicolon" junit.textui.TestRunner @clientpacka...@classname %* \ No newline at end of file Modified: releases/1.6/user/src/com/google/gwt/junit/tools/junit-hostedsrc == --- releases/1.6/user/src/com/google/gwt/junit/tools/junit-hostedsrc (original) +++ releases/1.6/user/src/com/google/gwt/junit/tools/junit-hostedsrcMon Apr 6 09:50:04 2009 @@ -1,3 +1,3 @@ #!/bin/sh APPDIR=`dirname $0`; -java @vmargs -Dgwt.args="-out www-test" -Xmx256M -cp "$APPDIR/src:$APPDIR/test:$APPDIR/bin:@junitPath:@gwtUserPath:@gwtdevp...@extraclasspathscolon" junit.textui.TestRunner @clientpacka...@classname "$@"; +java @vmargs -Dgwt.args="-out www-test" -Xmx256M -cp "$APPDIR/src:$APPDIR/test:$APPDIR/war/WEB-INF/classes:@junitPath:@gwtUserPath:@gwtdevp...@extraclasspathscolon" junit.textui.TestRunner @clientpacka...@classname "$@"; Modified: releases/1.6/user/src/com/google/gwt/junit/tools/junit-web.cmdsrc == --- releases/1.6/user/src/com/google/gwt/junit/tools/junit-web.cmdsrc (original) +++ releases/1.6/user/src/com/google/gwt/junit/tools/junit-web.cmdsrc Mon Apr 6 09:50:04 2009 @@ -1 +1 @@ -...@java -Dgwt.args="-web -out www-test" -Xmx256M -cp "%~dp0\src;%~dp0\test;%~dp0\bin;@junitPath;@gwtUserPath;@gwtdevp...@extraclasspathssemicolon" junit.textui.TestRunner @clientpacka...@classname %* \ No newline at end of file +...@java -Dgwt.args="-web -out www-test" -Xmx256M -cp "%~dp0\src;%~dp0\test;%~dp0\war\WEB-INF\classes;@junitPath;@gwtUserPath;@gwtdevp...@extraclasspathssemicolon" junit.textui.TestRunner @clientpacka...@classname %* \ No newline at end of file Modified: releases/1.6/user/src/com/google/gwt/junit/tools/junit-websrc == --- releases/1.6/user/src/com/google/gwt/junit/tools/junit-websrc (original) +++ releases/1.6/user/src/com/google/gwt/junit/tools/junit-websrc Mon Apr 6 09:50:04 2009 @@ -1,3 +1,3 @@ #!/bin/sh APPDIR=`dirname $0`; -java @vmargs -Dgwt.args="-web -out www-test" -Xmx256M -cp "$APPDIR/src:$APPDIR/test:$APPDIR/bin:@junitPath:@gwtUserPath:@gwtdevp...@extraclasspathscolon" junit.textui.TestRunner @clientpacka...@classname "$@"; +java @vmargs -Dgwt.args="-web -out www-test" -Xmx256M -cp "$APPDIR/src:$APPDIR/test:$APPDIR/war/WEB-INF/classes:@junitPath:@gwtUserPath:@gwtdevp...@extraclasspathscolon" junit.textui.TestRunner @clientpacka...@classname "$@"; --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 11:57 AM, BobV wrote: > > I'm in the process of migrating ClientBundle into trunk and it > occurred to me that even if you remove the use of all deprecated types > from your code, your module might still inherit an otherwise-unused > module. > > What do you think about adding another tag to gwt.xml as follows? > > > http://google.com/more_info"; >This module has been > replaced by blah-blah-blah. > > SGTM. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RFC : Adding deprecations to gwt.xml files
I'm in the process of migrating ClientBundle into trunk and it occurred to me that even if you remove the use of all deprecated types from your code, your module might still inherit an otherwise-unused module. What do you think about adding another tag to gwt.xml as follows? http://google.com/more_info"; >This module has been replaced by blah-blah-blah. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5187 - Edited wiki page through web user interface.
Author: b...@google.com
Date: Mon Apr 6 08:51:55 2009
New Revision: 5187
Modified:
wiki/ClientBundle.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/ClientBundle.wiki
==
--- wiki/ClientBundle.wiki (original)
+++ wiki/ClientBundle.wiki Mon Apr 6 08:51:55 2009
@@ -1,13 +1,110 @@
#summary Compile-time resource optimizations
-TODO(bobv): Copy wiki articles from incubator to here; cross-link the pages
+
-= Migrating from ImmutableResourceBundle =
+= Introduction =
+
+ The resources in a deployed GWT application can be roughly categorized
into resources to never cache `.nocache.js`, to cache forever
`.cache.html`, and everything else `myapp.css`. The ClientBundle interface
moves entries in the everything-else category into the cache-forever
category.
+
+= Goals =
+
+ * No more uncertainty if your application is getting the right contents
for program resources.
+ * Decrease non-determinism caused by intermediate proxy servers.
+ * Enable more aggressive caching headers for program resources.
+ * Eliminate mismatches between physical filenames and constants in Java
code by performing consistency checks during the compile.
+ * Use 'data:' URLs, JSON bundles, or other means of embedding resources
in compiled JS when browser- and size-appropriate to decrease the number of
round-trips entirely.
+ * Provide an extensible design for adding new resource types.
+ * Ensure there is no penalty for having multiple ClientBundle resource
functions refer to the same content.
+
+= Non-Goals =
+
+ * To provide a file-system abstraction
+
+= Examples =
+
+To use the ClientBundle, add an inherits tag to your `gwt.xml` file:
+{{{
+
+}}}
+
+Interfaces:
+{{{
+public interface MyResources extends ClientBundle {
+ public static final MyResources INSTANCE =
GWT.create(MyResources.class);
+
+ @Source("my.css")
+ public CssResource css();
+
+ @Source("config.xml")
+ public TextResource initialConfiguration();
+
+ @Source("manual.pdf")
+ public DataResource ownersManual();
+}
+}}}
+
+You can then say:
+{{{
+ Window.alert(MyResources.INSTANCE.css().getText());
+ new Frame(MyResources.INSTANCE.ownersManual().getURL());
+}}}
+
+= I18N =
+
+ClientBundle is compatible with GWT's I18N module.
+
+Suppose you defined a resource:
+{{{
+...@source("default.txt")
+public TextResource defaultText();
+}}}
+
+For each possible value of the `locale` deferred-binding property, the
ClientBundle generator will look for variations of the specified filename
in a manner similar to that of Java's `ResourceBundle`.
+
+Suppose the `locale` were set to `fr_FR`. The generator would look for
files in the following order:
+ # default_fr_FR.txt
+ # default_fr.txt
+ # default.txt
+
+This will work equally well with all resource types, which can allow you
to provide localized versions of other resources, say `ownersManual_en.pdf`
versus `ownersManual_fr.pdf`.
+
+= Pluggable Resource Generation =
+
+Each subtype of `ResourcePrototype` must define a `...@resourcegenerator`
annotation whose value is a concrete Java class that extends
`ResourceGenerator`. The instance of the `ResourceGenerator` is
responsible for accumulation (or bundling) of incoming resource data as
well as a small degree of code generation to assemble the concrete
implementation of the ClientBundle class. Implementors of
`ResourceGenerator` subclasses can expect that only one `ResourceGenerator`
will be created for a given type of resource within an ClientBundle
interface.
+
+The methods on a `ResourceGenerator` are called in the following order
+ # `init` to provide the `ResourceGenerator` with a `ResourceContext`
+ # `prepare` is called for each `JMethod` the `ResourceGenerator` is
expected to handle
+ # `createFields` allows the `ResourceGenerator` to add code at the class
level
+ # `createAssignment` is called for each `JMethod`. The generated code
should be suitable for use as the right-hand side of an assignment
expression.
+ # `finish` is called after all assignments should have been written.
+
+`ResourceGenerators` are expected to make use of the
`ResourceGeneratorUtil` class.
+
+= Potential pitfalls =
+ * Changing the content of the resources will change the filenames (or
data: encoding), thus forcing a recompile of the GWT application. To avoid
this, the inlining and renaming features can be globally toggled off in
your gwt.xml file during the development phase.
+ * Inlining files into the compiled JS may not make sense if those files
are not always accessed by the program, thus inlining should be
configurable on a per-resource or per-ClientBundle basis.
+
+= Levers and knobs =
+
+ * `ClientBundle.enableInlining` is a deferred-binding property that can
be used to disable the use of `data:` URLs in browsers that would otherwise
support inlining resource data into the compile
[gwt-contrib] Re: RR: shorten filenames for SOYC reports
I guess I should actually include the patch. Here it is: http://gwt-code-reviews.appspot.com/16802/show -Lex On Fri, Apr 3, 2009 at 6:30 PM, Lex Spoon wrote: > Bob, can you review this patch for me? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5186 - Edited wiki page through web user interface.
Author: b...@google.com Date: Mon Apr 6 07:41:16 2009 New Revision: 5186 Modified: wiki/ClientBundle.wiki Log: Edited wiki page through web user interface. Modified: wiki/ClientBundle.wiki == --- wiki/ClientBundle.wiki (original) +++ wiki/ClientBundle.wiki Mon Apr 6 07:41:16 2009 @@ -23,3 +23,4 @@ * `CssResource.enableMerge` to `CssResource.mergeEnabled` * `CssResource.forceStrict` to `CssResource.strictAccessors` * `CssResource.globalPrefix` to `CssResource.obfuscationPrefix` + * StyleInjector moved to `com.google.gwt.dom.client` package \ No newline at end of file --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5184 - Fix OpenJDK compatibility (a generic type inference bug) by removing the
Author: j...@google.com
Date: Mon Apr 6 06:27:37 2009
New Revision: 5184
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/linker/ArtifactSet.java
Log:
Fix OpenJDK compatibility (a generic type inference bug) by removing the
ability to return a different type than is requested. None of our code
uses this ability, and it is easy enough to copy the returned list into a
list of the supertype externally anyway.
Issue: 3058
Patch by: jat
Review by: scottb, bobv
Modified: trunk/dev/core/src/com/google/gwt/core/ext/linker/ArtifactSet.java
==
--- trunk/dev/core/src/com/google/gwt/core/ext/linker/ArtifactSet.java
(original)
+++ trunk/dev/core/src/com/google/gwt/core/ext/linker/ArtifactSet.java Mon
Apr 6 06:27:37 2009
@@ -61,35 +61,30 @@
return treeSet.containsAll(c);
}
+ @Override
public boolean equals(Object o) {
return treeSet.equals(o);
}
/**
* Find all Artifacts assignable to some base type. The returned value
will be
- * a snapshot of the values in the ArtifactSet. The following two
examples
- * result in an equivalent set:
+ * a snapshot of the values in the ArtifactSet. An example of how this
could
+ * be used:
*
*
- * SortedSet search =
artifactSet.find(PublicResource.class);
- * search.addAll(artifactSet.find(GeneratedResource.class);
+ * for (EmittedArtifact ea : artifactSet.find(EmittedArtifact.class)) {
+ * ...
+ * }
*
*
- * or
- *
- *
- * SortedSet search =
artifactSet.find(EmittedArtifact.class);
- *
- *
- * @param a type bound possibly wider than the desired type of
artifact
* @param the desired type of Artifact
* @param artifactType the desired type of Artifact
* @return all Artifacts in the ArtifactSet assignable to the desired
type
*/
- public , T extends A> SortedSet find(
+ public > SortedSet find(
Class artifactType) {
// TODO make this sub-linear (but must retain order for
styles/scripts!)
-SortedSet toReturn = new TreeSet();
+SortedSet toReturn = new TreeSet();
for (Artifact artifact : this) {
if (artifactType.isInstance(artifact)) {
toReturn.add(artifactType.cast(artifact));
@@ -113,6 +108,7 @@
}
}
+ @Override
public int hashCode() {
return treeSet.hashCode();
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5185 - Initial add of StyleInjector.
Author: b...@google.com
Date: Mon Apr 6 07:07:28 2009
New Revision: 5185
Added:
trunk/user/src/com/google/gwt/dom/client/StyleInjector.java (contents,
props changed)
trunk/user/test/com/google/gwt/dom/client/StyleInjectorTest.java
(contents, props changed)
Modified:
trunk/user/src/com/google/gwt/dom/DOM.gwt.xml
trunk/user/test/com/google/gwt/dom/DOMSuite.java
Log:
Initial add of StyleInjector.
New StyleInjectorIE implementation based on work by tirsen and reuben.
Patch by: bobv
Review by: rjrjr, cromwellian
Modified: trunk/user/src/com/google/gwt/dom/DOM.gwt.xml
==
--- trunk/user/src/com/google/gwt/dom/DOM.gwt.xml (original)
+++ trunk/user/src/com/google/gwt/dom/DOM.gwt.xml Mon Apr 6 07:07:28 2009
@@ -44,4 +44,9 @@
+
+
+
+
+
Added: trunk/user/src/com/google/gwt/dom/client/StyleInjector.java
==
--- (empty file)
+++ trunk/user/src/com/google/gwt/dom/client/StyleInjector.java Mon Apr 6
07:07:28 2009
@@ -0,0 +1,225 @@
+/*
+ * Copyright 2008 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.dom.client;
+
+import com.google.gwt.core.client.GWT;
+import com.google.gwt.core.client.JavaScriptObject;
+import com.google.gwt.core.client.JsArray;
+import com.google.gwt.core.client.JsArrayInteger;
+
+/**
+ * Used to add stylesheets to the document.
+ */
+public class StyleInjector {
+
+ /**
+ * The DOM-compatible way of adding stylesheets. This implementation
requires
+ * the host HTML page to have a head element defined.
+ */
+ public static class StyleInjectorImpl {
+private static final StyleInjectorImpl IMPL =
GWT.create(StyleInjectorImpl.class);
+
+private HeadElement head;
+
+public StyleElement injectStyleSheet(String contents) {
+ StyleElement style = createElement(contents);
+ getHead().appendChild(style);
+ return style;
+}
+
+public StyleElement injectStyleSheetAtEnd(String contents) {
+ return injectStyleSheet(contents);
+}
+
+public StyleElement injectStyleSheetAtStart(String contents) {
+ StyleElement style = createElement(contents);
+ getHead().insertBefore(style, head.getFirstChild());
+ return style;
+}
+
+public void setContents(StyleElement style, String contents) {
+ style.setInnerText(contents);
+}
+
+private StyleElement createElement(String contents) {
+ StyleElement style = Document.get().createStyleElement();
+ style.setPropertyString("language", "text/css");
+ setContents(style, contents);
+ return style;
+}
+
+private HeadElement getHead() {
+ if (head == null) {
+Element elt =
Document.get().getElementsByTagName("head").getItem(0);
+assert elt != null : "The host HTML page does not have a
element"
++ " which is required by StyleInjector";
+head = HeadElement.as(elt);
+ }
+ return head;
+}
+ }
+
+ /**
+ * IE doesn't allow manipulation of a style element through DOM methods.
There
+ * is also a hard-coded limit on the number of times that
createStyleSheet can
+ * be called before IE6 starts throwing exceptions.
+ */
+ public static class StyleInjectorImplIE extends StyleInjectorImpl {
+
+/*
+ * TODO(bobv) : Talk to scottb about being able to read this out of the
+ * module xml file as a configuration-property to handle cases where
+ * multiple GWT modules are living in the same page.
+ */
+private static final int MAX_STYLE_SHEETS = 30;
+private static final JsArray STYLE_ELEMENTS =
JavaScriptObject.createArray().cast();
+private static final JsArrayInteger STYLE_ELEMENT_LENGTHS =
JavaScriptObject.createArray().cast();
+
+public native void appendContents(StyleElement style, String contents)
/*-{
+ style.cssText += contents;
+}-*/;
+
+@Override
+public StyleElement injectStyleSheet(String contents) {
+ int idx = STYLE_ELEMENTS.length();
+ if (idx < MAX_STYLE_SHEETS) {
+// Just create a new style element and add it to the list
+StyleElement style = createElement();
+setContents(style, contents);
+STYLE_ELEMENTS.set(idx, style);
+STYLE_ELEMENT_LENGTHS.set(idx, contents.length());
+return style;
+ }
[gwt-contrib] Re: Add StyleInjector to GWT trunk
StyleInjector committed to trunk at r5185. @RayC, I added an assertion that there is a head tag. @RayR, The line lengths seem to be ok according to the eclipse formatting rules checked into trunk. I added notes to the Javadoc indicating that not all StyleElements returned are necessarily unique and that setContents should be used with caution. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: code review requested - allow OpenJDK to compile GWT
On Mon, Apr 6, 2009 at 9:07 AM, BobV wrote: > > Here is the patch which does what Scott suggested. Any objections? > > LGTM Thanks, committed with Scott's javadoc change at r5184. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: JSO patch to use desiredAssertionStatus
On Mon, Apr 6, 2009 at 9:16 AM, Scott Blum wrote: > return JavaScriptObject.class.desiredAssertionStatus() ? > toStringVerbose()? : toStringSimple(); > (typo, obviously) return JavaScriptObject.class.desiredAssertionStatus() ? toStringVerbose() : toStringSimple(); --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: JSO patch to use desiredAssertionStatus
Very close, but I think the Java optimizer won't be able to figure that out
as early as we'd like.
How about something like this?
public final String toString() {
return JavaScriptObject.class.desiredAssertionStatus() ?
toStringVerbose()? : toStringSimple();
}
On Mon, Apr 6, 2009 at 1:48 AM, Freeland Abbott wrote:
> Scott,
>
> is this what you were suggesting, to lighten JavaScriptObject.toString()
> for micro-apps?
>
>
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: code review requested - allow OpenJDK to compile GWT
> Here is the patch which does what Scott suggested. Any objections? LGTM -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: weak listener in GWT?
Hi Hiho, Thanks for your reaction. I don't want to sound (too) arrogant, but your solution is way to simple in my case (I wish I could use it). Because of the complex requirements I have to meet, I have several layers on top of basic widgets. That is: on the level I want to do some cleanup, these widgets are way out of scope (and I have too many widgets below). That is also desired behavior as on the level I want to do some cleanup, I don't want to directly see these widgets anymore as I am in another problem scope. I did some more prototyping and even my above suggestion doesn't solve my problem entirely as I sometimes want to remove part of the listeners that belong to a category. What I will do now: Like explained above: I have my own Form that contains Form field (these are the ones that wrap the basic widgets). These form fields (general gwt things) contain all kind of default behavior: validation, dirty checking, resetting, validation handling, etc.. (I have all kind of general form field for strings, birthday, datepicker, group of checkboxes, etc...) I will add a method to the Form field beforeRemove () that will always called by his managing Form just before removing (detaching) the form field of the Form, that gives the form field a change to do some cleanup. That is: when removing widgets/form field of the Form, I always do this trhough the manging Form. I will then add an extra method to the form field: addRemover (HasDestroy destroy), such that I can add things that need to be called by the Form field when beforeRemove() is called. In my builder I can then add instances to the Form field that need to do some cleanup. I think this is an elegant and nice solution, don't you think ? Da, I do miss the Weak Listener from SWT/Swing in cases like this... (It's back to the stoneage to do everyting yourself. Btw: don't get me wrong, I am not blaming GWT for this it's simple javascript that doesn't support this all) I would love to hear experiences of other developers have bounced their head against this issue. -- Ed --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting available TimeZones, Detecting Timezones?
On Mon, Apr 6, 2009 at 2:40 AM, David wrote: > And what in the case that the application is not running on the internet ? > In banking software chances are very slim that the PC is connected. > The data could be compiled into the application, but it would be large. It could also be stored in Gears or HTML5 databases. It seems hard to imagine a client application of much use without any connection to a server. If it is on a private network, the servlet could be run on private infrastructure as mentioned. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
