[gwt-contrib] Breaks dom.DOM dependency on user.UserAgent
Reviewers: jgw, Description: One of the goals of the new Dom library was proper modularity so that it would be possible to write apps and libraries that do not depend on User.gwt.xml. That's not currently possible due to UserAgent. This patch moves UserAgent.gwt.xml into the dom module and creates a bridge module in User so as not to break anything. Please review this at http://gwt-code-reviews.appspot.com/401 Affected files: user/src/com/google/gwt/dom/DOM.gwt.xml user/src/com/google/gwt/dom/UserAgent.gwt.xml user/src/com/google/gwt/user/UserAgent.gwt.xml --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4239 - branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client
Author: [EMAIL PROTECTED]
Date: Tue Dec 2 20:08:01 2008
New Revision: 4239
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/CalendarView.java
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/ElementMapper.java
Log:
Addresses some of the remaining issues from
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/486babc9bb0863a9
In particular, nukes the unused Iterator class from ElementMapper,
fixes a bug in DatePicker#removeStyleFromVisibleDates, touches up some
javadoc, removes unneeded redeclaration of refresh from CalendarView.
We still lack unit tests on CalendarView and ElementMapper, and time
may not permit them. There is also a discussion in progress on
removeStyleFromVisibleDates. When that is done, any remaining methods
with Iterator in their signature will need to re-worked to use
Collection instead.
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/CalendarView.java
==
---
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/CalendarView.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/CalendarView.java
Tue Dec 2 20:08:01 2008
@@ -63,9 +63,6 @@
*/
public abstract boolean isDateEnabled(Date date);
- @Override
- public abstract void refresh();
-
/**
* Removes a visible style name from the cell of the supplied date.
*
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
==
---
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Tue Dec 2 20:08:01 2008
@@ -380,7 +380,7 @@
}
/**
- * Gets the highlighted date, if any.
+ * Gets the highlighted date (the one the mouse is hovering over), if
any.
*
* @return the highlighted date
*/
@@ -399,9 +399,9 @@
}
/**
- * Gets the [EMAIL PROTECTED] DatePicker}'s value.
+ * Returns the selected date, or null if none is selected.
*
- * @return the value
+ * @return the selected date, or null
*/
public final Date getValue() {
return value;
@@ -456,7 +456,7 @@
assert (isDateVisible(date)) : date + " should be visible";
getView().removeStyleFromDate(styleName, date);
for (Date d : moreDates) {
- getView().removeStyleFromDate(styleName, date);
+ getView().removeStyleFromDate(styleName, d);
}
}
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
Tue Dec 2 20:08:01 2008
@@ -17,13 +17,9 @@
package com.google.gwt.user.datepicker.client;
import com.google.gwt.user.client.Element;
-import com.google.gwt.user.client.ui.HTMLTable;
import com.google.gwt.user.client.ui.UIObject;
-import com.google.gwt.user.client.ui.Widget;
import java.util.ArrayList;
-import java.util.Iterator;
-import java.util.NoSuchElementException;
/**
* Creates a mapping from elements to their associated ui objects.
@@ -99,57 +95,6 @@
public void removeByElement(Element elem) {
int index = getIndex(elem);
removeImpl(elem, index);
- }
-
- /**
- * Creates an iterator of uiObjects.
- *
- * @return the iterator
- */
- public Iterator iterator() {
-
-return new Iterator() {
- int lastIndex = -1;
- int nextIndex = -1;
- {
-findNext();
- }
-
- public boolean hasNext() {
-return nextIndex < uiObjectList.size();
- }
-
- public T next() {
-if (!hasNext()) {
- throw new NoSuchElementException();
-}
-T result = uiObjectList.get(nextIndex);
-lastIndex = nextIndex;
-findNext();
-return result;
- }
-
- public void remove() {
-if (lastIndex < 0) {
- throw new IllegalStateException();
-}
-// 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();
-lastIndex = -1;
- }
-
- private void findNext() {
-while (+
[gwt-contrib] TBR Code review on DatePicker branch, more clean up
http://code.google.com/p/google-web-toolkit/source/detail?r=4239 Addresses some of the remaining issues from http://groups.google.com/group/Google-Web-Toolkit- Contributors/browse_thread/thread/486babc9bb0863a9 In particular, nukes the unused Iterator class from ElementMapper, fixes a bug in DatePicker#removeStyleFromVisibleDates, touches up some javadoc, removes unneeded redeclaration of refresh from CalendarView. We still lack unit tests on CalendarView and ElementMapper, and time may not permit them. There is also a discussion in progress on removeStyleFromVisibleDates. When that is done, any remaining methods with Iterator in their signature will need to re-worked to use Collection instead. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Datepicker: Global style v. visible style
I'm working through the big date picker review: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/486babc9bb0863a9 I don't understand why we provide addGlobalStyleToDateand addStyleToVisibleDates, especially since the latter will explode in your face if you call it on an invisible date, except when it doesn't in web mode. Why don't we get rid of the visibleDate variants, and drop the "global" from the others? rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] small code review: Add InlineHyperlink widget
Reviewers: rjrjr,
Message:
LGTM with the nits below fixed.
http://codereview.appspot.com/8700/diff/1/3
File user/src/com/google/gwt/user/client/ui/Hyperlink.java (right):
http://codereview.appspot.com/8700/diff/1/3#newcode45
Line 45: * CSS Style Rules .gwt-Hyperlink
{ }
Autoformat damage. Please don't autoformat entire existing classes.
http://codereview.appspot.com/8700/diff/1/3#newcode56
Line 56: private Element anchorElem;
can you make this final?
http://codereview.appspot.com/8700/diff/1/2
File user/src/com/google/gwt/user/client/ui/InlineHyperlink.java
(right):
http://codereview.appspot.com/8700/diff/1/2#newcode25
Line 25: * CSS Style Rules
.gwt-InlineHyperlink { }
shouldn't be in one line
http://codereview.appspot.com/8700/diff/1/2#newcode64
Line 64: public InlineHyperlink(String text, String targetHistoryToken)
{
I'd expect this to be
this(text, false, targetHistoryToken);
Description:
Hello Ray :)
Would you take a look at this patch for the 1.6 branch, adding the
InlineHyperlink widget?
It adds a protected constructor to Hyperlink, allowing subclasses to
pass a wrapper element. If that element is null, it calls setElement
with the anchor element. InlineHyperlink then is just a Hyperlink
widget with no wrapping div.
Associated issue is here:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3056
Thanks!
--
Alex Rudnick
swe, gwt, atl
Please review this at http://codereview.appspot.com/8700
Affected files:
user/src/com/google/gwt/user/client/ui/Hyperlink.java
user/src/com/google/gwt/user/client/ui/InlineHyperlink.java
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4238 - releases/1.6/dev/core/src/com/google/gwt/dev/javac
Author: [EMAIL PROTECTED]
Date: Tue Dec 2 17:34:56 2008
New Revision: 4238
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java
Log:
Do not record binary types for units with errors, this can lead to an
invalid state.
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java
==
--- releases/1.6/dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java
(original)
+++ releases/1.6/dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java Tue
Dec 2 17:34:56 2008
@@ -103,7 +103,9 @@
CompilationUnitAdapter adapter = (CompilationUnitAdapter) icu;
CompilationUnit unit = adapter.getUnit();
unit.setJdtCud(cud);
- recordBinaryTypes(unit.getCompiledClasses());
+ if (!cud.compilationResult().hasErrors()) {
+recordBinaryTypes(unit.getCompiledClasses());
+ }
}
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4237 - releases/1.6
Author: [EMAIL PROTECTED] Date: Tue Dec 2 17:08:23 2008 New Revision: 4237 Modified: releases/1.6/branch-info.txt Log: Recording merge into trunk. Modified: releases/1.6/branch-info.txt == --- releases/1.6/branch-info.txt(original) +++ releases/1.6/branch-info.txtTue Dec 2 17:08:23 2008 @@ -14,8 +14,9 @@ /branches/[EMAIL PROTECTED]:4088 was merged (r4092) into this branch /releases/1.5/@r3863:4093 was merged (r4134) into this branch /releases/1.6/@r4025:4130 was merged (r4142) into trunk, superceding trunk:c4118 -/releases/1.6/@r4130:4147 was merged (r4148) into trunk, superceding trunk:c4118 +/releases/1.6/@r4130:4147 was merged (r4148) into trunk +/releases/1.6/@r4147:4198 was merged (r4202) into trunk > The next merge into trunk will be 4147: +---> The next merge into trunk will be 4198: -svn merge --accept postpone -r4147: https://google-web-toolkit.googlecode.com/svn/releases/1.6 . +svn merge --accept postpone -4198: https://google-web-toolkit.googlecode.com/svn/releases/1.6 . --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] small code review: Add InlineHyperlink widget
Hello Ray :)
Would you take a look at this patch for the 1.6 branch, adding the
InlineHyperlink widget?
It adds a protected constructor to Hyperlink, allowing subclasses to
pass a wrapper element. If that element is null, it calls setElement
with the anchor element. InlineHyperlink then is just a Hyperlink
widget with no wrapping div.
Associated issue is here:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3056
Thanks!
--
Alex Rudnick
swe, gwt, atl
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: user/src/com/google/gwt/user/client/ui/InlineHyperlink.java
===
--- user/src/com/google/gwt/user/client/ui/InlineHyperlink.java (revision 0)
+++ user/src/com/google/gwt/user/client/ui/InlineHyperlink.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;
+
+/**
+ * A widget that serves as an "internal" hyperlink. That is, it is a link to
+ * another state of the running application. It should behave exactly like
+ * [EMAIL PROTECTED] com.google.gwt.user.client.ui.Hyperlink}, save that it lays out
+ * as an inline element, not block.
+ *
+ * CSS Style Rules .gwt-InlineHyperlink { }
+ *
+ */
+public class InlineHyperlink extends Hyperlink {
+
+ /**
+ * Creates an empty hyperlink.
+ */
+ public InlineHyperlink() {
+super(null);
+
+setStyleName("gwt-InlineHyperlink");
+ }
+
+ /**
+ * Creates a hyperlink with its text and target history token specified.
+ *
+ * @param text the hyperlink's text
+ * @param asHTML true to treat the specified text as html
+ * @param targetHistoryToken the history token to which it will link
+ * @see #setTargetHistoryToken
+ */
+ public InlineHyperlink(String text, boolean asHTML, String targetHistoryToken) {
+this();
+
+if (asHTML) {
+ setHTML(text);
+} else {
+ setText(text);
+}
+setTargetHistoryToken(targetHistoryToken);
+ }
+
+ /**
+ * Creates a hyperlink with its text and target history token specified.
+ *
+ * @param text the hyperlink's text
+ * @param targetHistoryToken the history token to which it will link
+ */
+ public InlineHyperlink(String text, String targetHistoryToken) {
+this();
+setText(text);
+setTargetHistoryToken(targetHistoryToken);
+ }
+}
Property changes on: user/src/com/google/gwt/user/client/ui/InlineHyperlink.java
___
Name: svn:mime-type
+ text/x-java
Name: svn:eol-style
+ native
Index: user/src/com/google/gwt/user/client/ui/Hyperlink.java
===
--- user/src/com/google/gwt/user/client/ui/Hyperlink.java (revision 4235)
+++ user/src/com/google/gwt/user/client/ui/Hyperlink.java (working copy)
@@ -42,10 +42,7 @@
*
*
*
- * CSS Style Rules
- *
- * .gwt-Hyperlink { }
- *
+ * CSS Style Rules .gwt-Hyperlink { }
*
*
* Example [EMAIL PROTECTED] com.google.gwt.examples.HistoryExample}
@@ -55,7 +52,7 @@
HasClickHandlers {
private static HyperlinkImpl impl = GWT.create(HyperlinkImpl.class);
-
+
private Element anchorElem;
private String targetHistoryToken;
@@ -63,10 +60,7 @@
* Creates an empty hyperlink.
*/
public Hyperlink() {
-setElement(DOM.createDiv());
-DOM.appendChild(getElement(), anchorElem = DOM.createAnchor());
-sinkEvents(Event.ONCLICK);
-setStyleName("gwt-Hyperlink");
+this(DOM.createDiv());
}
/**
@@ -99,6 +93,20 @@
setTargetHistoryToken(targetHistoryToken);
}
+ protected Hyperlink(Element elem) {
+anchorElem = DOM.createAnchor();
+
+if (elem == null) {
+ setElement(anchorElem);
+} else {
+ setElement(elem);
+ DOM.appendChild(getElement(), anchorElem);
+}
+
+sinkEvents(Event.ONCLICK);
+setStyleName("gwt-Hyperlink");
+ }
+
public HandlerRegistration addClickHandler(ClickHandler handler) {
return addHandler(handler, ClickEvent.getType());
}
@@ -130,7 +138,7 @@
public void onBrowserEvent(Event event) {
if (DOM.eventGetType(event) == Event.ONCLICK) {
super.onBrowserEvent(event);
-
+
if (impl.handleAsClick(event)) {
History.newItem(getTargetHi
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4235.
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4235. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4235 Score: Positive General Comment: Looks sensible to me! Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4235 -- 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] TBR review needed on r4235 (date picker branch)
Tweaks in response to review of r4188. Use Labels instead of TextBoxes in examples, and explain use of VerticalPanel in DatePicker. http://code.google.com/p/google-web-toolkit/source/detail?r=4235 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4235 - in branches/1_6_datepicker: samples/showcase/src/com/google/gwt/sample/showcase/client/co...
Author: [EMAIL PROTECTED]
Date: Tue Dec 2 16:08:25 2008
New Revision: 4235
Modified:
branches/1_6_datepicker/samples/showcase/src/com/google/gwt/sample/showcase/client/content/widgets/CwDatePicker.java
branches/1_6_datepicker/user/javadoc/com/google/gwt/examples/DatePickerExample.java
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Log:
Tweaks in response to review of r4188. Use Labels instead of TextBoxes in
examples,
and explain use of VerticalPanel in DatePicker.
TBR: jlabanca
submitter: rjrjr
Modified:
branches/1_6_datepicker/samples/showcase/src/com/google/gwt/sample/showcase/client/content/widgets/CwDatePicker.java
==
---
branches/1_6_datepicker/samples/showcase/src/com/google/gwt/sample/showcase/client/content/widgets/CwDatePicker.java
(original)
+++
branches/1_6_datepicker/samples/showcase/src/com/google/gwt/sample/showcase/client/content/widgets/CwDatePicker.java
Tue Dec 2 16:08:25 2008
@@ -24,7 +24,7 @@
import
com.google.gwt.sample.showcase.client.ShowcaseAnnotations.ShowcaseSource;
import
com.google.gwt.sample.showcase.client.ShowcaseAnnotations.ShowcaseStyle;
import com.google.gwt.user.client.ui.HTML;
-import com.google.gwt.user.client.ui.TextBox;
+import com.google.gwt.user.client.ui.Label;
import com.google.gwt.user.client.ui.VerticalPanel;
import com.google.gwt.user.client.ui.Widget;
import com.google.gwt.user.datepicker.client.DateBox;
@@ -88,15 +88,14 @@
public Widget onInitialize() {
// Create a basic date picker
DatePicker datePicker = new DatePicker();
-final TextBox textBox = new TextBox();
-textBox.setEnabled(false);
+final Label text = new Label();
// Set the value in the text box when the user selects a date
datePicker.addValueChangeHandler(new ValueChangeHandler() {
public void onValueChange(ValueChangeEvent event) {
Date date = event.getValue();
String dateString =
DateTimeFormat.getMediumDateFormat().format(date);
-textBox.setValue(dateString);
+text.setText(dateString);
}
});
@@ -109,7 +108,7 @@
// Combine the widgets into a panel and return them
VerticalPanel vPanel = new VerticalPanel();
vPanel.add(new HTML(constants.cwDatePickerLabel()));
-vPanel.add(textBox);
+vPanel.add(text);
vPanel.add(datePicker);
vPanel.add(new HTML(constants.cwDatePickerBoxLabel()));
vPanel.add(dateBox);
Modified:
branches/1_6_datepicker/user/javadoc/com/google/gwt/examples/DatePickerExample.java
==
---
branches/1_6_datepicker/user/javadoc/com/google/gwt/examples/DatePickerExample.java
(original)
+++
branches/1_6_datepicker/user/javadoc/com/google/gwt/examples/DatePickerExample.java
Tue Dec 2 16:08:25 2008
@@ -19,8 +19,8 @@
import com.google.gwt.event.logical.shared.ValueChangeEvent;
import com.google.gwt.event.logical.shared.ValueChangeHandler;
import com.google.gwt.i18n.client.DateTimeFormat;
+import com.google.gwt.user.client.ui.Label;
import com.google.gwt.user.client.ui.RootPanel;
-import com.google.gwt.user.client.ui.TextBox;
import com.google.gwt.user.datepicker.client.DatePicker;
import java.util.Date;
@@ -30,14 +30,14 @@
public void onModuleLoad() {
// Create a date picker
DatePicker datePicker = new DatePicker();
-final TextBox textBox = new TextBox();
+final Label text = new Label();
// Set the value in the text box when the user selects a date
datePicker.addValueChangeHandler(new ValueChangeHandler() {
public void onValueChange(ValueChangeEvent event) {
Date date = event.getValue();
String dateString =
DateTimeFormat.getMediumDateFormat().format(date);
-textBox.setValue(dateString);
+text.setText(dateString);
}
});
@@ -45,7 +45,7 @@
datePicker.setValue(new Date(), true);
// Add the widgets to the page
-RootPanel.get().add(textBox);
+RootPanel.get().add(text);
RootPanel.get().add(datePicker);
}
}
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
==
---
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Tue Dec 2 16:08:25 2008
@@ -609,6 +609,10 @@
* Sets up the date picker.
*/
protected void setup() {
+/*
+ * Use a table (VerticalPanel) to get shrink-to-fit behavior. Divs
expand to
+ * fill the available width, so we'd need to give it a size.
+ */
VerticalPanel panel = new VerticalPanel();
initWidget(panel);
setStyle
[gwt-contrib] [google-web-toolkit commit] r4234 - releases/1.6/user/src/com/google/gwt/user/client/ui
Author: [EMAIL PROTECTED] Date: Tue Dec 2 15:38:29 2008 New Revision: 4234 Modified: releases/1.6/user/src/com/google/gwt/user/client/ui/HasValue.java Log: Loosen the contract on HasValue, and encourage (not require) use of setValue(null) to clear a widget. reviewer: ecc submitter: rjrjr Modified: releases/1.6/user/src/com/google/gwt/user/client/ui/HasValue.java == --- releases/1.6/user/src/com/google/gwt/user/client/ui/HasValue.java (original) +++ releases/1.6/user/src/com/google/gwt/user/client/ui/HasValue.java Tue Dec 2 15:38:29 2008 @@ -18,13 +18,10 @@ import com.google.gwt.event.logical.shared.HasValueChangeHandlers; /** - * An object that implements this interface should be a user input widget, where - * the user and programmer can both set and get the object's value. - * - * It is a requirement that a value passed to [EMAIL PROTECTED] setValue} be - * [EMAIL PROTECTED] Object#equals} to that returned by an immediately succeeding call to - * [EMAIL PROTECTED] getValue}, or that both be null. Note that this is not a requirement - * that setValue(null) be supported by all implementors. + * An object that implements this interface should be a user input + * widget, where the user and programmer can both set and get the + * object's value. It is intended to provide a unified interface to + * widgets with "atomic" values, like Strings and Dates. * * @param the type of value. */ @@ -43,6 +40,10 @@ * * It is acceptable to fail assertions or throw (documented) unchecked * exceptions in response to bad values. + * + * By convention, GWT widgets that can be cleared accept null for + * value, but it is acceptable for widgets that cannot + * be cleared to throw an exception for null values. * * @param value the object's new value */ --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Small code review, HasValue javadoc
Submitted r4234 On Tue, Dec 2, 2008 at 3:05 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > Seeing as we don't actually throw any of those yet, I'd like to stay > ambiguous on that front. > rjrjr > > > On Tue, Dec 2, 2008 at 2:58 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > >> Should we say that IllegalArgumentExceptions should be preferred for >> invalid input? >> Other then that, LGTM. >> >> >> On Tue, Dec 2, 2008 at 5:39 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: >> >>> Per our earlier conversation, softening the requirements on HasValue. >>> Intended for submission to releases/1.6 >>> rjrjr >>> >>> >> >> >> -- >> "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] r4233 - releases/1.6/dev/core/src/com/google/gwt/dev
Author: [EMAIL PROTECTED]
Date: Tue Dec 2 15:22:57 2008
New Revision: 4233
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/GWTCompiler.java
Log:
If there is an error during precompilation, then exit gracefully rather
than causing a null pointer exception.
Review by: scottb (desk check)
Modified: releases/1.6/dev/core/src/com/google/gwt/dev/GWTCompiler.java
==
--- releases/1.6/dev/core/src/com/google/gwt/dev/GWTCompiler.java
(original)
+++ releases/1.6/dev/core/src/com/google/gwt/dev/GWTCompiler.java Tue Dec
2 15:22:57 2008
@@ -152,6 +152,10 @@
Precompilation precompilation = Precompile.precompile(logger,
options,
module, options.getGenDir(), options.getCompilerWorkDir());
+if (precompilation == null) {
+ return false;
+}
+
Permutation[] allPerms = precompilation.getPermutations();
File[] resultFiles = CompilePerms.makeResultFiles(
options.getCompilerWorkDir(), allPerms);
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Small code review, HasValue javadoc
Seeing as we don't actually throw any of those yet, I'd like to stay ambiguous on that front. rjrjr On Tue, Dec 2, 2008 at 2:58 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > Should we say that IllegalArgumentExceptions should be preferred for > invalid input? > Other then that, LGTM. > > > On Tue, Dec 2, 2008 at 5:39 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > >> Per our earlier conversation, softening the requirements on HasValue. >> Intended for submission to releases/1.6 >> rjrjr >> >> > > > -- > "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: Small code review, HasValue javadoc
Should we say that IllegalArgumentExceptions should be preferred for invalid input? Other then that, LGTM. On Tue, Dec 2, 2008 at 5:39 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > Per our earlier conversation, softening the requirements on HasValue. > Intended for submission to releases/1.6 > rjrjr > > -- "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] Small code review, HasValue javadoc
Per our earlier conversation, softening the requirements on HasValue. Intended for submission to releases/1.6 rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- HasValue-doc-tweak-1.6-r4222.patch Description: Binary data
[gwt-contrib] [google-web-toolkit] EmilyCrutcher commented on revision r4232.
[google-web-toolkit] EmilyCrutcher commented on revision r4232. Details are at http://code.google.com/p/google-web-toolkit/source/detail?r=4232 Score: Positive General Comment: LGTM. Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4232 -- 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] r4232 - branches/1_6_datepicker/user/test/com/google/gwt/user/client/ui
Author: [EMAIL PROTECTED]
Date: Tue Dec 2 14:14:39 2008
New Revision: 4232
Modified:
branches/1_6_datepicker/user/test/com/google/gwt/user/client/ui/DateValueChangeTester.java
branches/1_6_datepicker/user/test/com/google/gwt/user/client/ui/TextBoxBaseTestBase.java
Log:
Punches up testing to ensure that setValue(null) works, and that the
default value of HasValue objects is null.
TBR ecc
submitted by rjrjr
Modified:
branches/1_6_datepicker/user/test/com/google/gwt/user/client/ui/DateValueChangeTester.java
==
---
branches/1_6_datepicker/user/test/com/google/gwt/user/client/ui/DateValueChangeTester.java
(original)
+++
branches/1_6_datepicker/user/test/com/google/gwt/user/client/ui/DateValueChangeTester.java
Tue Dec 2 14:14:39 2008
@@ -35,22 +35,36 @@
}
private final HasValue subject;
+
+ /**
+ * The HasValue to be tested. It should have been freshly created
+ * before handing it to this tester.
+ */
public DateValueChangeTester(HasValue subject) {
this.subject = subject;
}
+ /**
+ * Asserts that the default value is null, checks that value change
+ * events do and don't fire when appropriate, and that getValue() always
+ * returns what was handed to getValue().
+ */
@SuppressWarnings("deprecation")
public void run() {
+TestCase.assertNull(subject.getValue());
+
+DateValueChangeTester.Handler h = new Handler();
+subject.addValueChangeHandler(h);
+
subject.setValue(null);
TestCase.assertNull(subject.getValue());
+TestCase.assertNull(h.received);
Date able = new Date(1999, 5, 15);
subject.setValue(able);
TestCase.assertEquals(able, subject.getValue());
-
-DateValueChangeTester.Handler h = new Handler();
-subject.addValueChangeHandler(h);
-
+TestCase.assertNull(h.received);
+
subject.setValue(able);
TestCase.assertNull(h.received);
Modified:
branches/1_6_datepicker/user/test/com/google/gwt/user/client/ui/TextBoxBaseTestBase.java
==
---
branches/1_6_datepicker/user/test/com/google/gwt/user/client/ui/TextBoxBaseTestBase.java
(original)
+++
branches/1_6_datepicker/user/test/com/google/gwt/user/client/ui/TextBoxBaseTestBase.java
Tue Dec 2 14:14:39 2008
@@ -98,11 +98,16 @@
public void testValueChangeEvent() {
TextBoxBase tb = createTextBoxBase();
-
// To work cross-platform, the tb must be added to the root panel.
RootPanel.get().add(tb);
+
Handler h = new Handler();
tb.addValueChangeHandler(h);
+
+tb.setValue(null);
+assertEquals("", tb.getValue());
+assertNull(h.received);
+
tb.setText("able");
assertEquals("able", tb.getValue());
assertNull(h.received);
@@ -110,6 +115,7 @@
tb.setValue("able");
assertEquals("able", tb.getValue());
assertNull(h.received);
+
tb.setValue("baker");
assertNull(h.received);
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4231 - trunk/distro-source/windows
Author: [EMAIL PROTECTED] Date: Tue Dec 2 13:39:50 2008 New Revision: 4231 Modified: trunk/distro-source/windows/build.xml Log: Fix distro build file for Windows. Patch by: amitmanjhi Review by: jat Modified: trunk/distro-source/windows/build.xml == --- trunk/distro-source/windows/build.xml (original) +++ trunk/distro-source/windows/build.xml Tue Dec 2 13:39:50 2008 @@ -9,7 +9,7 @@ - + --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: TabPanel feature request
> > A flag on the TabPanel/DeckPanel would be a better solution, I would just > subclass and make sure that the lazy attachment is used on all our panels. > That I could get away with, but still I find it a pitty that it is not the > default behaviour. > D > Yes, for new widgets that is exactly what we'd do. > avid > >> >> On Tue, Dec 2, 2008 at 3:04 AM, stuckagain <[EMAIL PROTECTED]> wrote: >> >>> >>> Thanks for the great comments! >>> >>> It turns out that this bug is already reported (and 5 stars as well) >>> in the issue database. >>> jlaba is the owner of the bug and priority is medium >>> >>> Here is the bug report: >>> http://code.google.com/p/google-web-toolkit/issues/detail?id=1902 >>> >>> David >>> >>> On Nov 27, 8:51 am, stuckagain <[EMAIL PROTECTED]> wrote: >>> > People, >>> > >>> > I recently read about lazy loading panels >>> http://googlewebtoolkit.blogspot.com/2008/11/profiling-gwt-applicatio... >>> > >>> > I am actually asking for offering lazy attaching tabpanels as a >>> > default implementation. In most cases you only get a >>> > performance problem when you attach the Widgets to the DOM tree, >>> > creating the UI without attaching is done in milliseconds. >>> > >>> > In case of a TabPabel it can sometimes be very cumbersome to use lazy >>> > loading for the different tabs. Loading it lazily is easy, but >>> > gathering information from multiple tabs to post to the server must >>> > take into account that maybe the widgets are null... that makes the >>> > code much more complicated than it should be. >>> > >>> > By deferring attaching to the DOM tree until first shown, all this is >>> > not needed. Creating the widgets is most of the time very fast, it is >>> > only when they get attached that the Browser shokes. When I was >>> > experimenting with tables in IE6 for example, I could build up a table >>> > of 250 rows in memory in a few milliseconds, but as soon as I attached >>> > the table, I lost 8 seconds that the Browser was not responsive. >>> > >>> > So,... anybody cares about the subject ? Can I create a functional >>> > request in the issues database or do I have to shut up and move over >>> > to the other GWT group ? >>> > >>> > David >>> > >>> > On Nov 24, 11:46 am, stuckagain <[EMAIL PROTECTED]> wrote: >>> > >>> > >>> > >>> > > Hi, >>> > >>> > > I'm having a problem with theTabPanelbehaviour. >>> > >>> > > I've created a widget that uses absolute positioning internally to >>> get >>> > > a certain effect. The DIV that surrounds it is sized correctly in the >>> > > onLoad method, based on the size of the absolutely positioned >>> element. >>> > >>> > > All this works fine except in the case where this widget is used in >>> aTabPanel. >>> > >>> > > If the widget is not put in the visible tab at the moment of >>> > > attachement, then the size calucation fails because I always get 0 as >>> > > a response. The widget is attached but not visible ... that makes >>> > > sense. >>> > >>> > > I would like to suggest an alternative approach in thetabpanel, to >>> > > postpone calling onLoad until the tab is actually shown the first >>> > > time. >>> > >>> > > The obvious workaround for the moment is ofcourse to add the tab >>> panel >>> > > lazily to make sure that the onLoad is only triggered when the tab is >>> > > made visible but this is a generaly reusable component and I do not >>> > > control the use of the component. >>> > >>> > > I avoided the problem by showing the widget with display:none on the >>> > > RootPanel, the same trick as used in the popup panel, because that >>> was >>> > > easier to hide from the calling code... but the calculation can fail >>> > > due to different CSS rules being applied when attached to another >>> > > parent DOM element. >>> > >>> > > David- Hide quoted text - >>> > >>> > - Show quoted text - >>> >>> >> >> >> > > > -- "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: incubator code review
The problem is that both versions on these widgets need to exist simultaneously for a period of time, to give our users enough space to move from the deprecated version to the non-deprecated one. For date picker, in specific, because it will be in the first 1.6 milestone, it does not seem worth people's time to migrate from widgetideas to the gen2 version at this late date, as while we will leave the date picker in gwt-incubator as a convenience, both versions will be deprecated within a matter of a couple of more weeks. On Tue, Dec 2, 2008 at 12:07 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: > > Is that going to turn into a revolving door of new packages as each > generation of widgets requires it's own namespace? It seems to me that > the gen2 package idea was a mistake of convenience and maybe should > have been a branch (or branches) that got merged back into trunk once > it stabilized. > > > On Tue, Dec 2, 2008 at 11:57 AM, John LaBanca <[EMAIL PROTECTED]> wrote: > > Is this a good idea? I think we should just deprecate the widgetideas > > version now in favor of the gen2 version. I didn't attempt to copy > > ScrollTable changes back to the widgetideas version, it would be a > > nightmare. IMHO, development on widgetideas code should be closed once a > > gen2 replacement is available. > > > > Thanks, > > John LaBanca > > [EMAIL PROTECTED] > > > > > > On Tue, Dec 2, 2008 at 11:48 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > >> > >> Code review request: > >> > http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1250 > >> > >> Copying gen2-DropDownPanel over the widgetideas-DropDownPanel rather > then > >> patching the widgetideas version, as this way we only maintain one > version > >> of DropDownPanel, which is going to be depricated as soon as the first > 1.6 > >> milestone is released. > >> > >> > >> -- > >> "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] Re: TabPanel feature request
The constructor flag is a great idea. David, would you mind logging an issue to that effect? On Tue, Dec 2, 2008 at 11:58 AM, David <[EMAIL PROTECTED]> wrote: > >> I didn't see any comments... oh, sarcasm =) >> > > I'm not going to repeat myself... but there is room for improvement on how > bugs and feature requests are treated! > > > >> Since the TabPanel (really the DeckPanel) currently attaches widgets to >> the DOM immediately, we might have backward compatibility issues if we >> attach them lazily. We could make lazy attachment an optional setting >> though. > > > OK, I understand how that can cause troubles. > > An alternative that should work for your use case is to use the fact that >> DeckPanel calls setVisible(true) when a widget is shown (which the LazyPanel >> exploits to render lazily). You could create your widget in the >> constructor, but don't attach the inner components to the outermost >> component until setVisible(true) is called the first time. Then you'd have >> your widget DOM structure available for manipulation, but you don't pay the >> render time in the browser. >> > > The LazyPanel sounds like a workable solution, if I am the only developer > in the team and/or everything is in one big project. But that is not the > case, I do not have control on how they are using it. I could document it as > a workaround, but still everybody who uses a TabPanel in which they might > use one of these widgets (somewhere hidden in a Composite panel) must > implement the workaround. There must be a solution that would avoid the need > for workarounds - it just moves complications to all the users of a > component and becomes a maintenance problem in the end. > > A flag on the TabPanel/DeckPanel would be a better solution, I would just > subclass and make sure that the lazy attachment is used on all our panels. > That I could get away with, but still I find it a pitty that it is not the > default behaviour. > > > David > >> >> On Tue, Dec 2, 2008 at 3:04 AM, stuckagain <[EMAIL PROTECTED]> wrote: >> >>> >>> Thanks for the great comments! >>> >>> It turns out that this bug is already reported (and 5 stars as well) >>> in the issue database. >>> jlaba is the owner of the bug and priority is medium >>> >>> Here is the bug report: >>> http://code.google.com/p/google-web-toolkit/issues/detail?id=1902 >>> >>> David >>> >>> On Nov 27, 8:51 am, stuckagain <[EMAIL PROTECTED]> wrote: >>> > People, >>> > >>> > I recently read about lazy loading panels >>> http://googlewebtoolkit.blogspot.com/2008/11/profiling-gwt-applicatio... >>> > >>> > I am actually asking for offering lazy attaching tabpanels as a >>> > default implementation. In most cases you only get a >>> > performance problem when you attach the Widgets to the DOM tree, >>> > creating the UI without attaching is done in milliseconds. >>> > >>> > In case of a TabPabel it can sometimes be very cumbersome to use lazy >>> > loading for the different tabs. Loading it lazily is easy, but >>> > gathering information from multiple tabs to post to the server must >>> > take into account that maybe the widgets are null... that makes the >>> > code much more complicated than it should be. >>> > >>> > By deferring attaching to the DOM tree until first shown, all this is >>> > not needed. Creating the widgets is most of the time very fast, it is >>> > only when they get attached that the Browser shokes. When I was >>> > experimenting with tables in IE6 for example, I could build up a table >>> > of 250 rows in memory in a few milliseconds, but as soon as I attached >>> > the table, I lost 8 seconds that the Browser was not responsive. >>> > >>> > So,... anybody cares about the subject ? Can I create a functional >>> > request in the issues database or do I have to shut up and move over >>> > to the other GWT group ? >>> > >>> > David >>> > >>> > On Nov 24, 11:46 am, stuckagain <[EMAIL PROTECTED]> wrote: >>> > >>> > >>> > >>> > > Hi, >>> > >>> > > I'm having a problem with theTabPanelbehaviour. >>> > >>> > > I've created a widget that uses absolute positioning internally to >>> get >>> > > a certain effect. The DIV that surrounds it is sized correctly in the >>> > > onLoad method, based on the size of the absolutely positioned >>> element. >>> > >>> > > All this works fine except in the case where this widget is used in >>> aTabPanel. >>> > >>> > > If the widget is not put in the visible tab at the moment of >>> > > attachement, then the size calucation fails because I always get 0 as >>> > > a response. The widget is attached but not visible ... that makes >>> > > sense. >>> > >>> > > I would like to suggest an alternative approach in thetabpanel, to >>> > > postpone calling onLoad until the tab is actually shown the first >>> > > time. >>> > >>> > > The obvious workaround for the moment is ofcourse to add the tab >>> panel >>> > > lazily to make sure that the onLoad is only triggered when the tab is >>> > > made visible but this is a generaly reusabl
[gwt-contrib] Re: Removing HasValue interface from gwt-incubator
LGTM Thanks, John LaBanca [EMAIL PROTECTED] On Tue, Dec 2, 2008 at 3:46 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > John, > > Could you review this change? Unfortunately, HasValue from incubator > directly conflicts with HasValue from gwt-trunk. Therefore creating a nasty > path-dependency problem, the current solution is to remove HasValue from > gwt-incubator: > > http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1253 > > -- > "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] Removing HasValue interface from gwt-incubator
John, Could you review this change? Unfortunately, HasValue from incubator directly conflicts with HasValue from gwt-trunk. Therefore creating a nasty path-dependency problem, the current solution is to remove HasValue from gwt-incubator: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1253 -- "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] r4230 - trunk/tools/soyc-vis/src/com/google/gwt/soyc
Author: [EMAIL PROTECTED]
Date: Tue Dec 2 12:27:03 2008
New Revision: 4230
Modified:
trunk/tools/soyc-vis/src/com/google/gwt/soyc/GlobalInformation.java
trunk/tools/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
trunk/tools/soyc-vis/src/com/google/gwt/soyc/SoycDashboard.java
Log:
- now displaying dependencies at the class level
- improved table layout
Modified:
trunk/tools/soyc-vis/src/com/google/gwt/soyc/GlobalInformation.java
==
--- trunk/tools/soyc-vis/src/com/google/gwt/soyc/GlobalInformation.java
(original)
+++ trunk/tools/soyc-vis/src/com/google/gwt/soyc/GlobalInformation.java Tue
Dec 2 12:27:03 2008
@@ -33,7 +33,7 @@
public static HashMap classToPackage = new
HashMap();
//TODO(kprobst): not currently used, but will be for dependencies
- //public static HashMap> classToWhatItDependsOn
= new HashMap>();
+ public static HashMap> classToWhatItDependsOn =
new HashMap>();
public static HashMap classToSize = new HashMap();
public static HashMap classToPartialSize = new
HashMap();
Modified:
trunk/tools/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
==
---
trunk/tools/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
(original)
+++
trunk/tools/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
Tue Dec 2 12:27:03 2008
@@ -510,7 +510,7 @@
float maxSize = 0f;
//TODO(kprobst): not currently used, but will be for dependencies
- //int maxDepCount = 0;
+ int maxDepCount = 1;
for (String className :
GlobalInformation.packageToClasses.get(packageName)){
@@ -523,10 +523,10 @@
}
//TODO(kprobst): not currently used, but will be for dependencies
-/*int depCount = 0;
+int depCount = 0;
if
(GlobalInformation.classToWhatItDependsOn.containsKey(className)){
depCount =
GlobalInformation.classToWhatItDependsOn.get(className).size();
-}*/
+}
if (curSize != 0f){
@@ -535,9 +535,9 @@
maxSize = curSize;
}
//TODO(kprobst): not currently used, but will be for dependencies
- /*if (depCount > maxDepCount){
+ if (depCount > maxDepCount){
maxDepCount = depCount;
- }*/
+ }
}
}
@@ -569,23 +569,23 @@
String className = sortedClasses.get(size);
//TODO(kprobst): switch out the commented/uncommented lines below
when showing dependencies
-//float ratio = (size / maxSize) * 45;
-float ratio = (size / maxSize) * 85;
+float ratio = (size / maxSize) * 45;
+//float ratio = (size / maxSize) * 85;
if (ratio < 3){
ratio = 3;
}
//TODO(kprobst): not currently used, but will be for dependencies
-/*// get the dependency count
+ // get the dependency count
int depCount = 0;
if
(GlobalInformation.classToWhatItDependsOn.containsKey(className)){
depCount =
GlobalInformation.classToWhatItDependsOn.get(className).size();
}
-float depRatio = (depCount / maxDepCount) * 25;
-if (depRatio < 3){
+float depRatio = ((float)depCount / (float)maxDepCount) * 45f;
+if (depRatio < 3.0){
depRatio = 3;
-}*/
+}
outFile.println("");
outFile.println("");
@@ -601,7 +601,7 @@
//TODO(kprobst): not currently used, but will be for dependencies
// place holder for mock-up of dependency display
-/*outFile.println("");
+outFile.println("");
outFile.println("");
outFile.println("");
outFile.println("");
@@ -611,22 +611,13 @@
outFile.println("");
outFile.println("");
outFile.println("");
-
-
-outFile.println("");
-outFile.println("");
-outFile.println("");
-outFile.println("");
-outFile.println("");
-outFile.println("");
-outFile.println("");
-outFile.println("");
-outFile.println("");
-outFile.println(""); */
-
+
int yOffsetText = yOffset+8;
outFile.printf("%.1f\n", size);
outFile.println(""+className+"");
+//TODO(kprobst) make this a link
+String drillDownFileName = className + "Deps.html";
+outFile.println("Dependencies: " + depCount + "");
yOffset = yOffset + 25;
@@ -723,7 +714,7 @@
int yOffsetText = yOffset+8;
outFile.printf("%.1f\n", size);
-outFile.println(""+className+"");
+ outFile.println(""+className+"");
yOffset = yOffset + 25;
@@ -737,6 +728,112 @@
}
+ public static void makeLiteralsClassesTableHtmls(TreeMap nameToLitColl) throws IOEx
[gwt-contrib] [google-web-toolkit commit] r4229 - changes/jat/oophm-plugins-trunk/sdk
Author: [EMAIL PROTECTED] Date: Tue Dec 2 12:13:50 2008 New Revision: 4229 Added: changes/jat/oophm-plugins-trunk/sdk/ - copied from r4228, /tools/sdk/ Log: Copy tools/sdk into change branch. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4228 - changes/jat/oophm-plugins-trunk/plugins
Author: [EMAIL PROTECTED] Date: Tue Dec 2 12:12:32 2008 New Revision: 4228 Added: changes/jat/oophm-plugins-trunk/plugins/ - copied from r4227, /branches/oophm/plugins/ Log: Copy plugins directory from branches/oophm to change branch. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4227 - changes/jat/oophm-plugins-trunk
Author: [EMAIL PROTECTED] Date: Tue Dec 2 12:12:01 2008 New Revision: 4227 Added: changes/jat/oophm-plugins-trunk/ Log: Create change branch for OOPHM XPCOM plugin changes to support FF2/3, associated build sytem changes, and required libraries/includes. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: TabPanel feature request
> > > I didn't see any comments... oh, sarcasm =) > I'm not going to repeat myself... but there is room for improvement on how bugs and feature requests are treated! > Since the TabPanel (really the DeckPanel) currently attaches widgets to the > DOM immediately, we might have backward compatibility issues if we attach > them lazily. We could make lazy attachment an optional setting though. OK, I understand how that can cause troubles. An alternative that should work for your use case is to use the fact that > DeckPanel calls setVisible(true) when a widget is shown (which the LazyPanel > exploits to render lazily). You could create your widget in the > constructor, but don't attach the inner components to the outermost > component until setVisible(true) is called the first time. Then you'd have > your widget DOM structure available for manipulation, but you don't pay the > render time in the browser. > The LazyPanel sounds like a workable solution, if I am the only developer in the team and/or everything is in one big project. But that is not the case, I do not have control on how they are using it. I could document it as a workaround, but still everybody who uses a TabPanel in which they might use one of these widgets (somewhere hidden in a Composite panel) must implement the workaround. There must be a solution that would avoid the need for workarounds - it just moves complications to all the users of a component and becomes a maintenance problem in the end. A flag on the TabPanel/DeckPanel would be a better solution, I would just subclass and make sure that the lazy attachment is used on all our panels. That I could get away with, but still I find it a pitty that it is not the default behaviour. David > > On Tue, Dec 2, 2008 at 3:04 AM, stuckagain <[EMAIL PROTECTED]> wrote: > >> >> Thanks for the great comments! >> >> It turns out that this bug is already reported (and 5 stars as well) >> in the issue database. >> jlaba is the owner of the bug and priority is medium >> >> Here is the bug report: >> http://code.google.com/p/google-web-toolkit/issues/detail?id=1902 >> >> David >> >> On Nov 27, 8:51 am, stuckagain <[EMAIL PROTECTED]> wrote: >> > People, >> > >> > I recently read about lazy loading panels >> http://googlewebtoolkit.blogspot.com/2008/11/profiling-gwt-applicatio... >> > >> > I am actually asking for offering lazy attaching tabpanels as a >> > default implementation. In most cases you only get a >> > performance problem when you attach the Widgets to the DOM tree, >> > creating the UI without attaching is done in milliseconds. >> > >> > In case of a TabPabel it can sometimes be very cumbersome to use lazy >> > loading for the different tabs. Loading it lazily is easy, but >> > gathering information from multiple tabs to post to the server must >> > take into account that maybe the widgets are null... that makes the >> > code much more complicated than it should be. >> > >> > By deferring attaching to the DOM tree until first shown, all this is >> > not needed. Creating the widgets is most of the time very fast, it is >> > only when they get attached that the Browser shokes. When I was >> > experimenting with tables in IE6 for example, I could build up a table >> > of 250 rows in memory in a few milliseconds, but as soon as I attached >> > the table, I lost 8 seconds that the Browser was not responsive. >> > >> > So,... anybody cares about the subject ? Can I create a functional >> > request in the issues database or do I have to shut up and move over >> > to the other GWT group ? >> > >> > David >> > >> > On Nov 24, 11:46 am, stuckagain <[EMAIL PROTECTED]> wrote: >> > >> > >> > >> > > Hi, >> > >> > > I'm having a problem with theTabPanelbehaviour. >> > >> > > I've created a widget that uses absolute positioning internally to get >> > > a certain effect. The DIV that surrounds it is sized correctly in the >> > > onLoad method, based on the size of the absolutely positioned element. >> > >> > > All this works fine except in the case where this widget is used in >> aTabPanel. >> > >> > > If the widget is not put in the visible tab at the moment of >> > > attachement, then the size calucation fails because I always get 0 as >> > > a response. The widget is attached but not visible ... that makes >> > > sense. >> > >> > > I would like to suggest an alternative approach in thetabpanel, to >> > > postpone calling onLoad until the tab is actually shown the first >> > > time. >> > >> > > The obvious workaround for the moment is ofcourse to add the tab panel >> > > lazily to make sure that the onLoad is only triggered when the tab is >> > > made visible but this is a generaly reusable component and I do not >> > > control the use of the component. >> > >> > > I avoided the problem by showing the widget with display:none on the >> > > RootPanel, the same trick as used in the popup panel, because that was >> > > easier to hide from the calling code... but the calculation can fail >>
[gwt-contrib] [google-web-toolkit commit] r4226 - releases/1.6/user/src/com/google/gwt/user/tools
Author: [EMAIL PROTECTED]
Date: Tue Dec 2 11:00:01 2008
New Revision: 4226
Modified:
releases/1.6/user/src/com/google/gwt/user/tools/App.launchsrc
releases/1.6/user/src/com/google/gwt/user/tools/ApplicationCreator.java
releases/1.6/user/src/com/google/gwt/user/tools/project.ant.xmlsrc
Log:
Minor changes in r4222 that John suggested.
Patch by: amitmanjhi
Review by: jat (desk review)
Modified: releases/1.6/user/src/com/google/gwt/user/tools/App.launchsrc
==
--- releases/1.6/user/src/com/google/gwt/user/tools/App.launchsrc
(original)
+++ releases/1.6/user/src/com/google/gwt/user/tools/App.launchsrc Tue Dec
2 11:00:01 2008
@@ -9,7 +9,7 @@
@eclipseExtraLaunchPaths
-
+
Modified:
releases/1.6/user/src/com/google/gwt/user/tools/ApplicationCreator.java
==
--- releases/1.6/user/src/com/google/gwt/user/tools/ApplicationCreator.java
(original)
+++ releases/1.6/user/src/com/google/gwt/user/tools/ApplicationCreator.java
Tue Dec 2 11:00:01 2008
@@ -307,9 +307,9 @@
replacements.put("@shellClass", "com.google.gwt.dev.GWTHosted");
replacements.put("@compileClass", "com.google.gwt.dev.GWTCompiler");
replacements.put("@startupUrl", startupUrl);
-replacements.put("@vmargs", isMacOsX
+replacements.put("@antVmargs", isMacOsX
? "" : "");
-replacements.put("@eclipseVmargs",
isMacOsX ? "-XstartOnFirstThread" : "");
+replacements.put("@vmargs", isMacOsX ? "-XstartOnFirstThread" : "");
replacements.put("@eclipseExtraLaunchPaths",
CreatorUtilities.createEclipseExtraLaunchPaths(extraClassPaths));
replacements.put("@extraModuleInherits",
Modified: releases/1.6/user/src/com/google/gwt/user/tools/project.ant.xmlsrc
==
--- releases/1.6/user/src/com/google/gwt/user/tools/project.ant.xmlsrc
(original)
+++ releases/1.6/user/src/com/google/gwt/user/tools/project.ant.xmlsrc Tue
Dec 2 11:00:01 2008
@@ -50,8 +50,9 @@
+
- @vmargs
+ @antVmargs
@@ -71,7 +72,7 @@
- @vmargs
+ @antVmargs
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4225 - in releases/1.6/user/src/com/google/gwt/user: . client/ui client/ui/impl
Author: [EMAIL PROTECTED]
Date: Tue Dec 2 10:37:04 2008
New Revision: 4225
Added:
releases/1.6/user/src/com/google/gwt/user/Hyperlink.gwt.xml
releases/1.6/user/src/com/google/gwt/user/client/ui/impl/HyperlinkImpl.java
(contents, props changed)
releases/1.6/user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplIE.java
(contents, props changed)
releases/1.6/user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplOpera.java
(contents, props changed)
releases/1.6/user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplSafari.java
(contents, props changed)
Modified:
releases/1.6/user/src/com/google/gwt/user/User.gwt.xml
releases/1.6/user/src/com/google/gwt/user/client/ui/Hyperlink.java
Log:
Rolls behavior from incubator's HyperlinkOverride into Hyperlink. Now
Hyperlink
will let the default browser action happen in some cases, eg Ctrl-clicking
on a
link. Particular behavior is specific per browser.
patch by: ajr
review by: rjrjr
Added: releases/1.6/user/src/com/google/gwt/user/Hyperlink.gwt.xml
==
--- (empty file)
+++ releases/1.6/user/src/com/google/gwt/user/Hyperlink.gwt.xml Tue Dec 2
10:37:04 2008
@@ -0,0 +1,19 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Modified: releases/1.6/user/src/com/google/gwt/user/User.gwt.xml
==
--- releases/1.6/user/src/com/google/gwt/user/User.gwt.xml (original)
+++ releases/1.6/user/src/com/google/gwt/user/User.gwt.xml Tue Dec 2
10:37:04 2008
@@ -39,6 +39,7 @@
+
Modified: releases/1.6/user/src/com/google/gwt/user/client/ui/Hyperlink.java
==
--- releases/1.6/user/src/com/google/gwt/user/client/ui/Hyperlink.java
(original)
+++ releases/1.6/user/src/com/google/gwt/user/client/ui/Hyperlink.java Tue
Dec 2 10:37:04 2008
@@ -15,6 +15,7 @@
*/
package com.google.gwt.user.client.ui;
+import com.google.gwt.core.client.GWT;
import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
import com.google.gwt.event.dom.client.HasClickHandlers;
@@ -23,6 +24,7 @@
import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.Event;
import com.google.gwt.user.client.History;
+import com.google.gwt.user.client.ui.impl.HyperlinkImpl;
/**
* A widget that serves as an "internal" hyperlink. That is, it is a link
to
@@ -52,6 +54,8 @@
public class Hyperlink extends Widget implements HasHTML,
SourcesClickEvents,
HasClickHandlers {
+ private static HyperlinkImpl impl = GWT.create(HyperlinkImpl.class);
+
private Element anchorElem;
private String targetHistoryToken;
@@ -126,8 +130,11 @@
public void onBrowserEvent(Event event) {
if (DOM.eventGetType(event) == Event.ONCLICK) {
super.onBrowserEvent(event);
- History.newItem(targetHistoryToken);
- DOM.eventPreventDefault(event);
+
+ if (impl.handleAsClick(event)) {
+History.newItem(getTargetHistoryToken());
+DOM.eventPreventDefault(event);
+ }
}
}
Added:
releases/1.6/user/src/com/google/gwt/user/client/ui/impl/HyperlinkImpl.java
==
--- (empty file)
+++
releases/1.6/user/src/com/google/gwt/user/client/ui/impl/HyperlinkImpl.java
Tue Dec 2 10:37:04 2008
@@ -0,0 +1,45 @@
+/*
+ * 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;
+
+/**
+ * Methods that need browser-specific implementations for Hyperlink.
+ * By default, we're very conservative and let the browser handle any
clicks
+ * with non-left buttons or with modifier keys. This happens to be the
correct
+ * behavior for Firefox.
+ */
+public class HyperlinkImpl {
+
+ /**
+ * Default version, useful for Firefox. Don't fire if it's a rightclick,
+ * middleclick, or if any modifiers are held down.
+ */
+ public boolean handleAsClick(Event event) {
+int mouseButtons = event.getButton();
+boolean alt = event.getAltKey();
+boolean ctrl = event.getCtrlKey();
+boolean meta = event.getMetaKey();
+boolean shift =
[gwt-contrib] Re: RR, code review request: merge HyperlinkOverride into Hyperlink widget
Fantastic, thanks! :) Tweaked to do initialization on the declaration lines for those static variables. Committed r4225. On Tue, Dec 2, 2008 at 12:50 PM, <[EMAIL PROTECTED]> wrote: > Reviewers: rjrjr, > > Message: > This looks great to me, Alex. And I think you're doing as right a thing > as you can WRT Chrome. Just a couple of nits noted below. > > > http://codereview.appspot.com/8696/diff/1/4 > File user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplIE.java > (right): > > http://codereview.appspot.com/8696/diff/1/4#newcode31 > Line 31: ctrlisModifier = (getInternetExplorerVersion() >= 7); > Why the static block? Seems like you can just do this inline. > > http://codereview.appspot.com/8696/diff/1/5 > File > user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplSafari.java > (right): > > http://codereview.appspot.com/8696/diff/1/5#newcode31 > Line 31: shiftIsModifier = onChrome(); > again, don't see the need for the block. > > Description: > 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 > > > Please review this at http://codereview.appspot.com/8696 > > Affected files: > user/src/com/google/gwt/user/Hyperlink.gwt.xml > user/src/com/google/gwt/user/User.gwt.xml > user/src/com/google/gwt/user/client/ui/Hyperlink.java > user/src/com/google/gwt/user/client/ui/impl/HyperlinkImpl.java > user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplIE.java > user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplOpera.java > user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplSafari.java > > > -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4224 - trunk/dev/core/src/com/google/gwt/dev/util
Author: [EMAIL PROTECTED] Date: Tue Dec 2 10:32:41 2008 New Revision: 4224 Modified: trunk/dev/core/src/com/google/gwt/dev/util/Util.java Log: Removing bad import, desk check by spoon. Modified: trunk/dev/core/src/com/google/gwt/dev/util/Util.java == --- trunk/dev/core/src/com/google/gwt/dev/util/Util.java(original) +++ trunk/dev/core/src/com/google/gwt/dev/util/Util.javaTue Dec 2 10:32:41 2008 @@ -45,7 +45,6 @@ import java.io.OutputStream; import java.io.OutputStreamWriter; import java.io.PrintWriter; -import java.io.RandomAccessFile; import java.io.Reader; import java.io.Serializable; import java.io.StringWriter; --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4223 - releases/1.6/user/javadoc/com/google/gwt/examples
Author: [EMAIL PROTECTED]
Date: Tue Dec 2 10:22:02 2008
New Revision: 4223
Modified:
releases/1.6/user/javadoc/com/google/gwt/examples/LazyPanelExample.java
Log:
Per jlabanca's review feedback, lowered cuteness and explained
setVisible(false) call.
reviewed by jlabanca
submitted by rjrjr
Modified:
releases/1.6/user/javadoc/com/google/gwt/examples/LazyPanelExample.java
==
--- releases/1.6/user/javadoc/com/google/gwt/examples/LazyPanelExample.java
(original)
+++ releases/1.6/user/javadoc/com/google/gwt/examples/LazyPanelExample.java
Tue Dec 2 10:22:02 2008
@@ -26,10 +26,7 @@
public class LazyPanelExample implements EntryPoint {
- /**
- * A friendly little LazyPanel.
- */
- static class HelloLazy extends LazyPanel {
+ private static class HelloLazyPanel extends LazyPanel {
@Override
protected Widget createWidget() {
return new Label("Well hello there!");
@@ -37,7 +34,10 @@
}
public void onModuleLoad() {
-final Widget lazy = new HelloLazy();
+final Widget lazy = new HelloLazyPanel();
+
+// Not strictly necessary, but keeps the empty outer div
+// from effecting layout before it is of any use
lazy.setVisible(false);
PushButton b = new PushButton("Click me");
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review: LazyPanelExample tweaks
LGTM Thanks, John LaBanca [EMAIL PROTECTED] On Tue, Dec 2, 2008 at 12:36 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > Per your review feedback, lowered cuteness and explained setVisible(false) > call. > rjrjr > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR, code review request: merge HyperlinkOverride into Hyperlink widget
Reviewers: rjrjr, Message: This looks great to me, Alex. And I think you're doing as right a thing as you can WRT Chrome. Just a couple of nits noted below. http://codereview.appspot.com/8696/diff/1/4 File user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplIE.java (right): http://codereview.appspot.com/8696/diff/1/4#newcode31 Line 31: ctrlisModifier = (getInternetExplorerVersion() >= 7); Why the static block? Seems like you can just do this inline. http://codereview.appspot.com/8696/diff/1/5 File user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplSafari.java (right): http://codereview.appspot.com/8696/diff/1/5#newcode31 Line 31: shiftIsModifier = onChrome(); again, don't see the need for the block. Description: 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 Please review this at http://codereview.appspot.com/8696 Affected files: user/src/com/google/gwt/user/Hyperlink.gwt.xml user/src/com/google/gwt/user/User.gwt.xml user/src/com/google/gwt/user/client/ui/Hyperlink.java user/src/com/google/gwt/user/client/ui/impl/HyperlinkImpl.java user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplIE.java user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplOpera.java user/src/com/google/gwt/user/client/ui/impl/HyperlinkImplSafari.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Widget resources
> Is there a plan to make Constants part of ImmutableResourceBundle?
Incubator r1252 includes a new resource type called GwtCreateResource.
interface GwtCreateResource extends ResourcePrototype {
T create();
}
interface Resources extends ImmutableResourceBundle {
// messages().create() invokes GWT.create(MyMessages.class);
GwtCreateResource messages();
// invokes GWT.create(Service.class), rpc().create() returns a ServiceAsync
// @ClassType can be overridden on subclasses
@ClassType(Service.class)
GwtCreateResource rpc();
}
This works for any type which can be passed into GWT.create(), which
includes all default-instantiable types as a very simple form of DI.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Code review: LazyPanelExample tweaks
Per your review feedback, lowered cuteness and explained setVisible(false) call. rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- less-silly-LazyPanelExample-1.6-r4222.patch Description: Binary data
[gwt-contrib] [google-web-toolkit commit] r4222 - in releases/1.6/user/src/com/google/gwt: junit/tools user/tools
Author: [EMAIL PROTECTED]
Date: Tue Dec 2 09:12:50 2008
New Revision: 4222
Modified:
releases/1.6/user/src/com/google/gwt/junit/tools/JUnit-hosted.launchsrc
releases/1.6/user/src/com/google/gwt/junit/tools/JUnit-web.launchsrc
releases/1.6/user/src/com/google/gwt/user/tools/App.launchsrc
releases/1.6/user/src/com/google/gwt/user/tools/ApplicationCreator.java
releases/1.6/user/src/com/google/gwt/user/tools/project.ant.xmlsrc
Log:
This patch fixes issue 1816 and a similar bug with applicationCreator on
Mac.
Patch by: amitmanjhi
Review by: jat (TBR)
Modified:
releases/1.6/user/src/com/google/gwt/junit/tools/JUnit-hosted.launchsrc
==
--- releases/1.6/user/src/com/google/gwt/junit/tools/JUnit-hosted.launchsrc
(original)
+++ releases/1.6/user/src/com/google/gwt/junit/tools/JUnit-hosted.launchsrc
Tue Dec 2 09:12:50 2008
@@ -13,6 +13,6 @@
@eclipseExtraLaunchPaths
-
+
Modified:
releases/1.6/user/src/com/google/gwt/junit/tools/JUnit-web.launchsrc
==
--- releases/1.6/user/src/com/google/gwt/junit/tools/JUnit-web.launchsrc
(original)
+++ releases/1.6/user/src/com/google/gwt/junit/tools/JUnit-web.launchsrc
Tue Dec 2 09:12:50 2008
@@ -13,6 +13,6 @@
@eclipseExtraLaunchPaths
-
+
Modified: releases/1.6/user/src/com/google/gwt/user/tools/App.launchsrc
==
--- releases/1.6/user/src/com/google/gwt/user/tools/App.launchsrc
(original)
+++ releases/1.6/user/src/com/google/gwt/user/tools/App.launchsrc Tue Dec
2 09:12:50 2008
@@ -9,7 +9,7 @@
@eclipseExtraLaunchPaths
-
+
Modified:
releases/1.6/user/src/com/google/gwt/user/tools/ApplicationCreator.java
==
--- releases/1.6/user/src/com/google/gwt/user/tools/ApplicationCreator.java
(original)
+++ releases/1.6/user/src/com/google/gwt/user/tools/ApplicationCreator.java
Tue Dec 2 09:12:50 2008
@@ -309,6 +309,7 @@
replacements.put("@startupUrl", startupUrl);
replacements.put("@vmargs", isMacOsX
? "" : "");
+replacements.put("@eclipseVmargs",
isMacOsX ? "-XstartOnFirstThread" : "");
replacements.put("@eclipseExtraLaunchPaths",
CreatorUtilities.createEclipseExtraLaunchPaths(extraClassPaths));
replacements.put("@extraModuleInherits",
Modified: releases/1.6/user/src/com/google/gwt/user/tools/project.ant.xmlsrc
==
--- releases/1.6/user/src/com/google/gwt/user/tools/project.ant.xmlsrc
(original)
+++ releases/1.6/user/src/com/google/gwt/user/tools/project.ant.xmlsrc Tue
Dec 2 09:12:50 2008
@@ -50,6 +50,7 @@
+
@vmargs
@@ -63,13 +64,13 @@
-
+
@vmargs
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: incubator code review
Is that going to turn into a revolving door of new packages as each generation of widgets requires it's own namespace? It seems to me that the gen2 package idea was a mistake of convenience and maybe should have been a branch (or branches) that got merged back into trunk once it stabilized. On Tue, Dec 2, 2008 at 11:57 AM, John LaBanca <[EMAIL PROTECTED]> wrote: > Is this a good idea? I think we should just deprecate the widgetideas > version now in favor of the gen2 version. I didn't attempt to copy > ScrollTable changes back to the widgetideas version, it would be a > nightmare. IMHO, development on widgetideas code should be closed once a > gen2 replacement is available. > > Thanks, > John LaBanca > [EMAIL PROTECTED] > > > On Tue, Dec 2, 2008 at 11:48 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: >> >> Code review request: >> http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1250 >> >> Copying gen2-DropDownPanel over the widgetideas-DropDownPanel rather then >> patching the widgetideas version, as this way we only maintain one version >> of DropDownPanel, which is going to be depricated as soon as the first 1.6 >> milestone is released. >> >> >> -- >> "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: incubator code review
Is this a good idea? I think we should just deprecate the widgetideas version now in favor of the gen2 version. I didn't attempt to copy ScrollTable changes back to the widgetideas version, it would be a nightmare. IMHO, development on widgetideas code should be closed once a gen2 replacement is available. Thanks, John LaBanca [EMAIL PROTECTED] On Tue, Dec 2, 2008 at 11:48 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > Code review request: > http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1250 > > Copying gen2-DropDownPanel over the widgetideas-DropDownPanel rather then > patching the widgetideas version, as this way we only maintain one version > of DropDownPanel, which is going to be depricated as soon as the first 1.6 > milestone is released. > > > -- > "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] incubator code review
Code review request: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1250 Copying gen2-DropDownPanel over the widgetideas-DropDownPanel rather then patching the widgetideas version, as this way we only maintain one version of DropDownPanel, which is going to be depricated as soon as the first 1.6 milestone is released. -- "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?
Yep.
On Tue, Dec 2, 2008 at 11:23 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> Trying to recap, I believe the concrete proposals I just heard are:
> 1. TextBoxBase should accept setValue(null), and return "" from getValue();
> 2. It is reasonable for widgets that can't sensibly be cleared to throw
> IllegalArgumentException on setValue(null)
> 3. HasValue's javadoc should be tweaked accordingly
>
> Yes?
>
> rjrjr
>
> On Tue, Dec 2, 2008 at 6:12 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> This seems like the right philosophy to me, and your point about date
>> pickers having an optional range is a very persuasive one, so I'm sold on
>> the "best guess" with the widget being able to throw
>> IllegalArgumentException as well.
>>
>>
>> On Mon, Dec 1, 2008 at 11:09 PM, John LaBanca <[EMAIL PROTECTED]>wrote:
>>
>>> 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?
>
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
>
> 1. TextBoxBase should accept setValue(null), and return "" from getValue();
Correct, and in general getValue() and setValue() do not need to be equal.
> 2. It is reasonable for widgets that can't sensibly be cleared to throw
> IllegalArgumentException on setValue(null)
>
I don't think we need to call out null specifically in javadoc, but your
point is correct. It is reasonable for widgets to throw an
IllegalArgumentException if the value cannot be sensibly set, null or not.
GWT widgets (and all implementors) should probably strive to accept null as
a valid value because its a very common use case.
3. HasValue's javadoc should be tweaked accordingly
>
Yes, but if we didn't change the javadoc, that could be fun too.
Thanks,
John LaBanca
[EMAIL PROTECTED]
On Tue, Dec 2, 2008 at 11:23 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> Trying to recap, I believe the concrete proposals I just heard are:
> 1. TextBoxBase should accept setValue(null), and return "" from getValue();
> 2. It is reasonable for widgets that can't sensibly be cleared to throw
> IllegalArgumentException on setValue(null)
> 3. HasValue's javadoc should be tweaked accordingly
>
> Yes?
>
> rjrjr
>
> On Tue, Dec 2, 2008 at 6:12 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> This seems like the right philosophy to me, and your point about date
>> pickers having an optional range is a very persuasive one, so I'm sold on
>> the "best guess" with the widget being able to throw
>> IllegalArgumentException as well.
>>
>>
>> On Mon, Dec 1, 2008 at 11:09 PM, John LaBanca <[EMAIL PROTECTED]>wrote:
>>
>>> 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 excep
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
Trying to recap, I believe the concrete proposals I just heard are:
1. TextBoxBase should accept setValue(null), and return "" from getValue();
2. It is reasonable for widgets that can't sensibly be cleared to throw
IllegalArgumentException on setValue(null)
3. HasValue's javadoc should be tweaked accordingly
Yes?
rjrjr
On Tue, Dec 2, 2008 at 6:12 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> This seems like the right philosophy to me, and your point about date
> pickers having an optional range is a very persuasive one, so I'm sold on
> the "best guess" with the widget being able to throw
> IllegalArgumentException as well.
>
>
> On Mon, Dec 1, 2008 at 11:09 PM, John LaBanca <[EMAIL PROTECTED]> wrote:
>
>> 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:
>>> >
>>> > HasValue dateBox = new DateBox();
>>> > HasValue hasValue2 = new Text
[gwt-contrib] Re: TabPanel feature request
> > Thanks for the great comments! > I didn't see any comments... oh, sarcasm =) Since the TabPanel (really the DeckPanel) currently attaches widgets to the DOM immediately, we might have backward compatibility issues if we attach them lazily. We could make lazy attachment an optional setting though. An alternative that should work for your use case is to use the fact that DeckPanel calls setVisible(true) when a widget is shown (which the LazyPanel exploits to render lazily). You could create your widget in the constructor, but don't attach the inner components to the outermost component until setVisible(true) is called the first time. Then you'd have your widget DOM structure available for manipulation, but you don't pay the render time in the browser. Thanks, John LaBanca [EMAIL PROTECTED] On Tue, Dec 2, 2008 at 3:04 AM, stuckagain <[EMAIL PROTECTED]> wrote: > > Thanks for the great comments! > > It turns out that this bug is already reported (and 5 stars as well) > in the issue database. > jlaba is the owner of the bug and priority is medium > > Here is the bug report: > http://code.google.com/p/google-web-toolkit/issues/detail?id=1902 > > David > > On Nov 27, 8:51 am, stuckagain <[EMAIL PROTECTED]> wrote: > > People, > > > > I recently read about lazy loading panels > http://googlewebtoolkit.blogspot.com/2008/11/profiling-gwt-applicatio... > > > > I am actually asking for offering lazy attaching tabpanels as a > > default implementation. In most cases you only get a > > performance problem when you attach the Widgets to the DOM tree, > > creating the UI without attaching is done in milliseconds. > > > > In case of a TabPabel it can sometimes be very cumbersome to use lazy > > loading for the different tabs. Loading it lazily is easy, but > > gathering information from multiple tabs to post to the server must > > take into account that maybe the widgets are null... that makes the > > code much more complicated than it should be. > > > > By deferring attaching to the DOM tree until first shown, all this is > > not needed. Creating the widgets is most of the time very fast, it is > > only when they get attached that the Browser shokes. When I was > > experimenting with tables in IE6 for example, I could build up a table > > of 250 rows in memory in a few milliseconds, but as soon as I attached > > the table, I lost 8 seconds that the Browser was not responsive. > > > > So,... anybody cares about the subject ? Can I create a functional > > request in the issues database or do I have to shut up and move over > > to the other GWT group ? > > > > David > > > > On Nov 24, 11:46 am, stuckagain <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi, > > > > > I'm having a problem with theTabPanelbehaviour. > > > > > I've created a widget that uses absolute positioning internally to get > > > a certain effect. The DIV that surrounds it is sized correctly in the > > > onLoad method, based on the size of the absolutely positioned element. > > > > > All this works fine except in the case where this widget is used in > aTabPanel. > > > > > If the widget is not put in the visible tab at the moment of > > > attachement, then the size calucation fails because I always get 0 as > > > a response. The widget is attached but not visible ... that makes > > > sense. > > > > > I would like to suggest an alternative approach in thetabpanel, to > > > postpone calling onLoad until the tab is actually shown the first > > > time. > > > > > The obvious workaround for the moment is ofcourse to add the tab panel > > > lazily to make sure that the onLoad is only triggered when the tab is > > > made visible but this is a generaly reusable component and I do not > > > control the use of the component. > > > > > I avoided the problem by showing the widget with display:none on the > > > RootPanel, the same trick as used in the popup panel, because that was > > > easier to hide from the calling code... but the calculation can fail > > > due to different CSS rules being applied when attached to another > > > parent DOM element. > > > > > David- Hide quoted text - > > > > - Show quoted text - > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: gen2 tables: Create TableDefinition based on annotations
This is very cool!
Thanks,
John LaBanca
[EMAIL PROTECTED]
On Fri, Nov 28, 2008 at 2:54 PM, dflorey <[EMAIL PROTECTED]> wrote:
>
> Uuups, only working in hosted mode :-(
>
> On 27 Nov., 13:07, dflorey <[EMAIL PROTECTED]> wrote:
> > Hi,
> > I've used that Generator stuff in gwt for the first time and I've to
> > admit that it is really cool!
> > I've been using it to simplify the creation of model based gen2-
> > tables. Instead of defining the TableDefinition programmatically you
> > now have the alternative to do it with annotations in your domain
> > class.
> > Example:
> >
> > public static class Ancestor extends AbstractTreeTableItem implements
> > RowValue {
> > private String firstName, lastName;
> > private double iq;
> > private Date dateOfBirth;
> >
> >public Ancestor(String firstName, String lastName, int iq, Date
> > dateOfBirth) {
> > this.firstName = firstName;
> > this.lastName = lastName;
> > this.iq = iq;
> > this.dateOfBirth = dateOfBirth;
> > }
> >
> > @ColumnDefinition(column = 0, header = "First name", filterable =
> > false)
> > public String getFirstName() {
> > return firstName;
> > }
> >
> > @ColumnDefinition(column = 1, header = "Last name")
> > public String getLastName() {
> > return lastName;
> > }
> >
> > @ColumnDefinition(column = 2, header = "IQ", numberFormat =
> > NumberColumnFormat.SCIENTIFIC_FORMAT)
> > public double getIq() {
> > return iq;
> > }
> >
> > @ColumnDefinition(column = 3, header = "Date of birth",
> > dateTimeFormat = DateColumnFormat.SHORT_DATE_FORMAT)
> > public Date getDateOfBirth() {
> > return dateOfBirth;
> > }
> >
> > @Override
> > public String getDisplayName() {
> > return firstName + " " + lastName;
> > }
> >
> > @Override
> > public String getId() {
> > return firstName + lastName + dateOfBirth;
> > }
> >
> > }
> >
> > Note that you have to implement the RowValue marker interface. Now you
> > are ready to create your TableDefinition like this:
> >
> > TableDefinition tableDefinition = GWT.create
> > (Ancestor.class);
> >
> > Very cool! Thanks for this brilliant toolkit!!
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: How absolute should the setValue's contract be?
This seems like the right philosophy to me, and your point about date
pickers having an optional range is a very persuasive one, so I'm sold on
the "best guess" with the widget being able to throw
IllegalArgumentException as well.
On Mon, Dec 1, 2008 at 11:09 PM, John LaBanca <[EMAIL PROTECTED]> wrote:
> 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:
>> >
>> > HasValue dateBox = new DateBox();
>> > HasValue 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 va
[gwt-contrib] Client did not send nnn bytes as expected - sorry for crossposting
Hi, Does anyone has any new insights about this issue? We've been investigating for over a year(!), and we seem to not be the only ones... http://tinyurl.com/5rqfp5 Thanks. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: TabPanel feature request
Thanks for the great comments! It turns out that this bug is already reported (and 5 stars as well) in the issue database. jlaba is the owner of the bug and priority is medium Here is the bug report: http://code.google.com/p/google-web-toolkit/issues/detail?id=1902 David On Nov 27, 8:51 am, stuckagain <[EMAIL PROTECTED]> wrote: > People, > > I recently read about lazy loading > panelshttp://googlewebtoolkit.blogspot.com/2008/11/profiling-gwt-applicatio... > > I am actually asking for offering lazy attaching tabpanels as a > default implementation. In most cases you only get a > performance problem when you attach the Widgets to the DOM tree, > creating the UI without attaching is done in milliseconds. > > In case of a TabPabel it can sometimes be very cumbersome to use lazy > loading for the different tabs. Loading it lazily is easy, but > gathering information from multiple tabs to post to the server must > take into account that maybe the widgets are null... that makes the > code much more complicated than it should be. > > By deferring attaching to the DOM tree until first shown, all this is > not needed. Creating the widgets is most of the time very fast, it is > only when they get attached that the Browser shokes. When I was > experimenting with tables in IE6 for example, I could build up a table > of 250 rows in memory in a few milliseconds, but as soon as I attached > the table, I lost 8 seconds that the Browser was not responsive. > > So,... anybody cares about the subject ? Can I create a functional > request in the issues database or do I have to shut up and move over > to the other GWT group ? > > David > > On Nov 24, 11:46 am, stuckagain <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > I'm having a problem with theTabPanelbehaviour. > > > I've created a widget that uses absolute positioning internally to get > > a certain effect. The DIV that surrounds it is sized correctly in the > > onLoad method, based on the size of the absolutely positioned element. > > > All this works fine except in the case where this widget is used in > > aTabPanel. > > > If the widget is not put in the visible tab at the moment of > > attachement, then the size calucation fails because I always get 0 as > > a response. The widget is attached but not visible ... that makes > > sense. > > > I would like to suggest an alternative approach in thetabpanel, to > > postpone calling onLoad until the tab is actually shown the first > > time. > > > The obvious workaround for the moment is ofcourse to add the tab panel > > lazily to make sure that the onLoad is only triggered when the tab is > > made visible but this is a generaly reusable component and I do not > > control the use of the component. > > > I avoided the problem by showing the widget with display:none on the > > RootPanel, the same trick as used in the popup panel, because that was > > easier to hide from the calling code... but the calculation can fail > > due to different CSS rules being applied when attached to another > > parent DOM element. > > > David- Hide quoted text - > > - Show quoted text - --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
