[gwt-contrib] [google-web-toolkit] e...@google.com commented on revision r4188.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4188. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4188 Score: Negative General Comment: Looks really good overall! Just a couple of nits... Showcase: Do we have reason to believe the translations added are correct or do we need to consult the tc folks? CWDatePicker: Why are we doing this line: datePicker.setValue(new Date()); Rather then using a TextBox that is not enabled, why not use a label? I think that would make it less confusing, given that we also have a date box on the page. Can we rename cwDatePickerBoxLabel to cwDateBoxLabel? DatePicker: Why did the FlowPanel become a VerticalPanel? I know you probably have a good reason, but it does mean less flexibility for styling the widget, so I think we might want to document what forced us to make this change. Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4188 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] e...@google.com commented on revision r4189.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4189. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4189 Score: Negative General Comment: I think we should remove them altogether rather then leaving commented out code. Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4189 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] e...@google.com commented on revision r4191.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4191. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4191 Score: Negative General Comment: DatePicker examples: Same comments as from the cw date picker, i.e. why the setValue + can we use a label instead of a text box? DateBox: This may actually be more for Ray, but why is the default date reporter public final? I think we might eventually want to include the ability to set the default, so leaving this public final would be misleading. DatePicker: Can we use the definition list rather then li/ul, as the definition list seems to actually format correctly! Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4191 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4193.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4193. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4193 Score: Positive General Comment: LGTM. Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4193 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Fwd: Review of handler map speed test.
Joel, Thank you so much for looking into this! Below is the review request that was originally directed to Kelly. Also, I've cut/pasted the initial benchmark results I got from it. The way I interpret them is that we may/may not have a significant problem depending upon how many handlers programs actually have. As you can imagine, the fact that the string manipulation is globally slowed down if we don't use the flattened data structure is what most concerns me, as if this is a realistic number of handlers for a production system and this benchmark holds true, we would be slowing down this sort of string operation by over 90%. == Start handlerMapForSimpleJs Test== Creating 5000 handlerMapForSimpleJs maps 78 millseconds, 78 millseconds, 78 millseconds Adding 6 handlers for 5000 to a handlerMapForSimpleJs 312 millseconds, 266 millseconds, 329 millseconds Fired 3 handlers for 5000 widgets using handlerMapForSimpleJs 157 millseconds, 156 millseconds, 156 millseconds created a random string with 3 handlers using handlerMapForSimpleJs 156 millseconds, 203 millseconds, 219 millseconds == Start handlerMapForJs Test== Creating 5000 handlerMapForJs maps 78 millseconds, 94 millseconds, 109 millseconds Adding 6 handlers for 5000 to a handlerMapForJs 188 millseconds, 171 millseconds, 187 millseconds Fired 3 handlers for 5000 widgets using handlerMapForJs 157 millseconds, 157 millseconds, 172 millseconds created a random string with 3 handlers using handlerMapForJs 109 millseconds, 94 millseconds, 94 millseconds == Start handlerMapForJava Test== Creating 5000 handlerMapForJava maps 172 millseconds, 172 millseconds, 172 millseconds Adding 6 handlers for 5000 to a handlerMapForJava 453 millseconds, 453 millseconds, 469 millseconds Fired 36 handlers for 5000 widgets using handlerMapForJava 312 millseconds, 312 millseconds, 312 millseconds created a random string with 3 handlers using handlerMapForJava 141 millseconds, 188 millseconds, 188 millseconds -- Forwarded message -- From: Emily Crutcher [EMAIL PROTECTED] Date: Mon, Nov 17, 2008 at 2:50 PM Subject: Review of handler map speed test. To: Kelly Norton [EMAIL PROTECTED], Ray Ryan [EMAIL PROTECTED], Google Web Toolkit Contributors Google-Web-Toolkit-Contributors@googlegroups.com Kelly, Could you review this visual benchmark I was using to compute the pros/cons of the different handler maps? Of particular interest is the SimpleJsHandlerMap, to see if there is anything, well, simple we we can do to make it faster. http://code.google.com/p/google-web-toolkit/source/detail?r=4089 -- There are only 10 types of people in the world: Those who understand binary, and those who don't -- There are only 10 types of people in the world: Those who understand binary, and those who don't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] rj...@google.com commented on revision r4191.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4191. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4191 Line-by-line comments: File: /branches/1_6_datepicker/user/javadoc/com/google/gwt/examples/DatePickerExample.java (r4191) === Line 45: datePicker.setValue(new Date(), true); --- I assume you're doing this to fill the text box? Like ecc implied, it's a bit of an unclean example, as the datePicker already has a value. How about instead refactor the guts of onValueChange into DatePickerExample#updateTextBox(Date), and at this line call updateTextBox(datePicker.getValue()); Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4191 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4193.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4193. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4193 General Comment: LGTM too Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4193 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4191.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4191. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4191 General Comment: quot;Like ecc implied, it's a bit of an unclean example, as the datePicker already has a value.quot; It already has a value? I don't see where it is initialized in DatePicker, so I don't think it has a default value. Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4191 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Update datetime symbols
OK. Let's get this in 1.6, then. Can we talk about getting the scripts open-sourced? They could be really helpful for other (external) projects. Shanjian, would that be interesting to you? On Mon, Dec 1, 2008 at 12:07 PM, Shanjian Li [EMAIL PROTECTED] wrote: The scripts exist in //google3/i18n/tools. I am using the same scripts to generate constants for Closure, GAE and possibly other apps. I am not sure if we should mention it. shanjian -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4071.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4071. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4071 Score: Positive General Comment: LGTM Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4071 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4093.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4093. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4093 Score: Positive General Comment: LGTM Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4093 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4137.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4137. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4137 Score: Negative General Comment: Looks like a late night goofey example. Goofey comments are fine when they're buried in obscure code, but we don't want to confuse people in the examples. Line-by-line comments: File: /releases/1.6/user/javadoc/com/google/gwt/examples/LazyPanelExample.java (r4137) === Line 30:* A friendly little LazyPanel. --- This might be a little cute. We usually don't include comments like these. Line 41: lazy.setVisible(false); --- setVisible(false) isn't needed and might confuse people Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4137 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4213 - changes/kprobst/soyc-vis/src/com/google/gwt/soyc
Author: [EMAIL PROTECTED]
Date: Mon Dec 1 08:44:27 2008
New Revision: 4213
Modified:
changes/kprobst/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
Log:
Small update for string literal layout.
Modified:
changes/kprobst/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
==
---
changes/kprobst/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
(original)
+++
changes/kprobst/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
Mon Dec 1 08:44:27 2008
@@ -430,6 +430,9 @@
+
+
+
public static void makePackageClassesHtmls() throws IOException{
for (String packageName : GlobalInformation.packageToClasses.keySet()){
@@ -653,6 +656,8 @@
+
+
public static void makeLiteralsClassesHtmls(TreeMapString,
LiteralsCollection nameToLitColl) throws IOException{
@@ -666,7 +671,7 @@
outFile.println(html);
outFile.println(head);
outFile.println(meta http-equiv=\content-type\
content=\text/html;charset=ISO-8859-1\);
- outFile.println(titleLiterals of type + literalType
+ /title);
+ outFile.println(titleLiterals of type \ + literalType
+ \/title);
outFile.println(/head);
outFile.println(style type=\text/css\);
@@ -690,7 +695,7 @@
outFile.println(});
outFile.println(.rowdiv {);
outFile.println(display: table-row;);
- outFile.println(width:100%;);
+ //outFile.println(width:90%;);
outFile.println(});
outFile.println(/style);
@@ -701,15 +706,51 @@
outFile.println(hr);
outFile.println(div style=\width:90%; height:80%;
overflow-y:auto; overflow-x:auto; top: 30px; left:60px; position:relative;
background-color:white\);
- outFile.println(div class=\tablediv\);
+ outFile.println(div class=\tablediv\);
for (String literal :
nameToLitColl.get(literalType).literalToLocations.keySet()){
-String escliteral = escapeXml(literal);
+if (literal.trim().compareTo() == 0){
+ literal = [whitespace only string];
+}
+
+
+String newLiteral = ;
+if(literal.length() 100){
+ int i;
+ for (i = 100; i literal.length(); i=i+100){
+String part1 = literal.substring(i-100, i);
+newLiteral = newLiteral + part1 + ;
+ }
+ if (i-100 0){
+newLiteral = newLiteral + literal.substring(i-100);
+ }
+}
+else{
+ newLiteral = literal;
+}
+
+String escliteral = escapeXml(newLiteral);
outFile.println(div class=\rowdiv\);
-outFile.println(div class=\celldiv\ + escliteral
+ /div);
+outFile.println(div class=\celldiv\ + escliteral + /div);
for (String location :
nameToLitColl.get(literalType).literalToLocations.get(literal)){
- outFile.println(div class=\celldiv\ + location
+ /div);
+
+ String newLocation = ;
+ if(location.length() 100){
+int i;
+for (i = 100; i location.length(); i=i+100){
+ String part1 = location.substring(i-100, i);
+ newLocation = newLocation + part1 + ;
+}
+if (i-100 0){
+ newLocation = newLocation + location.substring(i-100);
+}
+ }
+ else{
+newLocation = location;
+ }
+
+ outFile.println(div class=\celldiv\ + newLocation
+ /div);
}
outFile.println(/div);
}
@@ -720,6 +761,8 @@
}
}
+
+
public static void makeStringLiteralsClassesHtmls(TreeMapString,
LiteralsCollection nameToLitColl) throws IOException{
@@ -735,7 +778,7 @@
outFile.println(html);
outFile.println(head);
outFile.println(meta http-equiv=\content-type\
content=\text/html;charset=ISO-8859-1\);
- outFile.println(titleLiterals of type + literalType
+ /title);
+ outFile.println(titleLiterals of type \ + literalType
+ \/title);
outFile.println(/head);
outFile.println(style type=\text/css\);
@@ -777,12 +820,48 @@
if
(nameToLitColl.get(string).stringLiteralToType.get(literal).compareTo(literalType)
== 0){
- String escliteral = escapeXml(literal);
+
+ if (literal.trim().compareTo() == 0){
+literal = [whitespace only string];
+ }
+
+ String newLiteral = ;
+ if(literal.length() 100){
+int i;
+for (i = 100; i literal.length(); i=i+100){
+ String part1 = literal.substring(i-100, i);
+ newLiteral = newLiteral + part1 + ;
+}
+if (i-100 0){
+ newLiteral = newLiteral + literal.substring(i-100);
+}
+ }
+ else{
+newLiteral = literal;
+ }
+
+ String escliteral =
[gwt-contrib] [google-web-toolkit commit] r4214 - branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client
Author: [EMAIL PROTECTED]
Date: Mon Dec 1 11:09:39 2008
New Revision: 4214
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/ElementMapper.java
Log:
beef up TODO per jlabanca's review of r4165. TBR jlabanca
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/ElementMapper.java
==
---
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/ElementMapper.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/ElementMapper.java
Mon Dec 1 11:09:39 2008
@@ -133,7 +133,9 @@
if (lastIndex 0) {
throw new IllegalStateException();
}
-// TODO(ecc) ???
+// TODO(ecc) Why are we casting to Widget and working only in
tables?
+// Is this code even executed? If not, let's yank it
+// and throwing an UnsupportedOperationException
Widget w = (Widget) uiObjectList.get(lastIndex);
assert (w.getParent() instanceof HTMLTable);
w.removeFromParent();
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] TBR needed on r4214
When you have a moment: http://code.google.com/p/google-web-toolkit/source/detail?r=4214 beef up TODO per jlabanca's review of r4165. TBR jlabanca rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4214.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4214. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4214 Score: Positive General Comment: minor grammar error, but you probably don't need to fix it since we'll have to address this TODO at some point. Line-by-line comments: File: /branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/ElementMapper.java (r4214) === Line 138: // and throwing an UnsupportedOperationException --- throw, not throwing Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4214 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: Adding .project to gwt-incubator root directory
We check the .project file in for all of our projects, this makes picking it up from the repo really easy. -- Arthur Kalmenson On Mon, Nov 24, 2008 at 11:31 AM, Lex Spoon [EMAIL PROTECTED] wrote: On Mon, Nov 17, 2008 at 4:28 PM, BobV [EMAIL PROTECTED] wrote: What exactly is the reason we can't do the same here? subclipse won't handle linked resources. Seconded. Saying that the trunk arrangement works is a mild overstatement. That said, I don't know if there is some way to make an eclipse subdirectory work or not. It might be possible if the linked resources can be avoided. Still, checking in the .project file works fine as far as I know. I've worked on projects that did so before. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: please solve this prob ..
The error message seems pretty explanatory, and it's kind of hard to understand what the problem is without a code snippet. You'd be better off asking your question on the regular mailing list: http://groups.google.com/group/Google-Web-Toolkit as this one is specific to contributors and not general questions. -- Arthur Kalmenson On Tue, Nov 25, 2008 at 8:43 AM, Bhupen [EMAIL PROTECTED] wrote: [ERROR] Uncaught exception escaped java.lang.AssertionError: A widget in the detach list was found not attached to the document. The is likely caused by wrapping an existing element and removing it from the document without calling RootPanel.detachNow(). at com.google.gwt.user.client.ui.RootPanel.detachWidgets (RootPanel.java:200) at com.google.gwt.user.client.ui.RootPanel$1.onWindowClosed (RootPanel.java:221) at com.google.gwt.user.client.Window.fireClosedImpl(Window.java:465) at com.google.gwt.user.client.Window.fireClosedAndCatch(Window.java: 456) at com.google.gwt.user.client.Window.onClosed(Window.java:430) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java: 103) at com.google.gwt.dev.shell.ie.IDispatchImpl.callMethod (IDispatchImpl.java:126) at com.google.gwt.dev.shell.ie.IDispatchProxy.invoke (IDispatchProxy.java:155) at com.google.gwt.dev.shell.ie.IDispatchImpl.Invoke (IDispatchImpl.java:294) at com.google.gwt.dev.shell.ie.IDispatchImpl.method6 (IDispatchImpl.java:194) at org.eclipse.swt.internal.ole.win32.COMObject.callback6 (COMObject.java:117) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1925) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2966) at com.google.gwt.dev.GWTShell.pumpEventLoop(GWTShell.java:720) at com.google.gwt.dev.GWTShell.run(GWTShell.java:593) at com.google.gwt.dev.GWTShell.main(GWTShell.java:357) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4098.
Lex, given that we're not at all likely to benchmark this obscure method, did you just suggest that we should stick with | (and document why we're doing so)? On Mon, Nov 24, 2008 at 8:55 AM, Lex Spoon [EMAIL PROTECTED] wrote: On Thu, Nov 20, 2008 at 1:43 PM, Emily Crutcher [EMAIL PROTECTED] wrote: Darn it, I hate when inconvenient facts get in the way of a nice theory! As I did the benchmark and you are right, there is no advantage of | over ||. For branch prediction in particular, note that a true interpreter will not have a branch in the machine code corresponding to each branch in the source code. Instead, the machine-code-level branch will be somewhere in the implementation of ||, of if, of while, etc. So, the branch predictor ends up trying to decide whether all of the ifs of the program go to true or to false. That's not quite useless, but it's way less than what C and Java programs enjoy. For an interpreter with dynamic translation, things should be different. Bearing in mind that, like John suggests, it still has to be a pretty fast interpreter before it matters, eliminating branches seems worth doing, other things equal. It would still be worth seeing a positive benchmark to be sure. Two other things. | is one character less than ||, which is important when we count the bytes. Second, there are analogous problems for an optimizing compiler. If this code used | instead of ||, then it would be an easy optimization to inline alt, ctrl, meta, and shift, thus eliminating those from being variables at all. The compiler could change it to this: Event nativeEvent = getNativeEvent(); return nativeEvent.getAltKey() | nativeEvent.getCtrlKey() | nativeEvent.getMetaKey() | nativeEvent.getShiftKey(); If this code used ||, then the optimization would be much trickier, all due to the implicit branch. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4098.
On Mon, Dec 1, 2008 at 3:23 PM, Ray Ryan [EMAIL PROTECTED] wrote: Lex, given that we're not at all likely to benchmark this obscure method, did you just suggest that we should stick with | (and document why we're doing so)? To summarize, | looks like a good default in cases where the rhs is cheap. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RR, code review request: merge HyperlinkOverride into Hyperlink widget
Hello Ray :)
Would you take a look at this patch for the Hyperlink widget? It takes
the behavior from incubator's HyperlinkOverride widget and moves it
into the core Hyperlink.
This means that on a click event with a modifier key (with specific
keys counting, per-browser), we let the default browser action happen,
usually something like opening that link in a new tab.
I have a small doubt about this patch with regard to Chrome, but
please let me know what you think -- as far as I can tell, Chrome
doesn't do an open in new tab when you ctrl-click on a link to a URL
fragment (for example, our history tokens) -- but on the assumption
that this may change soon, this patch tries to do the behavior that
Chrome does for regular links, which is just like Firefox.
Patch is intended for the 1.6 release branch, r4214.
Thanks!
--
Alex Rudnick
swe, gwt, atl
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: user/src/com/google/gwt/user/Hyperlink.gwt.xml
===
--- user/src/com/google/gwt/user/Hyperlink.gwt.xml (revision 0)
+++ user/src/com/google/gwt/user/Hyperlink.gwt.xml (revision 0)
@@ -0,0 +1,19 @@
+module
+ inherits name=com.google.gwt.core.Core/
+ inherits name=com.google.gwt.user.UserAgent/
+
+ replace-with class=com.google.gwt.user.client.ui.impl.HyperlinkImplOpera
+when-type-is class=com.google.gwt.user.client.ui.impl.HyperlinkImpl/
+when-property-is name=user.agent value=opera/
+ /replace-with
+
+ replace-with class=com.google.gwt.user.client.ui.impl.HyperlinkImplSafari
+when-type-is class=com.google.gwt.user.client.ui.impl.HyperlinkImpl/
+when-property-is name=user.agent value=safari/
+ /replace-with
+
+ replace-with class=com.google.gwt.user.client.ui.impl.HyperlinkImplIE
+when-type-is class=com.google.gwt.user.client.ui.impl.HyperlinkImpl/
+when-property-is name=user.agent value=ie6/
+ /replace-with
+/module
Index: user/src/com/google/gwt/user/User.gwt.xml
===
--- user/src/com/google/gwt/user/User.gwt.xml (revision 4214)
+++ user/src/com/google/gwt/user/User.gwt.xml (working copy)
@@ -39,6 +39,7 @@
inherits name=com.google.gwt.user.CaptionPanel /
inherits name=com.google.gwt.user.Window /
inherits name=com.google.gwt.user.Tree/
+ inherits name=com.google.gwt.user.Hyperlink/
super-source path=translatable/
source path=client/
Index: user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplIE.java
===
--- user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplIE.java (revision 0)
+++ user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplIE.java (revision 0)
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2008 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License); you may not
+ * use this file except in compliance with the License. You may obtain a copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations under
+ * the License.
+ */
+
+package com.google.gwt.user.client.ui.impl;
+
+import com.google.gwt.user.client.Event;
+
+/**
+ * IE version of HyperlinkImpl. IE6 and IE7 actually have different
+ * behavior; both have special behavior for shift-click, but IE7 also opens
+ * in a new tab on ctrl-click. IE6 treats ctrl-click as a standard click.
+ */
+public class HyperlinkImplIE extends HyperlinkImpl {
+
+ private static boolean ctrlisModifier;
+
+ static {
+ctrlisModifier = (getInternetExplorerVersion() = 7);
+ }
+
+ /**
+ * Returns the version of Internet Explorer or a -1, (indicating the use of
+ * another browser). Based on code from MSDN.
+ * http://msdn2.microsoft.com/en-us/library/ms537509.aspx
+ */
+ private static native int getInternetExplorerVersion() /*-{
+var rv = -1; // Assume that we're not IE.
+
+if (navigator.appName == 'Microsoft Internet Explorer') {
+ var ua = navigator.userAgent;
+ var re = new RegExp(MSIE ([0-9]{1,}[\.0-9]{0,}));
+ if (re.exec(ua) != null)
+rv = parseFloat( RegExp.$1 );
+}
+
+return rv;
+ }-*/;
+
+ @Override
+ public boolean handleAsClick(Event event) {
+int mouseButtons = event.getButton();
+boolean ctrl = event.getCtrlKey();
+boolean shift = event.getShiftKey();
+boolean middle = mouseButtons == Event.BUTTON_MIDDLE;
+boolean right = mouseButtons == Event.BUTTON_RIGHT;
+boolean modifiers;
+
+if (ctrlisModifier) {
+ modifiers = shift
[gwt-contrib] RR: How absolute should the setValue's contract be?
As many of you know, we have started down the path of making our form widgets implement HasValue. A question that has come up is: Should widgets be able to chose what values the widget accepts (i.e. setValue(null) for a text box or a bounded integer range for a select box) without throwing runtime exceptions? So, for instance, assuming we allow setValue(null) in some cases and not others: HasValueDate dateBox = new DateBox(); HasValueString hasValue2 = new TextBox(); // This clears the date box. hasValue1.setValue(null); // This throws an illegal argument exception. hasValue2.setValue(null); The HasValue interface becomes a lot more difficult to implement if we insist that all non-null values are supported, it becomes slightly harder to use if we do not. So, which contract should we enforce? *Proposal 1) *setValue() gives no guarantee about whether a specific value is valid. Users must know the underlying widget is in order to safely use the HasValue interface. *Proposal 2) *setValue() will accept all non-null values of a specific type as valid input. In order to implement this, we will have to introduce HasClearValue to support clearing a widget. ListBox, for instance, would not be able to implement HasValueString, as not all strings would be valid inputs. -- There are only 10 types of people in the world: Those who understand binary, and those who don't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
On Mon, Dec 1, 2008 at 2:50 PM, Emily Crutcher [EMAIL PROTECTED] wrote: As many of you know, we have started down the path of making our form widgets implement HasValue. A question that has come up is: Should widgets be able to chose what values the widget accepts (i.e. setValue(null) for a text box or a bounded integer range for a select box) without throwing runtime exceptions? So, for instance, assuming we allow setValue(null) in some cases and not others: HasValueDate dateBox = new DateBox(); HasValueString hasValue2 = new TextBox(); // This clears the date box. hasValue1.setValue(null); // This throws an illegal argument exception. hasValue2.setValue(null); The HasValue interface becomes a lot more difficult to implement if we insist that all non-null values are supported, it becomes slightly harder to use if we do not. I can't parse this. So, which contract should we enforce? *Proposal 1) *setValue() gives no guarantee about whether a specific value is valid. Users must know the underlying widget is in order to safely use the HasValue interface. *Proposal 2) *setValue() will accept all non-null values of a specific type as valid input. In order to implement this, we will have to introduce HasClearValue to support clearing a widget. Nor these. At the moment it is up to the individual widget to decide whether setValue(null) is legal or not. For HasValueString widgets, allowing getValue() to return null is pretty unpleasant. For most other types (think Date), using null to clear the widget seems a pretty natural thing to do. I'd prefer to leave the interface as is for now, and see if there is an actual problem here. I suspect we'll find ourselves in a world where most widgets deal with null, but string-based ones do not, and everyone will be just fine. ListBox, for instance, would not be able to implement HasValueString, as not all strings would be valid inputs. -- There are only 10 types of people in the world: Those who understand binary, and those who don't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
I'd prefer to leave the interface as is for now, and see if there is an actual problem here. I suspect we'll find ourselves in a world where most widgets deal with null, but string-based ones do not, and everyone will be just fine. Unfortunately, it is not very easy to change the contract after we've released it into the wild. We can go with either solution, as both have their plusses and minuses, but I'm not sure we can change course in the middle. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
On Mon, Dec 1, 2008 at 6:17 PM, Emily Crutcher [EMAIL PROTECTED] wrote:
Unfortunately, it is not very easy to change the contract after we've
released it into the wild. We can go with either solution, as both have
their plusses and minuses, but I'm not sure we can change course in the
middle.
How about:
public interface HasValueT {
T getValue();
boolean isAcceptableValue(T v);
void setValue(T v) throws InvalidArgumentException;
}
If you want to check if a given widget will accept a particular value, you
can ask without having to do a set and catch an exception, plus you don't
have to worry if it transformed the value to something else as below.
Otherwise, if you call setValue it is free to mangle it into some supported
value (for example, null = for a text box, invalid date = today, etc)
or throw an exception if it can't reasonably do so, but that behavior would
be entirely up to the widget. I do agree it should not be a checked
exception.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
That way lies data validation, something GWT needs, but something I think
we're not ready to cram into 1.6.
On Mon, Dec 1, 2008 at 3:23 PM, John Tamplin [EMAIL PROTECTED] wrote:
On Mon, Dec 1, 2008 at 6:17 PM, Emily Crutcher [EMAIL PROTECTED] wrote:
Unfortunately, it is not very easy to change the contract after we've
released it into the wild. We can go with either solution, as both have
their plusses and minuses, but I'm not sure we can change course in the
middle.
How about:
public interface HasValueT {
T getValue();
boolean isAcceptableValue(T v);
void setValue(T v) throws InvalidArgumentException;
}
If you want to check if a given widget will accept a particular value, you
can ask without having to do a set and catch an exception, plus you don't
have to worry if it transformed the value to something else as below.
Otherwise, if you call setValue it is free to mangle it into some supported
value (for example, null = for a text box, invalid date = today, etc)
or throw an exception if it can't reasonably do so, but that behavior would
be entirely up to the widget. I do agree it should not be a checked
exception.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
On Mon, Dec 1, 2008 at 6:26 PM, Ray Ryan [EMAIL PROTECTED] wrote: That way lies data validation, something GWT needs, but something I think we're not ready to cram into 1.6. If the alternative is to come up with either something that can't be implemented reasonably or something else that can't be used reasonably, I don't see the point in including it at all. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
I don't buy the argument that the current interface can't be used or implemented reasonably. The only real issue here, I think, is about the use of null. Trying to broaden that discussion to take on filtering legal non-null values is an artificial expansion of the problem. Not all widgets can be cleared meaningfully. Consider a select element--it's always showing something. I think forcing HasValue to take a stand on that issue is helpful. rjrjr On Mon, Dec 1, 2008 at 3:28 PM, John Tamplin [EMAIL PROTECTED] wrote: On Mon, Dec 1, 2008 at 6:26 PM, Ray Ryan [EMAIL PROTECTED] wrote: That way lies data validation, something GWT needs, but something I think we're not ready to cram into 1.6. If the alternative is to come up with either something that can't be implemented reasonably or something else that can't be used reasonably, I don't see the point in including it at all. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
God, I wish I could type. I *don't* think forcing HasValue to take a stand on that issue is helpful. Basically, in some spots empty is meaningful and in other it isn't. In some of those spots null will make sense, and in others it won't. I don't think there is a general problem to be solved there, and if there is I don't think HasValue is the place to solve it. rjrjr On Mon, Dec 1, 2008 at 3:37 PM, Ray Ryan [EMAIL PROTECTED] wrote: I don't buy the argument that the current interface can't be used or implemented reasonably. The only real issue here, I think, is about the use of null. Trying to broaden that discussion to take on filtering legal non-null values is an artificial expansion of the problem. Not all widgets can be cleared meaningfully. Consider a select element--it's always showing something. I think forcing HasValue to take a stand on that issue is helpful. rjrjr On Mon, Dec 1, 2008 at 3:28 PM, John Tamplin [EMAIL PROTECTED] wrote: On Mon, Dec 1, 2008 at 6:26 PM, Ray Ryan [EMAIL PROTECTED] wrote: That way lies data validation, something GWT needs, but something I think we're not ready to cram into 1.6. If the alternative is to come up with either something that can't be implemented reasonably or something else that can't be used reasonably, I don't see the point in including it at all. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
On Mon, Dec 1, 2008 at 3:12 PM, Ray Ryan [EMAIL PROTECTED] wrote:
On Mon, Dec 1, 2008 at 3:02 PM, Ian Petersen [EMAIL PROTECTED] wrote:
First, I think there should be two interfaces, one that only supports
getValue(), and another that inherits from the first and adds
setValue(T). I'll let someone else bikeshed over whether HasValue
should be the ancestor or descendant. The benefit here is that you
can plug into the HasValue architecture without being forced into the
corner of supporting arbitrary updates to your data.
There is no HasValue architecture, nor is one expected.
HasValue architecture was hand-wavy technobabble. What I meant was,
I'd like to be able to design a Foo that manipulates things that
implement HasValue. My Foo needs to getValue(), but it doesn't need
to setValue(T). Separating the interfaces makes my my Foo more useful
because other people can build arbitrary HasValue implementations
without having to worry about implementing setValue(T).
For a completely contrived example, you could imagine DatePicker
looking like this:
public class DatePicker implements HasSettableValueDate {
public Date getValue() {
// return current date
}
public void setValue(Date newDate) {
// update internal state
}
// by returning HasValue instead of HasSettableValue
// you avoid the thorny issue of updating the enclosing
// DatePicker's current date when the caller invokes
// setValue(4) on the returned object
public HasValueInteger getDayOfWeekObserver() {
return new HasValueInteger {
public Integer getValue() {
// return day of week as computed from enclosing DatePicker's
current date
}
}
}
My point is not whether a day-of-week observer is a useful extension
to DatePicker, but rather that HasValue and HasSettableValue is a
useful separation. I'd also be in favour of HasValue implying
SourcesValueChanged, but I'm a little divorced from the code these
days, so I'm not sure if it's worth the extra complexity.
Ian
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4217 - in changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core: ext/linker ext/linke...
Author: [EMAIL PROTECTED]
Date: Mon Dec 1 15:49:35 2008
New Revision: 4217
Added:
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/soyc/impl/SnippetIterator.java
(contents, props changed)
- copied, changed from r4215,
/changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/soyc/impl/SnippitIterator.java
Removed:
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/soyc/impl/SnippitIterator.java
Modified:
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/soyc/impl/StoryImpl.java
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/linker/soyc/SoycReportLinker.java
Log:
Spelling correction snippit - snippet.
Suggested by: kprobst
Modified:
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java
==
---
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java
(original)
+++
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java
Mon Dec 1 15:49:35 2008
@@ -30,9 +30,9 @@
/**
* Associates a Story and a Range of the output. Instances of this
interface
- * are obtained from [EMAIL PROTECTED] CompilationAnalysis#getSnippits()}.
+ * are obtained from [EMAIL PROTECTED] CompilationAnalysis#getSnippets()}.
*/
- public interface Snippit {
+ public interface Snippet {
Range getRange();
Story getStory();
@@ -63,7 +63,7 @@
* Provides access to the assignments of Stories to Ranges for a
fragment of
* the output. The Ranges are guaranteed not to overlap, and may be used
for
* exact accounting of bytes. Due to the potential for very large
data-sets to
- * be accessible through this method, it is recommended that Snippits
should
+ * be accessible through this method, it is recommended that Snippets
should
* be processed in an incremental fashion that does not require all
instances
* to be retained at once.
*/
@@ -73,7 +73,7 @@
* we were to return a Map for an analysis of N stories, we would also
need N
* Ranges, plus the overhead of constructing an ordered Map.
*/
- public abstract IterableSnippit getSnippits(int fragmentNumber);
+ public abstract IterableSnippet getSnippets(int fragmentNumber);
/**
* Returns all Stories.
Modified:
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
==
---
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
(original)
+++
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
Mon Dec 1 15:49:35 2008
@@ -40,7 +40,7 @@
/**
* A base class for Linkers that use an external script to boostrap the GWT
- * module. This implementation injects JavaScript snippits into a JS
program
+ * module. This implementation injects JavaScript Snippets into a JS
program
* defined in an external file.
*/
public abstract class SelectionScriptLinker extends AbstractLinker {
@@ -295,7 +295,7 @@
}
/**
- * Generate a snippit of JavaScript to inject an external stylesheet.
+ * Generate a Snippet of JavaScript to inject an external stylesheet.
*
* pre
* if (!__gwt_stylesLoaded['URL']) {
Modified:
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java
==
---
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java
(original)
+++
changes/bobv/soyc-reports-r4205/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java
Mon Dec 1 15:49:35 2008
@@ -28,7 +28,7 @@
import com.google.gwt.core.ext.soyc.impl.AbstractMemberWithDependencies;
import com.google.gwt.core.ext.soyc.impl.MemberFactory;
import com.google.gwt.core.ext.soyc.impl.OriginImpl;
-import com.google.gwt.core.ext.soyc.impl.SnippitIterator;
+import com.google.gwt.core.ext.soyc.impl.SnippetIterator;
import com.google.gwt.core.ext.soyc.impl.StandardClassMember;
import com.google.gwt.core.ext.soyc.impl.StandardFieldMember;
import com.google.gwt.core.ext.soyc.impl.StandardFunctionMember;
@@ -73,7 +73,7 @@
/**
* These
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
I share Ray's suspicion that this won't actually be much of a problem. A checked exception is clearly (I hope) the wrong way to go. Checked exceptions have their place, but they are a major pain in several anatomical locations when declared in situations where the vast majority of the time they cannot occur. On the other hand, unchecked exceptions for inputs that are unacceptable are quite normal (ArrayIndexOutOfBoundsException comes to mind). Nulls even have their own exclusive exception for unacceptability. Throwing exceptions like those can be left up to the individual HasValue implementation and developers will be accustomed to seeing and handling them. I think Ian's idea of a read-only interface is interesting, but not really on topic. Perhaps it deserves its own thread? On Mon, Dec 1, 2008 at 5:50 PM, Emily Crutcher [EMAIL PROTECTED] wrote: As many of you know, we have started down the path of making our form widgets implement HasValue. A question that has come up is: Should widgets be able to chose what values the widget accepts (i.e. setValue(null) for a text box or a bounded integer range for a select box) without throwing runtime exceptions? So, for instance, assuming we allow setValue(null) in some cases and not others: HasValueDate dateBox = new DateBox(); HasValueString hasValue2 = new TextBox(); // This clears the date box. hasValue1.setValue(null); // This throws an illegal argument exception. hasValue2.setValue(null); The HasValue interface becomes a lot more difficult to implement if we insist that all non-null values are supported, it becomes slightly harder to use if we do not. So, which contract should we enforce? Proposal 1) setValue() gives no guarantee about whether a specific value is valid. Users must know the underlying widget is in order to safely use the HasValue interface. Proposal 2) setValue() will accept all non-null values of a specific type as valid input. In order to implement this, we will have to introduce HasClearValue to support clearing a widget. ListBox, for instance, would not be able to implement HasValueString, as not all strings would be valid inputs. -- There are only 10 types of people in the world: Those who understand binary, and those who don't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4219 - trunk/doc
Author: [EMAIL PROTECTED] Date: Mon Dec 1 19:36:51 2008 New Revision: 4219 Modified: trunk/doc/build.xml Log: Bump memory when building javadoc to see if this will fix breakage on continuous build. Patch by: bobv Review by: scottb (TBR) Modified: trunk/doc/build.xml == --- trunk/doc/build.xml (original) +++ trunk/doc/build.xml Mon Dec 1 19:36:51 2008 @@ -76,6 +76,7 @@ sequential echoBuilding javadoc/echo java classpathref=DOC_PATH classname=com.google.doctool.custom.GWTJavaDoclet fork=yes failonerror=true + jvmarg value=-Xmx256M / arg value=-quiet / arg value=-notimestamp / arg value=-source / --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
I think we shouldn't be too strict on user implementations of HasValue, but GWT widgets should be standardized. I agree with jat's comment that its okay to mutate the input from setValue(), and I agree with Isaac's comment that there are some times when the input is just not valid and it makes sense to throw an exception. My original inclination was that getValue() should return exactly what was set in setValue(), but I've changed my mind. In a traditional Java object, that would certainly be a good criteria. But UI widgets are interactive by nature. If I setValue() now, the end user can certainly interact with the widget such that getValue() returns a different result later. Sure we could say that a synchronous call to getValue() after setValue() should return the same value, but why bother when it isn't generally true? The side effect of this (this being we don't have tight correlation between getValue() and setValue()) is that we have some leeway in mutating the input of setValue(). For example, setValue(null) on a TextBox can clear the text, even though getValue() will return an empty string. Sure a TextBox doesn't technically have a null value, but I don't think anyone is really going to get confused if setValue() clears the text. 99% of the time, it will be obvious what setValue(null) does. Some widgets can mutate setValue() significantly. For example, an IntegerOnlyTextBox might convert all Strings to an intValue() and then back to a String. So far, we can now use HasValue widgets without any knowledge of the actual Widget. However, I think its acceptable for a widget to throw an exception if the value is completely invalid and can't be reasonably mutated (props to Isaac). It would be nice if GWT widgets accepted the entire range of values in all cases, but even that may be a stretch. For example, if we add a date range to DatePicker, it would be truly incorrect to set a date outside of that range (we could pick the closest much, but just go with the example). So, the user needs to have some knowledge of the underlying widget if she uses a widget that has some restrictions, but she only needs enough intel to know that the values coming from the magical source of values are compatible with the widget. If your magical source of values is trying to set invalid values and the Widget throws an exception, its probably a good thing. In the DatePicker example, you'd either need to fix the value, or expand the range. But, at least for GWT widgets, exceptions would be few and far between. Thanks, John LaBanca [EMAIL PROTECTED] On Mon, Dec 1, 2008 at 7:47 PM, Isaac Truett [EMAIL PROTECTED] wrote: I share Ray's suspicion that this won't actually be much of a problem. A checked exception is clearly (I hope) the wrong way to go. Checked exceptions have their place, but they are a major pain in several anatomical locations when declared in situations where the vast majority of the time they cannot occur. On the other hand, unchecked exceptions for inputs that are unacceptable are quite normal (ArrayIndexOutOfBoundsException comes to mind). Nulls even have their own exclusive exception for unacceptability. Throwing exceptions like those can be left up to the individual HasValue implementation and developers will be accustomed to seeing and handling them. I think Ian's idea of a read-only interface is interesting, but not really on topic. Perhaps it deserves its own thread? On Mon, Dec 1, 2008 at 5:50 PM, Emily Crutcher [EMAIL PROTECTED] wrote: As many of you know, we have started down the path of making our form widgets implement HasValue. A question that has come up is: Should widgets be able to chose what values the widget accepts (i.e. setValue(null) for a text box or a bounded integer range for a select box) without throwing runtime exceptions? So, for instance, assuming we allow setValue(null) in some cases and not others: HasValueDate dateBox = new DateBox(); HasValueString hasValue2 = new TextBox(); // This clears the date box. hasValue1.setValue(null); // This throws an illegal argument exception. hasValue2.setValue(null); The HasValue interface becomes a lot more difficult to implement if we insist that all non-null values are supported, it becomes slightly harder to use if we do not. So, which contract should we enforce? Proposal 1) setValue() gives no guarantee about whether a specific value is valid. Users must know the underlying widget is in order to safely use the HasValue interface. Proposal 2) setValue() will accept all non-null values of a specific type as valid input. In order to implement this, we will have to introduce HasClearValue to support clearing a widget. ListBox, for instance, would not be able to implement HasValueString, as not all strings would be valid inputs. -- There are only 10 types of people in the world: Those who understand binary, and
[gwt-contrib] [google-web-toolkit commit] r4220 - in trunk/tools: . soyc-vis
Author: [EMAIL PROTECTED]
Date: Mon Dec 1 20:28:46 2008
New Revision: 4220
Added:
trunk/tools/soyc-vis/
trunk/tools/soyc-vis/README
trunk/tools/soyc-vis/build.xml
Modified:
trunk/tools/build.xml
Log:
Added SOYC Dashboard visualization to trunk/tools. See README in
trunk/tools/soyc-vis for information on how to compile run.
Modified: trunk/tools/build.xml
==
--- trunk/tools/build.xml (original)
+++ trunk/tools/build.xml Mon Dec 1 20:28:46 2008
@@ -3,7 +3,7 @@
property name=project.tail value=tools /
import file=${gwt.root}/common.ant.xml /
-!-- build is the default when subprojects are directly
targetted --
+!-- build is the default when subprojects are directly targeted
--
property name=target value=build /
target name=benchmark-viewer depends= description=Run
benchmark-viewer
@@ -13,8 +13,12 @@
target name=api-checker depends= description=Compile
api-checker
gwt.ant dir=api-checker /
/target
-
- target name=-do depends=benchmark-viewer,api-checker
description=Run all subfolders /
+
+target name=soyc-vis depends= description=Compile SOYC
dashboard
+gwt.ant dir=soyc-vis /
+/target
+
+ target name=-do depends=benchmark-viewer,api-checker,soyc-vis
description=Run all subfolders /
target name=build description=Build each subfolder
antcall target=-do
Added: trunk/tools/soyc-vis/README
==
--- (empty file)
+++ trunk/tools/soyc-vis/README Mon Dec 1 20:28:46 2008
@@ -0,0 +1,26 @@
+/*
+ * Copyright 2008 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+
+This utility presents a dashboard visulization of GWT's Story of Your
+Compile.
+
+To compile:
+ant (in this directory)
+
+To run:
+1. Compile your GWT application with SOYC (flag -soyc), which results in
one ore
+more .xml files (depending on your number of permutations), plus a file
manifest.xml that maps permutations to .xml files.
+2. Run java -classpath build/classes -Xmx1024M
com/google/gwt/soyc/SoycDashboard XmlFileName.xml
Added: trunk/tools/soyc-vis/build.xml
==
--- (empty file)
+++ trunk/tools/soyc-vis/build.xml Mon Dec 1 20:28:46 2008
@@ -0,0 +1,17 @@
+?xml version=1.0?
+
+project name=SOYC Dashboard Visualization default=build basedir=.
+
+target name=clean
+delete dir=build/
+/target
+
+target name=compile
+mkdir dir=build/classes/
+javac srcdir=src destdir=build/classes/
+/target
+
+target name=build depends=clean, compile/
+
+
+/project
\ No newline at end of file
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
