[gwt-contrib] Change in gwt[master]: Fixes JRawType#getImplementedMethods to return correct signa...
Manuel Carrasco Moñino has posted comments on this change. Change subject: Fixes JRawType#getImplementedMethods to return correct signature for inherited methods .. Patch Set 1: Code-Review+1 LGTM -- To view, visit https://gwt-review.googlesource.com/3230 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I7e2c4cf3d2d0bc1e50ecab1e257a6ac1d0e496d0 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Goktug Gokdogan Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: FileUpload: extending FocusWidget instead of Widget so as it...
Manuel Carrasco Moñino has uploaded a new change for review.
https://gwt-review.googlesource.com/3211
Change subject: FileUpload: extending FocusWidget instead of Widget so as
it exposes many features which already are in the file-input element:
click(), focus(), mouseevents, keyevents, etc.
..
FileUpload: extending FocusWidget instead of Widget so as it exposes
many features which already are in the file-input element: click(),
focus(), mouseevents, keyevents, etc.
Now it is possible open the file browser calling fileupload.click().
This allows customize widgets to upload files.
It works in almost supported browsers: IE6+, Chrome, Safari, FF (from 4.0)
and Opera (from 12).
Documented css rules noticing that browsers impose many constrains to
input file styling.
Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb
Bugs: issue 2262, issue 4078, issue 1998
---
M user/src/com/google/gwt/dom/client/DOMImplMozilla.java
M user/src/com/google/gwt/user/client/ui/FileUpload.java
M user/test/com/google/gwt/user/client/ui/ButtonTest.java
M user/test/com/google/gwt/user/client/ui/FileUploadTest.java
4 files changed, 58 insertions(+), 28 deletions(-)
diff --git a/user/src/com/google/gwt/dom/client/DOMImplMozilla.java
b/user/src/com/google/gwt/dom/client/DOMImplMozilla.java
index 5dd8343..6f937a0 100644
--- a/user/src/com/google/gwt/dom/client/DOMImplMozilla.java
+++ b/user/src/com/google/gwt/dom/client/DOMImplMozilla.java
@@ -71,7 +71,21 @@
}
@Override
- public native void buttonClick(ButtonElement button) /*-{
+ public void buttonClick(ButtonElement button) {
+if (isGecko19()) {
+ super.buttonClick(button);
+} else {
+ buttonClickImpl(button);
+}
+ }
+
+ /**
+ * This workaround is for browsers which don't set up the event
+ * target properly for synthesized clicks.
+ * It is here since gwt-1.6 or before.
+ * Probably we could get rid of it.
+ */
+ private native void buttonClickImpl(ButtonElement button) /*-{
var doc = button.ownerDocument;
if (doc != null) {
var evt = doc.createEvent('MouseEvents');
@@ -178,7 +192,7 @@
public int getScrollLeft(Element elem) {
if (!isGecko19() && isRTL(elem)) {
return super.getScrollLeft(elem)
- - (elem.getScrollWidth() - elem.getClientWidth());
+ - (elem.getScrollWidth() - elem.getClientWidth());
}
return super.getScrollLeft(elem);
}
diff --git a/user/src/com/google/gwt/user/client/ui/FileUpload.java
b/user/src/com/google/gwt/user/client/ui/FileUpload.java
index 48f2292..4b3e5c4 100644
--- a/user/src/com/google/gwt/user/client/ui/FileUpload.java
+++ b/user/src/com/google/gwt/user/client/ui/FileUpload.java
@@ -34,8 +34,21 @@
* Example
* {@example com.google.gwt.examples.FormPanelExample}
*
+ *
+ * CSS Style Rules
+ *
+ * .gwt-FileUpload {}
+ *
+ * NOTICE about styling
+ *
+ * The developer should be aware that most browsers do not allow to style
+ * many properties of the rendered input-file element because of security
restrictions.
+ * You can style certain properties like position, visibility, opacity,
etc. But size,
+ * color, backgrounds etc. will not work either using css or calling
widget methods like setSize().
+ *
+ *
*/
-public class FileUpload extends Widget implements HasName,
HasChangeHandlers, HasEnabled {
+public class FileUpload extends FocusWidget implements HasName,
HasChangeHandlers {
/**
* Implementation class for {@link FileUpload}.
*/
@@ -166,30 +179,11 @@
return getInputElement().getName();
}
- /**
- * Gets whether this widget is enabled.
- *
- * @return true if the widget is enabled
- */
- public boolean isEnabled() {
-return !getElement().getPropertyBoolean("disabled");
- }
-
@Override
public void onBrowserEvent(Event event) {
if (impl.onBrowserEvent(event)) {
super.onBrowserEvent(event);
}
- }
-
- /**
- * Sets whether this widget is enabled.
- *
- * @param enabled true to enable the widget,
false
- * to disable it
- */
- public void setEnabled(boolean enabled) {
-getElement().setPropertyBoolean("disabled", !enabled);
}
public void setName(String name) {
@@ -199,4 +193,11 @@
private InputElement getInputElement() {
return getElement().cast();
}
+
+ /**
+ * Programmatic equivalent of the user clicking the button.
+ */
+ public void click() {
+getInputElement().click();
+ }
}
diff --git a/user/test/com/google/gwt/user/client/ui/ButtonTest.java
b/user/test/com/google/gwt/user/client/ui/ButtonTest.java
index a70cd17..b5bee9c 100644
--- a/user/test/com/google/gwt/user/client/ui/ButtonTest.java
+++ b/user/test/com/google/gwt/user/client/ui/ButtonTest.java
@@ -36,9 +36,10 @@
return "com.google.gwt.user.User";
}
- private static class H implements ClickHandler {
-boolean clicked;
-EventTarget target;
+ // protected
[gwt-contrib] Change in gwt[master]: FileUpload: extending FocusWidget instead of Widget so as it...
Manuel Carrasco Moñino has uploaded a new patch set (#2). Change subject: FileUpload: extending FocusWidget instead of Widget so as it exposes many features which already are in the file-input element: click(), focus(), mouseevents, keyevents, etc. .. FileUpload: extending FocusWidget instead of Widget so as it exposes many features which already are in the file-input element: click(), focus(), mouseevents, keyevents, etc. Now it is possible open the file browser calling fileupload.click(). This allows customize widgets to upload files. It works in almost supported browsers: IE6+, Chrome, Safari, FF (from 4.0) and Opera (from 12). Documented css rules noticing that browsers impose many constrains to input file styling. Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb Bugs: issue 2262, issue 4078, issue 1998 --- M user/src/com/google/gwt/dom/client/DOMImplMozilla.java M user/src/com/google/gwt/user/client/ui/FileUpload.java M user/test/com/google/gwt/user/client/ui/ButtonTest.java M user/test/com/google/gwt/user/client/ui/FileUploadTest.java 4 files changed, 58 insertions(+), 28 deletions(-) -- To view, visit https://gwt-review.googlesource.com/3211 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Manuel Carrasco Moñino -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Use JSON.parse() instead of eval() to deserialize rpc callba...
Hello Leeroy Jenkins, Thomas Broyer, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/2900 to look at the new patch set (#5). Change subject: Use JSON.parse() instead of eval() to deserialize rpc callback payload .. Use JSON.parse() instead of eval() to deserialize rpc callback payload IE9 is currently leaking memory on every RPC call you make. The root cause is that eval() on IE9 is designed to keep everyting evaled in memory until the browser session dies (see http://support.microsoft.com/kb/2572253). To work around this issue this patch instead of using eval() on the RPC callback payload uses JSON.parse which does not have these problems. Since JSON does not support the special values NaN, Infinity and -Infinity they are now converted into strings and later converted back with Number(x) on the client side. The default RPC version still remains as 7 and this patch introduces a new system variable "gwt.rpc.version" which can be set to 8 to resolve the memory leak. Special cases where hacks have been applied to circumvent browser limitations (string literal size limitation, array size limitation) will still be applied in version 8 and will still be evaled insted of JSON.parsed on the client side. Change-Id: I6062180397f5fabed1dd5f08140c2bd43a19fa9f --- M user/src/com/google/gwt/user/client/rpc/impl/AbstractSerializationStream.java M user/src/com/google/gwt/user/client/rpc/impl/AbstractSerializationStreamWriter.java M user/src/com/google/gwt/user/client/rpc/impl/ClientSerializationStreamReader.java M user/src/com/google/gwt/user/server/rpc/RPC.java M user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java M user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamWriter.java M user/super/com/google/gwt/user/translatable/com/google/gwt/user/client/rpc/impl/ClientSerializationStreamReader.java 7 files changed, 56 insertions(+), 24 deletions(-) -- To view, visit https://gwt-review.googlesource.com/2900 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I6062180397f5fabed1dd5f08140c2bd43a19fa9f Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: John Ahlroos Gerrit-Reviewer: Artur Signell Gerrit-Reviewer: Brian Slesinsky Gerrit-Reviewer: Colin Alworth Gerrit-Reviewer: John Ahlroos Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Matthew Dempsky Gerrit-Reviewer: Thomas Broyer -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Use JSON.parse() instead of eval() to deserialize rpc callba...
John Ahlroos has posted comments on this change. Change subject: Use JSON.parse() instead of eval() to deserialize rpc callback payload .. Patch Set 5: Okay, so patch set 5 takes a much simpler approach and does not change the current behaviour in any way. It only adds a system property "gwt.rpc.version" which can be set to change the behaviour to use JSON.parse. This I think, is a good intermediate solution until we bump the version permanently to 8 and allows customers to work around the memory leak. I did not change how devmode evaluates the response (still using Rhino) and I think it deserves another changeset entirely since it is not related to fixing this memory leak in any way. The special cases (array concatenation, string concatenation) are still sent as Javascript even in version 8. In that case the client will try to parse with JSON.parse and fallback to eval. The memory leak will still persist there but I think those corner cases are so rare that they can at least for now be omitted. -- To view, visit https://gwt-review.googlesource.com/2900 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I6062180397f5fabed1dd5f08140c2bd43a19fa9f Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: John Ahlroos Gerrit-Reviewer: Artur Signell Gerrit-Reviewer: Brian Slesinsky Gerrit-Reviewer: Colin Alworth Gerrit-Reviewer: John Ahlroos Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Matthew Dempsky Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Make Element.hasTagName(...) case-insensitive.
Manuel Carrasco Moñino has posted comments on this change. Change subject: Make Element.hasTagName(...) case-insensitive. .. Patch Set 4: Code-Review+1 (1 comment) File user/test/com/google/gwt/dom/client/ElementTest.java Line 360: trailing spaces. -- To view, visit https://gwt-review.googlesource.com/2975 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib24bee7fa494c0345a7bc97e1b5df1095a05d024 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roy Paterson Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Make Element.hasTagName(...) case-insensitive.
Daniel Kurka has posted comments on this change. Change subject: Make Element.hasTagName(...) case-insensitive. .. Patch Set 4: Code-Review+1 LGTM, please address Manuel's comment -- To view, visit https://gwt-review.googlesource.com/2975 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib24bee7fa494c0345a7bc97e1b5df1095a05d024 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roy Paterson Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Make Element.hasTagName(...) case-insensitive.
Manuel Carrasco Moñino has posted comments on this change. Change subject: Make Element.hasTagName(...) case-insensitive. .. Patch Set 5: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/2975 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib24bee7fa494c0345a7bc97e1b5df1095a05d024 Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roy Paterson Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Roy Paterson Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Make Element.hasTagName(...) case-insensitive.
Thomas Broyer has posted comments on this change. Change subject: Make Element.hasTagName(...) case-insensitive. .. Patch Set 5: Code-Review+2 -- To view, visit https://gwt-review.googlesource.com/2975 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib24bee7fa494c0345a7bc97e1b5df1095a05d024 Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roy Paterson Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Roy Paterson Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Make Element.hasTagName(...) case-insensitive.
Daniel Kurka has posted comments on this change. Change subject: Make Element.hasTagName(...) case-insensitive. .. Patch Set 5: Code-Review+2 LGTM You can submit this change now using the publish & submit button -- To view, visit https://gwt-review.googlesource.com/2975 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib24bee7fa494c0345a7bc97e1b5df1095a05d024 Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roy Paterson Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Roy Paterson Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Make Element.hasTagName(...) case-insensitive.
Hello Manuel Carrasco Moñino, Daniel Kurka, Goktug Gokdogan, I'd like you to reexamine a rebased change. Please visit https://gwt-review.googlesource.com/2975 to look at the new rebased patch set (#6). Change subject: Make Element.hasTagName(...) case-insensitive. .. Make Element.hasTagName(...) case-insensitive. Helpful because the various Element TAG constants are in lower-case, but Element.getTagName() returns upper-case. Fixes issue 7756. Change-Id: Ib24bee7fa494c0345a7bc97e1b5df1095a05d024 --- M user/src/com/google/gwt/dom/client/Element.java M user/test/com/google/gwt/dom/client/ElementTest.java 2 files changed, 13 insertions(+), 1 deletion(-) -- To view, visit https://gwt-review.googlesource.com/2975 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: Ib24bee7fa494c0345a7bc97e1b5df1095a05d024 Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roy Paterson Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Roy Paterson Gerrit-Reviewer: Thomas Broyer -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] GWT style: Trailing spaces
Yep I have a similar setup in eclipse: remove trailing spaces when saving. On Tue, Jun 4, 2013 at 10:09 PM, Goktug Gokdogan wrote: > In Eclipse, I use auto-format on save for "edited lines". > If it is a javadoc, it forces you to use correct javadoc tags however for > regular multiine comments if you do some ascii art, then auto-format can > mess it up. In those cases, I simply press Ctrl+Z which just reverts the > last auto-format. It is not ideal but it is reasonable to work with for me. > > > On Tue, Jun 4, 2013 at 11:23 AM, Manuel Carrasco Moñino > wrote: > >> Hi All, >> >> This thread is to continue a conversation in gerrit [1] about trailing >> spaces at the end of lines. >> >> GWT convention is not to leave spaces at the end of lines, but some IDEs >> add them by default like Eclipse in empty javadoc lines. >> >> Maybe we want to relax this rule, or perhaps we could remove this warning >> from gerrit, I think it's a bit upsetting seeing those spaces in red. >> >> - Manolo >> >> >> >> >> [1] >> https://gwt-review.googlesource.com/#/c/1031/1/dev/core/src/com/google/gwt/util/tools/shared/StringUtils.java >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> --- >> You received this message because you are subscribed to the Google Groups >> "GWT Contributors" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Make Element.hasTagName(...) case-insensitive.
Thomas Broyer has posted comments on this change. Change subject: Make Element.hasTagName(...) case-insensitive. .. Patch Set 6: Code-Review+2 Grrr, Jenkins really doesn't want to pick it up to give its Verified+1. -- To view, visit https://gwt-review.googlesource.com/2975 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib24bee7fa494c0345a7bc97e1b5df1095a05d024 Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roy Paterson Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Roy Paterson Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] widget interfaces
Hi, Bringing this up again, but I'd like to submit a CL that moves the IsButton, IsListBox, etc., interfaces I've made for Tessell into GWT itself. IMO they would be useful to users doing MVP. I believe the only recent objection was from Goktug, who wanted to take the opportunity to make the widget API better, more-modern, non-sucky. My assertion is that is a perfectly fine goal, but should be done separately from the IsButton/etc. interfaces I'm proposing. AFAICT there's no reason we couldn't have IsButton go in today, which matches the old-school Button API directly, and then eventually have a next-gen Button/whatever that has a new/better API. Also, I would anticipate the newer/better widgets being more of a clean break anyway, so why not let the old widgets keep their current API, if now just codified in interfaces? Goktug, does that sound okay? Any other concerns? - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] serializing final fields
Hey, So, there is a CL out there that I have kinda/sorta been shepherding along to add support to GWT-RPC for final fields. The current CL is kinda complicated right now, because we have at least two flags about whether to turn final-fields on/off and also whether to warn about it when it is off. Seems like things would just be a lot simpler if we could say, screw it, final fields are always serialized. No options, no warnings. It just works. If we were building GWT-RPC from scratch, this is how it would work. However, previously in the "we can never break anything ever"-era of GWT, this was deemed a breaking change and so not allowed. Given we seem to have lightened up on that, I'd like to re-ask, how about for GWT 2.6, final fields are always serialized, no options, no warnings, it just works? Any -1s? Otherwise I'll assume it's okay and move the CL over to Gerrit and simplify it. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: widget interfaces
Kind of funny that I was just thinking about your old thread and Goktugs answer that he wants to try some new ways of writing widgets. Just wondering if he already came up with something :) I would definitely prefer starting from zero without IE 6-8 in mind for new widgets. I think adding interfaces would be ok, although I am not sure if I would ever need an interface for such low level widgets like checkbox, textbox, button, etc. They are wrapped anyways in larger views which just have meaningful setters to fill them. And using UiBinder you probably also have an interface to delegate UI events to a presenter. So what would be the added benefit in terms of MVP? I don't have real concerns about adding these interface as they dont hurt but I am just curious about how useful they really are for developers that already use MVP + UiBinder + Event delegate interface. -- J. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Fixes a NPE in RF when returning a null entity while the cli...
Manuel Carrasco Moñino has posted comments on this change. Change subject: Fixes a NPE in RF when returning a null entity while the client used .with(). .. Patch Set 1: Code-Review+1 LGTM -- To view, visit https://gwt-review.googlesource.com/2570 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I07c4b6d94fd063d76f205070047fd5f9e32c190b Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Thomas Broyer Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Matthew Dempsky Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Make Element.hasTagName(...) case-insensitive.
Manuel Carrasco Moñino has posted comments on this change. Change subject: Make Element.hasTagName(...) case-insensitive. .. Patch Set 6: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/2975 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib24bee7fa494c0345a7bc97e1b5df1095a05d024 Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roy Paterson Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Roy Paterson Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Hi Jens, > I would definitely prefer starting from zero without IE 6-8 in mind > for new widgets. With new widgets, definitely agree, I just think that's orthogonal to adding interfaces for the existing widgets. > So what would be the added benefit in terms of MVP? In the Type 1 style of MVP, the view interface exposes widgets directly to the presenter, albeit via the HasXxx characteristic interfaces. This can get annoying if you need multiple characteristics exposed for a single widget, or need to call a method that is not in a HasXxx interface. I think both of those points make the unified widget interfaces useful, and, IMO, they're much cleaner than hacks like faking out GWT.create to mock concrete classes like TextBox. So, I think the interfaces are worthwhile of their own accord. As to why I personally am extra fond of them, once you can look at a ui.xml file and deterministically say a gwt:TextBox should be exposed as an IsTextBox (vs. having to know did the programmer want HasValue? HasClickHandlers?), then you can generate the view interface and UiBinder implementation file automatically. Which is what Tessell does. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types -Byte.compare -...
John A. Tamplin has posted comments on this change.
Change subject: adding compare for several number types -Byte.compare
-Short.compare -Integer.compare -Long.compare -Float.compare (Double
already exists) fixes issue 7998
..
Patch Set 9: -Code-Review
(4 comments)
File user/super/com/google/gwt/emul/java/lang/Float.java
Line 37: if (isNaN(x)) {
You have to make sure those comparisons behave as desired when one or both
operands are NaNs.
File user/super/com/google/gwt/emul/java/lang/Integer.java
Line 61: return signum(x - y);
The spec of the Javadoc doesn't care, so anyone that writes code that
depends on implementation details, whether our own JRE emulation or
different JVMs, deserves whatever pain they get.
File user/test/com/google/gwt/emultest/java/lang/FloatTest.java
Line 81: }
Floating point varies significantly across all browsers. At least when I
was working on it, Safari JSCore steals bits from floats for tag values, so
there are some values that aren't representable there and you get different
roundoff than other engines.
I don't believe you can type "-0" in JS, but there are other ways to
generate them. I seem to recall code in Dan's float-to-int bytes tests
that generated them.
File user/test/com/google/gwt/emultest/java/lang/IntegerTest.java
Line 120: assertEquals(0, Integer.compare(1, 1));
We already say in the JRE compatibility doc that we don't handle integer
overflows. However, people aren't going to think of a comparison as an
integer overflow case, so if we can handle it cheaply we should.
After MAX_VALUE - MIN_VALUE overflows, what happens after the result is
coerced to an int? If we can't deal with the overflow after the fact, we
would need to check for overflow before doing the comparison.
Or, maybe that is why we didn't use subtraction in the first place.
--
To view, visit https://gwt-review.googlesource.com/3180
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246
Gerrit-PatchSet: 9
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Goktug Gokdogan
Gerrit-Reviewer: John A. Tamplin
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Thomas Broyer
Gerrit-HasComments: Yes
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate java.util.Objects
Hello John A. Tamplin, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/3184 to look at the new patch set (#8). Change subject: Emulate java.util.Objects .. Emulate java.util.Objects Fixes issue 8173 Change-Id: I15a10e7c52eb39baac2c22b9f6596ad0a5c1c599 --- M user/super/com/google/gwt/emul/java/util/Arrays.java A user/super/com/google/gwt/emul/java/util/Objects.java M user/test/com/google/gwt/emultest/EmulSuite.java A user/test/com/google/gwt/emultest/java/util/ObjectsTest.java 4 files changed, 213 insertions(+), 58 deletions(-) -- To view, visit https://gwt-review.googlesource.com/3184 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I15a10e7c52eb39baac2c22b9f6596ad0a5c1c599 Gerrit-PatchSet: 8 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: John A. Tamplin Gerrit-Reviewer: Ray Cromwell Gerrit-Reviewer: Ray Cromwell Gerrit-Reviewer: Thomas Broyer -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types -Byte.compare -...
Goktug Gokdogan has posted comments on this change. Change subject: adding compare for several number types -Byte.compare -Short.compare -Integer.compare -Long.compare -Float.compare (Double already exists) fixes issue 7998 .. Patch Set 9: (1 comment) File user/super/com/google/gwt/emul/java/lang/Integer.java Line 61: return signum(x - y); ".. deserves whatever pain they get" =) I would not try hard for something like this but currently I don't see any good reason to make this behave different than the de facto JDK. -- To view, visit https://gwt-review.googlesource.com/3180 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246 Gerrit-PatchSet: 9 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: John A. Tamplin Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate java.util.Objects
John A. Tamplin has posted comments on this change. Change subject: Emulate java.util.Objects .. Patch Set 8: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/3184 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I15a10e7c52eb39baac2c22b9f6596ad0a5c1c599 Gerrit-PatchSet: 8 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: John A. Tamplin Gerrit-Reviewer: Ray Cromwell Gerrit-Reviewer: Ray Cromwell Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate java.util.Objects
Ray Cromwell has posted comments on this change. Change subject: Emulate java.util.Objects .. Patch Set 8: Code-Review+2 -- To view, visit https://gwt-review.googlesource.com/3184 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I15a10e7c52eb39baac2c22b9f6596ad0a5c1c599 Gerrit-PatchSet: 8 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: John A. Tamplin Gerrit-Reviewer: Ray Cromwell Gerrit-Reviewer: Ray Cromwell Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] widget interfaces
Yeah, agreed; we will very likely need a cleaner plate so it is ok from my side for the IsXXX interfaces. If nobody else has any other concerns, I recommend you to start with an example interface to get early feedback and iterate from there. On Wed, Jun 5, 2013 at 8:57 AM, Stephen Haberman wrote: > Hi, > > Bringing this up again, but I'd like to submit a CL that moves the > IsButton, IsListBox, etc., interfaces I've made for Tessell into GWT > itself. IMO they would be useful to users doing MVP. > > I believe the only recent objection was from Goktug, who wanted to take > the opportunity to make the widget API better, more-modern, non-sucky. > > My assertion is that is a perfectly fine goal, but should be done > separately from the IsButton/etc. interfaces I'm proposing. AFAICT > there's no reason we couldn't have IsButton go in today, which matches > the old-school Button API directly, and then eventually have a next-gen > Button/whatever that has a new/better API. > > Also, I would anticipate the newer/better widgets being more of a clean > break anyway, so why not let the old widgets keep their current API, > if now just codified in interfaces? > > Goktug, does that sound okay? Any other concerns? > > - Stephen > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
The general idea is to use custom elements + html templates which can be extended for uibinder like support and/or data binding. I have been dealing with bugs so I didn't have much progress in that last weeks; my goal is to make the idea more clear before the end of the Q2. On Wed, Jun 5, 2013 at 9:39 AM, Jens wrote: > Kind of funny that I was just thinking about your old thread and Goktugs > answer that he wants to try some new ways of writing widgets. Just > wondering if he already came up with something :) I would definitely prefer > starting from zero without IE 6-8 in mind for new widgets. > > I think adding interfaces would be ok, although I am not sure if I would > ever need an interface for such low level widgets like checkbox, textbox, > button, etc. They are wrapped anyways in larger views which just have > meaningful setters to fill them. And using UiBinder you probably also have > an interface to delegate UI events to a presenter. So what would be the > added benefit in terms of MVP? I don't have real concerns about adding > these interface as they dont hurt but I am just curious about how useful > they really are for developers that already use MVP + UiBinder + Event > delegate interface. > > -- J. > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Change DOM access in HTMLTable for IE
Daniel Kurka has uploaded a new change for review.
https://gwt-review.googlesource.com/3212
Change subject: Change DOM access in HTMLTable for IE
..
Change DOM access in HTMLTable for IE
using table.rows or table.rows[i].cells
causes memory leaks in IE
Added two different implementations
to access table rows and cells. One for
IE and one for the rest
fixes issue 6938
Change-Id: I5789589a307f457a1295b9ed72111ad4c040fa97
---
A user/src/com/google/gwt/user/HTMLTable.gwt.xml
M user/src/com/google/gwt/user/User.gwt.xml
M user/src/com/google/gwt/user/client/ui/FlexTable.java
M user/src/com/google/gwt/user/client/ui/HTMLTable.java
4 files changed, 136 insertions(+), 23 deletions(-)
diff --git a/user/src/com/google/gwt/user/HTMLTable.gwt.xml
b/user/src/com/google/gwt/user/HTMLTable.gwt.xml
new file mode 100644
index 000..18ded5d
--- /dev/null
+++ b/user/src/com/google/gwt/user/HTMLTable.gwt.xml
@@ -0,0 +1,37 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ class="com.google.gwt.user.client.ui.HTMLTable.HTMLTableStandardImpl">
+class="com.google.gwt.user.client.ui.HTMLTable.HTMLTableImpl"/>
+
+
+
+ class="com.google.gwt.user.client.ui.HTMLTable.HTMLTableIEImpl">
+class="com.google.gwt.user.client.ui.HTMLTable.HTMLTableImpl"/>
+
+
+
+
+
+
+
diff --git a/user/src/com/google/gwt/user/User.gwt.xml
b/user/src/com/google/gwt/user/User.gwt.xml
index 5f9b89c..1cf42ef 100644
--- a/user/src/com/google/gwt/user/User.gwt.xml
+++ b/user/src/com/google/gwt/user/User.gwt.xml
@@ -48,6 +48,7 @@
+
diff --git a/user/src/com/google/gwt/user/client/ui/FlexTable.java
b/user/src/com/google/gwt/user/client/ui/FlexTable.java
index 5eecb9c..5ec2999 100644
--- a/user/src/com/google/gwt/user/client/ui/FlexTable.java
+++ b/user/src/com/google/gwt/user/client/ui/FlexTable.java
@@ -16,7 +16,6 @@
package com.google.gwt.user.client.ui;
import com.google.gwt.user.client.DOM;
-import com.google.gwt.user.client.Element;
/**
* A flexible table that creates cells on demand. It can be jagged (that
is,
@@ -91,14 +90,6 @@
DOM.setElementPropertyInt(ensureElement(row, column), "rowSpan",
rowSpan);
}
}
-
- private static native void addCells(Element table, int row, int num)/*-{
-var rowElem = table.rows[row];
-for(var i = 0; i < num; i++){
- var cell = $doc.createElement("td");
- rowElem.appendChild(cell);
-}
- }-*/;
public FlexTable() {
super();
diff --git a/user/src/com/google/gwt/user/client/ui/HTMLTable.java
b/user/src/com/google/gwt/user/client/ui/HTMLTable.java
index 05e528f..2d43f24 100644
--- a/user/src/com/google/gwt/user/client/ui/HTMLTable.java
+++ b/user/src/com/google/gwt/user/client/ui/HTMLTable.java
@@ -15,6 +15,7 @@
*/
package com.google.gwt.user.client.ui;
+import com.google.gwt.core.shared.GWT;
import com.google.gwt.dom.client.Document;
import com.google.gwt.dom.client.TableCellElement;
import com.google.gwt.dom.client.TableRowElement;
@@ -27,9 +28,9 @@
import com.google.gwt.event.dom.client.DragEnterEvent;
import com.google.gwt.event.dom.client.DragEnterHandler;
import com.google.gwt.event.dom.client.DragEvent;
+import com.google.gwt.event.dom.client.DragHandler;
import com.google.gwt.event.dom.client.DragLeaveEvent;
import com.google.gwt.event.dom.client.DragLeaveHandler;
-import com.google.gwt.event.dom.client.DragHandler;
import com.google.gwt.event.dom.client.DragOverEvent;
import com.google.gwt.event.dom.client.DragOverHandler;
import com.google.gwt.event.dom.client.DragStartEvent;
@@ -63,6 +64,84 @@
@SuppressWarnings("deprecation")
public abstract class HTMLTable extends Panel implements
SourcesTableEvents,
HasAllDragAndDropHandlers, HasClickHandlers, HasDoubleClickHandlers {
+
+ public interface HTMLTableImpl {
+
+public Element getRow(Element elem, int row);
+
+public int getDOMCellCount(Element tableBody, int row);
+
+public int getDOMRowCount(Element elem);
+
+public void addCells(Element table, int row, int num);
+
+public Element getCellElement(Element table, int row, int col);
+
+ }
+
+ public static class HTMLTableStandardImpl implements HTMLTableImpl {
+
+@Override
+public native Element getRow(Element elem, int row) /*-{
+ return elem.rows[row];
+}-*/;
+
+@Override
+public native int getDOMCellCount(Element tableBody, int row) /*-{
+ return tableBody.rows[row].cells.length;
+}-*/;
+
+@Override
+public native int getDOMRowCount(Element elem) /*-{
+ return elem.rows.length;
+}-*/;
+
+@Override
+public native void addCells(Element table, int row, int num) /*-{
+ var rowElem = table.rows[row];
+ for(var i = 0; i < num; i++){
+var cell = $doc.createElement("td");
+rowElem.appendChild(cell);
+ }
+}-*/;
+
+@Override
+public native Element get
[gwt-contrib] Change in gwt[master]: Use JSON.parse() instead of eval() to deserialize rpc callba...
Brian Slesinsky has posted comments on this change. Change subject: Use JSON.parse() instead of eval() to deserialize rpc callback payload .. Patch Set 5: (3 comments) I like where this is going. As I understand it, all clients will support parsing 7 and 8 messages. When the server creates a message it can be 7 or 8 depending on the system property, defaulting to 7. Client-created messages are always version 7. But it seems confusing that version 8 messages are sometimes JSON and sometimes not. It seems like if we decide to apply a hack we should set the version back to 7, so that version 7 messages are always non-JSON and version 8 messages are always JSON. That way we don't need a fallback when parsing; the version should always tell us what to do. File user/src/com/google/gwt/user/client/rpc/impl/ClientSerializationStreamReader.java Line 328 I think instead of deleting this check, we need to check that it's a version that this client knows how to decode. File user/super/com/google/gwt/user/translatable/com/google/gwt/user/client/rpc/impl/ClientSerializationStreamReader.java Line 60: int version = Integer.parseInt(versionStr); It's unclear how this works. Maybe extract a readVersion(String encoded) method and write a few tests with some example strings? Line 70: results = eval(encoded); I'm not sure we need a fallback? The server should have set the version correctly. -- To view, visit https://gwt-review.googlesource.com/2900 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I6062180397f5fabed1dd5f08140c2bd43a19fa9f Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: John Ahlroos Gerrit-Reviewer: Artur Signell Gerrit-Reviewer: Brian Slesinsky Gerrit-Reviewer: Colin Alworth Gerrit-Reviewer: John Ahlroos Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Matthew Dempsky Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
> > I would definitely prefer starting from zero without IE 6-8 in mind > > for new widgets. > > With new widgets, definitely agree, I just think that's orthogonal to > adding interfaces for the existing widgets. > Yep, agreed. > > So what would be the added benefit in terms of MVP? > > In the Type 1 style of MVP, the view interface exposes widgets directly > to the presenter, albeit via the HasXxx characteristic interfaces. This > can get annoying if you need multiple characteristics exposed for a > single widget, or need to call a method that is not in a HasXxx > interface. > Yeah this Type 1 style is really PITA in the long term, especially if views are a bit more complex. Its not just about exposing multiple characteristics of a single widget, its also about finding good names for these methods. I always had trouble with it. IMHO getPersonName().setValue() looks strange and anything else looks even stranger. Personally, I was never really pleased with this solution. However, with the release of UiBinder we constantly tell people/recommend to use the Type 2 style of MVP with UiBinder + @UiHandler and a delegate interface if they ask for MVP in gwt-discuss. So I think this argument looses some weight as probably no one really wants to do the type 1 way anymore and only a minority still choose it for new projects. So my concern is that nowadays developers that use MVP just dont need these interfaces anymore that badly. But these interfaces are probably nice to have for testing small widgets that self-contain their limited logic. You can then just cancel out Composite.initWidget() by overriding it during testing and then mock all fields. No need for GWTMockUtilities.disarm() or gwtmockito then. -- J. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent
Andrey Korzhevskiy has uploaded a new change for review.
https://gwt-review.googlesource.com/3171
Change subject: Support standardized DOM WheelEvent
..
Support standardized DOM WheelEvent
Fixes issue 8012
Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da
---
M user/src/com/google/gwt/event/dom/client/MouseWheelEvent.java
M user/src/com/google/gwt/user/client/impl/DOMImpl.java
M user/src/com/google/gwt/user/client/impl/DOMImplMozilla.java
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/user/src/com/google/gwt/event/dom/client/MouseWheelEvent.java
b/user/src/com/google/gwt/event/dom/client/MouseWheelEvent.java
index 33fc5ca..539cb25 100644
--- a/user/src/com/google/gwt/event/dom/client/MouseWheelEvent.java
+++ b/user/src/com/google/gwt/event/dom/client/MouseWheelEvent.java
@@ -31,6 +31,13 @@
static {
/**
+ * Hidden type used to ensure wheel event gets registered in the type
map.
+ * This is the standard event in DOM L3 which deprecates legacy
mousewheel and DOMMouseScroll events.
+ * https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
+ */
+new Type("wheel", new MouseWheelEvent());
+
+/**
* Hidden type used to ensure DOMMouseScroll gets registered in the
type map.
* This is the special name used on Mozilla browsers for what everyone
else
* calls 'mousewheel'.
diff --git a/user/src/com/google/gwt/user/client/impl/DOMImpl.java
b/user/src/com/google/gwt/user/client/impl/DOMImpl.java
index c5b8187..bf482d9 100644
--- a/user/src/com/google/gwt/user/client/impl/DOMImpl.java
+++ b/user/src/com/google/gwt/user/client/impl/DOMImpl.java
@@ -129,6 +129,7 @@
case "scroll": return 0x04000;
case "error": return 0x1;
case "mousewheel": return 0x2;
+case "wheel": return 0x2;
case "DOMMouseScroll": return 0x2;
case "contextmenu": return 0x4;
case "paste": return 0x8;
diff --git a/user/src/com/google/gwt/user/client/impl/DOMImplMozilla.java
b/user/src/com/google/gwt/user/client/impl/DOMImplMozilla.java
index eb08c98..4332af0 100644
--- a/user/src/com/google/gwt/user/client/impl/DOMImplMozilla.java
+++ b/user/src/com/google/gwt/user/client/impl/DOMImplMozilla.java
@@ -29,7 +29,8 @@
}
public native void disposeEventsMozilla(Element elem) /*-{
-elem.removeEventListener('DOMMouseScroll',
@com.google.gwt.user.client.impl.DOMImplStandard::dispatchEvent, false);
+var wheelEventName = 'onwheel' in $doc ? 'wheel' : 'DOMMouseScroll';
+elem.removeEventListener(wheelEventName,
@com.google.gwt.user.client.impl.DOMImplStandard::dispatchEvent, false);
}-*/;
@Override
@@ -40,7 +41,8 @@
public native void sinkEventsMozilla(Element elem, int bits) /*-{
if (bits & 0x2) {
- elem.addEventListener('DOMMouseScroll',
@com.google.gwt.user.client.impl.DOMImplStandard::dispatchEvent, false);
+ var wheelEventName = 'onwheel' in $doc ? 'wheel' : 'DOMMouseScroll';
+ elem.addEventListener(wheelEventName,
@com.google.gwt.user.client.impl.DOMImplStandard::dispatchEvent, false);
}
}-*/;
@@ -83,7 +85,8 @@
true
);
-$wnd.addEventListener('DOMMouseScroll',
@com.google.gwt.user.client.impl.DOMImplStandard::dispatchCapturedMouseEvent,
+var wheelEventName = 'onwheel' in $doc ? 'wheel' : 'DOMMouseScroll';
+$wnd.addEventListener(wheelEventName,
@com.google.gwt.user.client.impl.DOMImplStandard::dispatchCapturedMouseEvent,
true);
}-*/;
--
To view, visit https://gwt-review.googlesource.com/3171
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Andrey Korzhevskiy
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Change DOM access in HTMLTable for IE
Hello Leeroy Jenkins, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/3212 to look at the new patch set (#2). Change subject: Change DOM access in HTMLTable for IE .. Change DOM access in HTMLTable for IE using table.rows or table.rows[i].cells causes memory leaks in IE Added two different implementations to access table rows and cells. One for IE and one for the rest fixes issue 6938 Change-Id: I5789589a307f457a1295b9ed72111ad4c040fa97 Review-Link: https://gwt-review.googlesource.com/#/c/3212/ --- A user/src/com/google/gwt/user/HTMLTable.gwt.xml M user/src/com/google/gwt/user/User.gwt.xml M user/src/com/google/gwt/user/client/ui/FlexTable.java M user/src/com/google/gwt/user/client/ui/HTMLTable.java 4 files changed, 144 insertions(+), 23 deletions(-) -- To view, visit https://gwt-review.googlesource.com/3212 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I5789589a307f457a1295b9ed72111ad4c040fa97 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka Gerrit-Reviewer: Leeroy Jenkins -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Andrey Korzhevskiy has uploaded a new patch set (#2). Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel Fixes issue 8012 Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da --- M user/src/com/google/gwt/event/dom/client/MouseWheelEvent.java M user/src/com/google/gwt/user/client/impl/DOMImpl.java M user/src/com/google/gwt/user/client/impl/DOMImplStandard.java 3 files changed, 11 insertions(+), 1 deletion(-) -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Let me see if I understand this Type 1/2 discussion correctly:
yes, the short Has* interfaces are a bit of a pain: awkward names, mass of
small interfaces, must-use of class generics if you need to more Has*
interfaces.
Buttt, they make them very nice manageable through general Utils* methods..
For example: My root IsWidget interface:
public interface FlexWidget extends IsWidget, AsIsWidget, HasTitle,
HasVisible, HasStyleName, HasEnabled, HasEnsureDebugId, HasEventManagement
{}
And The HasStyleName look like:
public interface HasStyleName extends HasAddStyleName {
void setStyleName(final String style);
String getStyleName();
void removeStyleName(final String style);
}
---
In the UtilsWidget class I have all kind of methods like:
public static W addStyle(final W widget, final
String styleName) {
if (isNotNull(widget)) {
widget.addStyleName(styleName);
}
return widget;
}
public static W setStyle(final W widget, final
String styleName) {
if (isNotNull(widget)) {
widget.setStyleName(styleName);
}
return widget;
}
public static W ensureDebugId(final W widget,
final String debugId) {
if (isNotNull(widget)) {
widget.ensureDebugId(debugId);
}
return widget;
}
This makes coding safe, short and easy to understand/maintain (fluent
coding)...
Concerning implementation:
If you create a Is* widget like IsButton you have to think about when to
create the contains Widget variant like the Button class. I want to do this
as lazy as possible...
So the question is, if you call IsButton.addStyle(String), do you forward
this directly to the contained Button or do you buffer it? I buffer it,
such that I can run these operations in unit tests (not GWTTestCase...
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
> The general idea is to use custom elements + html templates which can be > extended for uibinder like support and/or data binding. > Sounds a bit like AngularJS directives for reusable components. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
> If you create a Is* widget like IsButton you have to think about when
> to create the contains Widget variant like the Button class.
No, for the simple case (that I am proposing anyway), it's just:
class Button implements IsButton {
// nothing else changes
}
So no lazily creation/delegation of methods/etc. At least in the
default widgets. If you want to do that with your own wrappers, that is
fine.
> I buffer it, such that I can run these operations in unit tests (not
> GWTTestCase...
The simpler thing than buffering is just to have a StubButton, e.g.:
class StubTextBox implements IsTextBox {
private String currentValue;
// get/set/etc.
}
Then you just need a factory/something somewhere, "newButton" that in
GWT code returns real Buttons and in test code returns StubButtons.
Tessell already has stubs for most widgets; I was going to explore
moving to GWT proper as well, after/if the widget interfaces are
accepted.
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Yes, more accurately it is html5 web components + related specs adapted to GWT. On Wed, Jun 5, 2013 at 2:09 PM, Jens wrote: > > The general idea is to use custom elements + html templates which can be >> extended for uibinder like support and/or data binding. >> > > Sounds a bit like AngularJS directives for reusable components. > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
> > The simpler thing than buffering is just to have a StubButton, e.g.: A, how could I forget ;)... I just remember the Stubs* Widgets in your gitHub ;) But is this even needed ? If you use a template mechanism it might not be needed. The template is created during setStyle() and other operations and only used in GWT client mode when the underlying "Widget" is created... -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
> Yeah this Type 1 style is really PITA in the long term, especially if > views are a bit more complex. I disagree; I actually prefer Type 1. Although to each their own, of course. > However, with the release of UiBinder we constantly tell > people/recommend to use the Type 2 style of MVP with UiBinder + > @UiHandler and a delegate interface if they ask for MVP in > gwt-discuss. UiHandler makes inner classes 2 lines shorter, but IMO it still leads to the same spaghetti code (reactive/imperative, instead of declarative). Tessell's binding DSL makes simple/common operations one line declarations (explicitly via Type 1-exposed widget interfaces, not UiHandlers). E.g. I don't see how UiHandlers/Type 2 could be as succinct as: https://github.com/stephenh/todomvc-tessell/blob/master/src/main/java/org/tessell/todomvc/client/app/TodoPresenter.java#L43 > So I think this argument looses some weight as probably no one really > wants to do the type 1 way anymore and only a minority still choose > it for new projects. Well, that is unfortunate, as MVP Type 1 with Tessell's view generation and binding DSL is quite pleasant. But, again, to each their own. :-) > No need for GWTMockUtilities.disarm() or gwtmockito then. Exactly. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
What are we looking at having in these interfaces? The discussion that Goktug and I had a few months ago got stalled around the concept that these interfaces were trying to both be a) implementation independent but also b) rich enough to be useful. Doing both is hard/meaningless. To pick an example, button has a few basic premises (in the standard GWT widgets) - it has text (or html if you support a base other than an ), it can receive focus, and it is a source of click events. In a perfect world an implementation could be backed by an appearance (perhaps wrapped itself in a cell) like the TextButton... But this ends up meaning that 'click' events aren't the only thing to worry about - a won't pass along key events like space or enter as a means of activating the button. So we either need to also emit key events, and touch events, or need to wrap all of these in one event (GXT calls it a SelectEvent). Either we have a backward compat problem (can't represent both past and future button-ish widgets with the same interface), or we limit the button implementations to a single setup (must be backed by or , or perhaps an ?). So, my point: Is the purpose of the IsButton *only* to be an interface for com.google.gwt.user.client.ui.Button? Or are we trying to build this out for the ideal button (and ideal text box, etc)? On Wed, Jun 5, 2013 at 4:28 PM, Ed wrote: > The simpler thing than buffering is just to have a StubButton, e.g.: > > A, how could I forget ;)... I just remember the Stubs* Widgets in your > gitHub ;) > > But is this even needed ? > If you use a template mechanism it might not be needed. > The template is created during setStyle() and other operations and only > used in GWT client mode when the underlying "Widget" is created... > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 218.248.6165 niloc...@gmail.com -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Slight follow up to both Stephen's comments here and my own prev post - If the interfaces are for existing, standard, built-in GWT widgets, type 2 makes a lot more sense, whereas for type 1, we really seem to need a general, ideal button that can be replaced by any implementation (with possibly any internal rebuilding via appearance/cells/etc). -Colin On Wed, Jun 5, 2013 at 4:36 PM, Stephen Haberman wrote: > > > Yeah this Type 1 style is really PITA in the long term, especially if > > views are a bit more complex. > > I disagree; I actually prefer Type 1. Although to each their own, of > course. > > > However, with the release of UiBinder we constantly tell > > people/recommend to use the Type 2 style of MVP with UiBinder + > > @UiHandler and a delegate interface if they ask for MVP in > > gwt-discuss. > > UiHandler makes inner classes 2 lines shorter, but IMO it still leads > to the same spaghetti code (reactive/imperative, instead of > declarative). > > Tessell's binding DSL makes simple/common operations one line > declarations (explicitly via Type 1-exposed widget interfaces, not > UiHandlers). E.g. I don't see how UiHandlers/Type 2 could be as > succinct as: > > > https://github.com/stephenh/todomvc-tessell/blob/master/src/main/java/org/tessell/todomvc/client/app/TodoPresenter.java#L43 > > > So I think this argument looses some weight as probably no one really > > wants to do the type 1 way anymore and only a minority still choose > > it for new projects. > > Well, that is unfortunate, as MVP Type 1 with Tessell's view generation > and binding DSL is quite pleasant. But, again, to each their own. :-) > > > No need for GWTMockUtilities.disarm() or gwtmockito then. > > Exactly. > > - Stephen > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 218.248.6165 niloc...@gmail.com -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
> > So, my point: Is the purpose of the IsButton *only* to be an interface for > com.google.gwt.user.client.ui.Button? Good point, when submitting my prev post, I was just think about: What problem is being solved here? Or What is improved ? Maybe good to summarize the list of goals and then work on them (like the white papers proposals in the gwt wiki). Either we have a backward compat problem I would start a separate IsWidget hierarchy. That makes it easier and overcomes all kind of conflicts and pain... People can then to decide them self if they want to use them.. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types -Byte.compare -...
Thomas Broyer has posted comments on this change. Change subject: adding compare for several number types -Byte.compare -Short.compare -Integer.compare -Long.compare -Float.compare (Double already exists) fixes issue 7998 .. Patch Set 9: (1 comment) File user/test/com/google/gwt/emultest/java/lang/FloatTest.java Line 81: } "-0" is valid JS, and 1/0 is Infinity while 1/-0 is -Infinity (per spec and tested in Chrome and Firefox). That said, we don't deal with that elsewhere. E.g. our Math.signum() emulations use >0 and <0 which won't distinguish +0 and -0. Math.signum(Double.NaN) is also broken BTW. This is fixable (with explicit isNaN and ==0 checks) but nobody complained so far. -- To view, visit https://gwt-review.googlesource.com/3180 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246 Gerrit-PatchSet: 9 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: John A. Tamplin Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
> UiHandler makes inner classes 2 lines shorter, but IMO it still leads > to the same spaghetti code (reactive/imperative, instead of > declarative). > > Tessell's binding DSL makes simple/common operations one line > declarations (explicitly via Type 1-exposed widget interfaces, not > UiHandlers). E.g. I don't see how UiHandlers/Type 2 could be as > succinct as: > > > https://github.com/stephenh/todomvc-tessell/blob/master/src/main/java/org/tessell/todomvc/client/app/TodoPresenter.java#L43 > > > > So I think this argument looses some weight as probably no one really > > wants to do the type 1 way anymore and only a minority still choose > > it for new projects. > > Well, that is unfortunate, as MVP Type 1 with Tessell's view generation > and binding DSL is quite pleasant. But, again, to each their own. :-) > Yeah but you can't really compare GWT proper to Tessell as your framework does probably generate quite some code to make all these declarative binding features possible as you always need to remember what to do once an action occurs. Also in Tessell one just leads to the other. You only have UiBinder xml and while generating the view implementation you have no idea what events the developer is interested in. So you are forced to expose all ui:field widgets/elements to allow the developer to do something with the view. Well and most *common/easy* things are then one liners through your binder to make life easy but complex things still require something like a command or you can't use the binder at all. So for slightly more complex things you also end up with anonymous classes. How these things play together in Tessel is totally fine as thats Tessell! :) But in GWT proper you don't have all these stuff. Tessell should not influence your motivation to integrate something into GWT proper (don't take me wrong on this). So if you stick to GWT proper and don't want to re-code Tessell then you probably stick to MVP Type 2. Once you do that, your view only has setter methods, gets really dump and is probably not worth testing through unit tests. In that case the Is* interfaces for GWT build-in widgets loose value. But, as already said, these Is* interfaces really make sense when you want to test simple composite widgets. Say you have a button and a textbox and once you click the button, the textfield should be validated and a custom event fired if everything is ok. In that case you wont do full blown MVP and having Is* interfaces for Button/TextBox available will be really handy for testing. So for this use case I would go for these Is* interfaces in GWT proper as they can encourage people to not use full blown MVP for everything while still being able to write non-hacky tests. @Colin: These interfaces are direct representations of current GWT widget classes. So its not "the ideal button interface". -- J. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Thomas Broyer has posted comments on this change. Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Patch Set 2: (1 comment) Is there any browser supporting that 'wheel' event and neither 'mousewheel' or 'DOMMouseScroll'? (in other words: is this worth the trouble?) I haven't checked either whether the WheelEvent is compatible with the legacy non-standard events re. our wrapping in NativeEvent. File user/src/com/google/gwt/user/client/impl/DOMImplStandard.java Line 329: if (chMask & 0x2) elem.onwheel = elem.onmousewheel = (bits & 0x2) ? According to the MDN, IE9 doesn't support onwheel (it only supports the 'wheel' event via addEventListener). Also, wouldn't registering both elem.onwheel and elem.onmousewheel lead to firing the MouseWheelEvent twice when both are supported? (according to MDN, no browser supports both *yet*, but in Mozilla, this code would register both onwheel and DOMMouseScroll, so the issue remains; that wasn't the case in the first patch) -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Andrey Korzhevskiy has posted comments on this change. Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Patch Set 2: Yes, it's Firefox. For now, gwt 2.5.1 doesn't fire mouse wheel events. I tested this patch in Firefox in MacOs and it works. -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Andrey Korzhevskiy Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Change DOM access in HTMLTable for IE
Thomas Broyer has posted comments on this change. Change subject: Change DOM access in HTMLTable for IE .. Patch Set 2: (2 comments) Should we rather move that to c.g.g.dom (Table*Element have .rows and .cells) and rewrite the JSNI in HTMLTable to use the c.g.g.dom JSO wrappers? Also, what would it do if we used the IE implementation everywhere? (IIRC, children might contain text nodes in other browsers whereas IE only includes elements there, and that would break in non-IE browsers then; am I right?) File user/src/com/google/gwt/user/HTMLTable.gwt.xml Line 2: 2013 Line 23: typo: is → if Also, I'm not a native-English speaker, but I think it should be "fall back" here rather than fall through. -- To view, visit https://gwt-review.googlesource.com/3212 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I5789589a307f457a1295b9ed72111ad4c040fa97 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Thomas Broyer has posted comments on this change. Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Patch Set 2: Does it mean your Firefox no longer fires DOMMouseScroll events? (because I tested in the JS console and mine one Linux still fires them) or that GWT no longer routes them as MouseWheelEvent? -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Andrey Korzhevskiy Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Andrey Korzhevskiy has posted comments on this change. Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Patch Set 2: (1 comment) File user/src/com/google/gwt/user/client/impl/DOMImplStandard.java Line 329: if (chMask & 0x2) elem.onwheel = elem.onmousewheel = (bits & 0x2) ? I think it's ok for Firefox because on MDN it is said if wheel event is consumed then DOMMouseScroll would not be fired. As for Microsoft, existing code should work as before -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Andrey Korzhevskiy Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Thomas Broyer has posted comments on this change. Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Patch Set 2: (1 comment) File user/src/com/google/gwt/user/client/impl/DOMImplStandard.java Line 329: if (chMask & 0x2) elem.onwheel = elem.onmousewheel = (bits & 0x2) ? "existing code should work as before" …for now! But how about Chromium and WebKit when they'll add support for the 'wheel' event? -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Andrey Korzhevskiy Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Fixes UiHandler method matching in generic classes
Goktug Gokdogan has uploaded a new change for review.
https://gwt-review.googlesource.com/3250
Change subject: Fixes UiHandler method matching in generic classes
..
Fixes UiHandler method matching in generic classes
Method matching in UiHandler is completely broken for generic
ui fields as FieldWriterOfExistingType is using the raw type
of the ui field. Raw type of a generic field erases all generics
from the method signature. This was causing type parameter information
to be not used while matching methods. This is a huge problem with
some common events like SelectEvent and ValueChangeEvent.
We were not hitting the problem in some cases because JRawType is
broken and doesn't correctly delete the generics from the signature
of parent methods. However that was causing another problem:
UiBinder uses the type information for ui.xml so it doesn't really
know the type parameters so it can't match generics methods from the
parent class (Issue 6091).
This fix changes the UiBinder generator so that
- it will enhance the type information if there is a @uifield declaration
- it will not use raw type in FieldWriterOfExistingType
- it will fallback to erase type if it can't find any method match
Bugs: Issue 6091
Change-Id: I3121542b6eb4f06f36b88b02006b155422c45726
---
M user/src/com/google/gwt/uibinder/rebind/FieldWriterOfExistingType.java
M user/src/com/google/gwt/uibinder/rebind/HandlerEvaluator.java
M
user/test/com/google/gwt/uibinder/rebind/FieldWriterOfExistingTypeTest.java
A
user/test/com/google/gwt/uibinder/test/client/ExtendsValueChangeWidget.java
M user/test/com/google/gwt/uibinder/test/client/UiHandlerTest.java
A user/test/com/google/gwt/uibinder/test/client/ValueChangeWidget.java
M user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.java
M user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.ui.xml
D
user/test/com/google/gwt/uibinder/test/client/WildcardValueChangeWidget.java
9 files changed, 239 insertions(+), 153 deletions(-)
diff --git
a/user/src/com/google/gwt/uibinder/rebind/FieldWriterOfExistingType.java
b/user/src/com/google/gwt/uibinder/rebind/FieldWriterOfExistingType.java
index c6d8a35..46e5b73 100644
--- a/user/src/com/google/gwt/uibinder/rebind/FieldWriterOfExistingType.java
+++ b/user/src/com/google/gwt/uibinder/rebind/FieldWriterOfExistingType.java
@@ -16,7 +16,6 @@
package com.google.gwt.uibinder.rebind;
import com.google.gwt.core.ext.typeinfo.JClassType;
-import com.google.gwt.core.ext.typeinfo.JGenericType;
/**
* Implementation of FieldWriter for fields whose type already exists
(that is,
@@ -33,12 +32,6 @@
if (type == null) {
throw new IllegalArgumentException("type cannot be null");
}
-
-JGenericType genericType = type.isGenericType();
-if (genericType != null) {
- type = genericType.getRawType();
-}
-
this.type = type;
}
diff --git a/user/src/com/google/gwt/uibinder/rebind/HandlerEvaluator.java
b/user/src/com/google/gwt/uibinder/rebind/HandlerEvaluator.java
index cc7bc2c..cae7dc4 100644
--- a/user/src/com/google/gwt/uibinder/rebind/HandlerEvaluator.java
+++ b/user/src/com/google/gwt/uibinder/rebind/HandlerEvaluator.java
@@ -23,8 +23,10 @@
import com.google.gwt.core.ext.typeinfo.JType;
import com.google.gwt.core.ext.typeinfo.TypeOracle;
import com.google.gwt.event.shared.EventHandler;
+import com.google.gwt.event.shared.HandlerRegistration;
import com.google.gwt.uibinder.client.UiHandler;
import com.google.gwt.uibinder.rebind.model.OwnerClass;
+import com.google.gwt.uibinder.rebind.model.OwnerField;
import com.google.web.bindery.event.shared.HandlerRegistration;
/**
@@ -153,10 +155,13 @@
("Method '%s' can not be bound. You probably missed
ui:field='%s' "
+ "in the template."), boundMethod, objectName);
}
+JClassType objectType = fieldWriter.getInstantiableType();
+if (objectType.isGenericType() != null) {
+ objectType = tryEnhancingTypeInfo(objectName, objectType);
+}
// Retrieves the "add handler" method in the object.
-JMethod addHandlerMethodType = getAddHandlerMethodForObject(
-fieldWriter.getInstantiableType(), handlerType);
+JMethod addHandlerMethodType =
getAddHandlerMethodForObject(objectType, handlerType);
if (addHandlerMethodType == null) {
logger.die("Field '%s' does not have an 'add%s' method
associated.",
objectName, handlerType.getName());
@@ -167,6 +172,23 @@
addHandlerMethodType.getName(), objectName);
}
}
+ }
+
+ private JClassType tryEnhancingTypeInfo(String objectName, JClassType
objectType) {
+OwnerField uiField = ownerClass.getUiField(objectName);
+if (uiField != null) {
+ JParameterizedType pType = uiField.getRawType().isParameterized();
+ if (pType != null) {
+// Even field is para
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Andrey Korzhevskiy has posted comments on this change. Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Patch Set 2: I mean, I cannot get mouse wheel event on gwt widget. I created issue back in February when I wanted to listen mousewheel events on canvas. -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Andrey Korzhevskiy Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Andrey Korzhevskiy has posted comments on this change. Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Patch Set 2: (1 comment) File user/src/com/google/gwt/user/client/impl/DOMImplStandard.java Line 329: if (chMask & 0x2) elem.onwheel = elem.onmousewheel = (bits & 0x2) ? You mean, there could be problem with firing two events instead of one? Maybe there should be a check to test if browser supports standard wheel event? -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Andrey Korzhevskiy Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Thomas Broyer has posted comments on this change. Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Patch Set 2: (1 comment) Shouldn't we fix our DOMMouseScroll event handling then? (it might be broken in Firefox versions older than 17) To be honest, it depends whether we want to support Firefox versions before 17; Mozilla no longer supports them; if we no longer support them too, then we can simply replace the DOMMouseScroll with onwheel in DOMImplMozilla, similar to what you did in the first patch. For now, I think we support all Firefox versions back to 3.6 (possibly partly because our version of HTMLUnit emulates Firefox 3.6) All in all, I think I preferred the patch set 1, more future-proof. Also, IIUC, c.g.g.dom.client.DOMImplMozilla#eventGetMouseWheelVelocityY should probably be changed to return e.detail || e.deltaY || 0; or return e.deltaY || e.detail || 0; File user/src/com/google/gwt/user/client/impl/DOMImplStandard.java Line 329: if (chMask & 0x2) elem.onwheel = elem.onmousewheel = (bits & 0x2) ? Yes, that's what I mean; let's try to be future-proof. BTW, a DOMMouseScroll will be fired in addition to a wheel event *unless* the wheel event is consumed using preventDefault(), so we should listen to either one of onwheel or DOMMouseScroll but not both. -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Andrey Korzhevskiy Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Fixes UiHandler method matching in generic classes
Hello Leeroy Jenkins, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/3250 to look at the new patch set (#2). Change subject: Fixes UiHandler method matching in generic classes .. Fixes UiHandler method matching in generic classes Method matching in UiHandler is completely broken for generic ui fields as FieldWriterOfExistingType is using the raw type of the ui field. Raw type of a generic field erases all generics from the method signature. This was causing type parameter information to be not used while matching methods. This is a huge problem with some common events like SelectEvent and ValueChangeEvent. We were not hitting the problem in some cases because JRawType is broken and doesn't correctly delete the generics from the signature of parent methods. However that was causing another problem: UiBinder uses the type information for ui.xml so it doesn't really know the type parameters so it can't match generics methods from the parent class (Issue 6091). This fix changes the UiBinder generator so that - it will enhance the type information if there is a @uifield declaration - it will not use raw type in FieldWriterOfExistingType - it will fallback to erase type if it can't find any method match Bugs: Issue 6091 Change-Id: I3121542b6eb4f06f36b88b02006b155422c45726 Review-Link: https://gwt-review.googlesource.com/#/c/3250/ --- M user/src/com/google/gwt/uibinder/rebind/FieldWriterOfExistingType.java M user/src/com/google/gwt/uibinder/rebind/HandlerEvaluator.java M user/test/com/google/gwt/uibinder/rebind/FieldWriterOfExistingTypeTest.java A user/test/com/google/gwt/uibinder/test/client/ExtendsValueChangeWidget.java M user/test/com/google/gwt/uibinder/test/client/UiHandlerTest.java A user/test/com/google/gwt/uibinder/test/client/ValueChangeWidget.java M user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.java M user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.ui.xml D user/test/com/google/gwt/uibinder/test/client/WildcardValueChangeWidget.java 9 files changed, 238 insertions(+), 153 deletions(-) -- To view, visit https://gwt-review.googlesource.com/3250 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I3121542b6eb4f06f36b88b02006b155422c45726 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Goktug Gokdogan Gerrit-Reviewer: Leeroy Jenkins -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Andrey Korzhevskiy has posted comments on this change. Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Patch Set 2: I agree but what about future versions of browsers? As for now webkit has open bug report, opera moving to blink. Someday they will get support for standard wheel event and we can provide consistent getMouseWheelVelocityY through e.deltaY -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Andrey Korzhevskiy Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Thomas Broyer has posted comments on this change. Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Patch Set 2: They'll likely to continue supporting onmousewheel, so it won't break GWT, and we then can add support for onwheel on more browsers. I still think we should start by investigating why DOMMouseScroll doesn't work for your use-case. -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Andrey Korzhevskiy Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Support standardized DOM WheelEvent https://developer.mozill...
Andrey Korzhevskiy has posted comments on this change. Change subject: Support standardized DOM WheelEvent https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel .. Patch Set 2: Ok -- To view, visit https://gwt-review.googlesource.com/3171 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia6e8cb62ea195ca9e0253a74b4fc6fafbe6183da Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy Gerrit-Reviewer: Andrey Korzhevskiy Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
On Wednesday, June 5, 2013 11:37:08 PM UTC+2, Colin Alworth wrote: > > What are we looking at having in these interfaces? The discussion that > Goktug and I had a few months ago got stalled around the concept that these > interfaces were trying to both be a) implementation independent but also b) > rich enough to be useful. Doing both is hard/meaningless. > > To pick an example, button has a few basic premises (in the standard GWT > widgets) - it has text (or html if you support a base other than an > ), it can receive focus, and it is a source of click events. In a > perfect world an implementation could be backed by an appearance (perhaps > wrapped itself in a cell) like the TextButton... > > But this ends up meaning that 'click' events aren't the only thing to > worry about - a won't pass along key events like space or enter as a > means of activating the button. So we either need to also emit key events, > and touch events, or need to wrap all of these in one event (GXT calls it a > SelectEvent). > > Either we have a backward compat problem (can't represent both past and > future button-ish widgets with the same interface), or we limit the button > implementations to a single setup (must be backed by or , > or perhaps an ?). > > So, my point: Is the purpose of the IsButton *only* to be an interface for > com.google.gwt.user.client.ui.Button? Or are we trying to build this out > for the ideal button (and ideal text box, etc)? If the former, then I understand it as mostly a mean to provide mocks/stubs/fakes for testing. How about gwt-mockito then? https://github.com/google/gwtmockito (I'd rather go with the latter, as you described above, which would mean it's only in "widgets 2" that Daniel has been talking about on the issue tracker) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] -validateOnly
Hi, Anyone knowns what the -validateOnly flag to the compiler does exactly? can it be reliably used to validate that all classes in a given module are * translatable*? I used it once but it was years ago so I don't remember what it checked exactly. AFAICT it didn't check that JSNI was valid JavaScript (understandable and not a blocker: if you have JSNI in a lib you should probably have unit-tests too) See also http://stackoverflow.com/q/16944701/116472 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: -validateOnly
I haven't look at the code, but I think it runs a precompile, and then stops. So it constructs the whole program AST and runs generators, so it runs all checking up to that point. I'm pretty sure it should be running JSORestrictionsChecker which runs on JDT I believe. On Wed, Jun 5, 2013 at 6:25 PM, Thomas Broyer wrote: > Hi, > > Anyone knowns what the -validateOnly flag to the compiler does exactly? > can it be reliably used to validate that all classes in a given module are > *translatable*? > I used it once but it was years ago so I don't remember what it checked > exactly. AFAICT it didn't check that JSNI was valid JavaScript > (understandable and not a blocker: if you have JSNI in a lib you should > probably have unit-tests too) > > See also http://stackoverflow.com/q/16944701/116472 > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
> So, my point: Is the purpose of the IsButton *only* to be an > interface for com.google.gwt.user.client.ui.Button? Or are we trying > to build this out for the ideal button (and ideal text box, etc)? Right, the former. That doesn't mean the latter isn't worth doing, just that I think it's a separate effort (because it would take awhile and having breaking changes anyway, while I think the widgets would benefit from these interfaces in the short-term and they are very simple to add.) - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] serializing final fields
I don't have a good idea about what could break, but who knows what we'll find. I think we will at least want a flag to turn it on and off. It might be temporary just to land the patch; not sure if it should survive until the 2.6 release. On Wed, Jun 5, 2013 at 9:03 AM, Stephen Haberman wrote: > Hey, > > So, there is a CL out there that I have kinda/sorta been shepherding > along to add support to GWT-RPC for final fields. > > The current CL is kinda complicated right now, because we have at least > two flags about whether to turn final-fields on/off and also whether to > warn about it when it is off. > > Seems like things would just be a lot simpler if we could say, screw > it, final fields are always serialized. No options, no warnings. It > just works. > > If we were building GWT-RPC from scratch, this is how it would work. > > However, previously in the "we can never break anything ever"-era of > GWT, this was deemed a breaking change and so not allowed. > > Given we seem to have lightened up on that, I'd like to re-ask, how > about for GWT 2.6, final fields are always serialized, no options, no > warnings, it just works? > > Any -1s? Otherwise I'll assume it's okay and move the CL over to Gerrit > and simplify it. > > - Stephen > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
> If the former, then I understand it as mostly a mean to provide > mocks/stubs/fakes for testing. How about gwt-mockito then? > https://github.com/google/gwtmockito This is tangenting a bit...but... :-) I know everyone uses them, but IMO mocks are less than ideal for testing UI code. With stubs, you can have state and semi-intelligent behavior without repeating every test the same "oh, right, this is how a textbox works...when call this, then return that, expect so and so", etc. That said, mocks are a personal preference, and while nifty tools like gwt-mockito exist for the current state of affairs, I don't think that means making life easier for everyone (by making the require for gwt-mockito go away) is a bad thing. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
> as your framework does probably generate quite some code to make > all these declarative binding features possible No, actually--the bindings don't have any code generation to them, either build-time or gwt-compile-time. They're pure Java, which means they run in unit tests (it would suck if they didn't...then too much logic/behavior wouldn't be testable). > You only have UiBinder xml and while generating the view > implementation you have no idea what events the developer is > interested in. So you are forced to expose all ui:field > widgets/elements to allow the developer to do something with the > view. Precisely. That is a good thing, IMO. Why is that a bad thing? It means the view is so dumb it doesn't (and *can't*) have any logic in it. (Sorry, feel free to treat that question as rhetorical if you want to drop the Tessell tangent. :-). > So for slightly more complex things you also end up with anonymous classes. Of course. But, speaking from experience, it's surprising how often that is not true. > Button/TextBox available will be really handy for testing. > So for this use case I would go for these Is* interfaces in GWT > proper as they can encourage people to not use full blown MVP for > everything while still being able to write non-hacky tests. Cool. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] serializing final fields
> I don't have a good idea about what could break I believe nothing would "break"--it's that final fields that were previously not going over the wire would now go over the wire. So, I guess technically that is a change in semantics--so it wouldn't be like "oh, your GWT app fails to compile", more like "you were doing *what* with that field...that doesn't work anymore". Or we're exposing a value over the wire that previously the developer knowingly made final so that it would not (seems pretty odd though...). > I think we will at least want a flag to turn it on and > off. It might be temporary just to land the patch; not sure if it > should survive until the 2.6 release. Okay, well, technically a flag for that already exists in the patch--I suppose we could land it as is and then hope to maybe remove it by 2.6 or there after. I was just hoping to simplify it. I'll plan to move it over to gerrit then... - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
On Wed, Jun 5, 2013 at 7:34 PM, Stephen Haberman wrote: > > > If the former, then I understand it as mostly a mean to provide > > mocks/stubs/fakes for testing. How about gwt-mockito then? > > https://github.com/google/gwtmockito > > This is tangenting a bit...but... :-) > > I know everyone uses them, but IMO mocks are less than ideal for > testing UI code. With stubs, you can have state and semi-intelligent > behavior without repeating every test the same "oh, right, this is how > a textbox works...when call this, then return that, expect so and so", > etc. > Just for the sake of correctness; You can still have similar stubs like you have today based on gwt-mockito (if you don't like mockito's 'expect' style). > > That said, mocks are a personal preference, and while nifty tools like > gwt-mockito exist for the current state of affairs, I don't think that > means > making life easier for everyone (by making the require for gwt-mockito go > away) > is a bad thing. > > - Stephen > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] serializing final fields
On Wed, Jun 5, 2013 at 10:46 PM, Stephen Haberman wrote: > > > I don't have a good idea about what could break > > I believe nothing would "break"--it's that final fields that were > previously not going over the wire would now go over the wire. > > So, I guess technically that is a change in semantics--so it wouldn't > be like "oh, your GWT app fails to compile", more like "you were doing > *what* with that field...that doesn't work anymore". Or we're exposing > a value over the wire that previously the developer knowingly made > final so that it would not (seems pretty odd though...). Yes, that is what we were worried about -- particularly that some Google internal app was putting some sensitive data in final fields and previous scrutiny didn't uncover it because it didn't go over the wire. Then, making final fields serializable would essentially be a leak of sensitive information. > > I think we will at least want a flag to turn it on and > > off. It might be temporary just to land the patch; not sure if it > > should survive until the 2.6 release. > > Okay, well, technically a flag for that already exists in the patch--I > suppose we could land it as is and then hope to maybe remove it by 2.6 > or there after. I was just hoping to simplify it. > > I'll plan to move it over to gerrit then... Does having the flag really make it that much more complicated? -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
> Just for the sake of correctness; > You can still have similar stubs like you have today based on > gwt-mockito (if you don't like mockito's 'expect' style). Ah, sorry, my fault for not looking in to it more. Thanks for the correction. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] serializing final fields
> Does having the flag really make it that much more complicated? It would not seem like it, but yes. :-) Specifically passing the context down through the layers to the right spot to say "do I serialize final fields?" took a bit--one of the first patches that went by used a static field to avoid a lot of method signatures, but it assumed only one GWT module/setting running at a time. It was also complicated by having to play nicely with the current "warn on finalize field" flag. Both of these are trivial in the big scheme of GWT-RPC, but every little simplification helps. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Use JSON.parse() instead of eval() to deserialize rpc callba...
John Ahlroos has posted comments on this change. Change subject: Use JSON.parse() instead of eval() to deserialize rpc callback payload .. Patch Set 5: (3 comments) File user/src/com/google/gwt/user/client/rpc/impl/ClientSerializationStreamReader.java Line 328 The check should probably be something like: (SERIALIZATION_STREAM_MIN_VERSION <= getVersion() && getVersion() <= SERIALIZATION_STREAM_MAX_VERSION) I'll add it back. File user/super/com/google/gwt/user/translatable/com/google/gwt/user/client/rpc/impl/ClientSerializationStreamReader.java Line 60: int version = Integer.parseInt(versionStr); The version number is always added last in the JSON array so it looks like this "[ ,7]". I just find the last ',' and last ']' and assume the value between is the version number. Sure I can extract it into a method and write some tests for it. Line 70: results = eval(encoded); The fallback is needed when the concat etc. hacks are applied and JSON.parse will fail since the message is not valid JSON. But if we change the server side implementation so that if the hacks are applied the version automatically becomes 7 then this indeed would not be needed. -- To view, visit https://gwt-review.googlesource.com/2900 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I6062180397f5fabed1dd5f08140c2bd43a19fa9f Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: John Ahlroos Gerrit-Reviewer: Artur Signell Gerrit-Reviewer: Brian Slesinsky Gerrit-Reviewer: Colin Alworth Gerrit-Reviewer: John Ahlroos Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Matthew Dempsky Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
