[gwt-contrib] [google-web-toolkit commit] r3726 - changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log
Author: [EMAIL PROTECTED]
Date: Tue Oct 7 15:35:36 2008
New Revision: 3726
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingLoggerPanel.java
Log:
Don't display stubbed-out filtering controls.
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingLoggerPanel.java
==
---
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingLoggerPanel.java
(original)
+++
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingLoggerPanel.java
Tue Oct 7 15:35:36 2008
@@ -266,39 +266,44 @@
}
});
topPanel.add(collapsButton);
-topPanel.add(new JLabel("Filter Log Messages: "));
-levelComboBox = new JComboBox();
-for (TreeLogger.Type type : TreeLogger.Type.instances()) {
- if (type.compareTo(maxLevel) > 0) {
-break;
+if (true) {
+ // temporarily avoid showing parts that aren't implemented.
+ topPanel.add(new JLabel("Log filtering controls will go here"));
+} else {
+ topPanel.add(new JLabel("Filter Log Messages: "));
+ levelComboBox = new JComboBox();
+ for (TreeLogger.Type type : TreeLogger.Type.instances()) {
+if (type.compareTo(maxLevel) > 0) {
+ break;
+}
+levelComboBox.addItem(type);
}
- levelComboBox.addItem(type);
+ levelComboBox.setEditable(false);
+ levelComboBox.setSelectedIndex(levelComboBox.getItemCount() - 1);
+ topPanel.add(levelComboBox);
+ levelComboBox.addActionListener(new ActionListener() {
+public void actionPerformed(ActionEvent e) {
+ setLevelFilter((TreeLogger.Type)
levelComboBox.getSelectedItem());
+}
+ });
+ regexField = new JTextField(20);
+ topPanel.add(regexField);
+ JButton applyRegexButton = new JButton("Apply Regex");
+ applyRegexButton.addActionListener(new ActionListener() {
+public void actionPerformed(ActionEvent e) {
+ setRegexFilter(regexField.getText());
+}
+ });
+ topPanel.add(applyRegexButton);
+ JButton clearRegexButton = new JButton("Clear Regex");
+ clearRegexButton.addActionListener(new ActionListener() {
+public void actionPerformed(ActionEvent e) {
+ regexField.setText("");
+ setRegexFilter("");
+}
+ });
+ topPanel.add(clearRegexButton);
}
-levelComboBox.setEditable(false);
-levelComboBox.setSelectedIndex(levelComboBox.getItemCount() - 1);
-topPanel.add(levelComboBox);
-levelComboBox.addActionListener(new ActionListener() {
- public void actionPerformed(ActionEvent e) {
-setLevelFilter((TreeLogger.Type) levelComboBox.getSelectedItem());
- }
-});
-regexField = new JTextField(20);
-topPanel.add(regexField);
-JButton applyRegexButton = new JButton("Apply Regex");
-applyRegexButton.addActionListener(new ActionListener() {
- public void actionPerformed(ActionEvent e) {
-setRegexFilter(regexField.getText());
- }
-});
-topPanel.add(applyRegexButton);
-JButton clearRegexButton = new JButton("Clear Regex");
-clearRegexButton.addActionListener(new ActionListener() {
- public void actionPerformed(ActionEvent e) {
-regexField.setText("");
-setRegexFilter("");
- }
-});
-topPanel.add(clearRegexButton);
add(topPanel, BorderLayout.NORTH);
root = new DefaultMutableTreeNode();
treeModel = new DefaultTreeModel(root);
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: data binding framework for GWT
Hi Arthur, On Tue, Oct 7, 2008 at 1:51 PM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote: >> I don't mean to nitpick, but it's actually the editor that puts back >> the previous value, not the converter. The converter just throws a >> ConversionException if the String couldn't be converted. It's up to >> the editor to decide what to do with the ConversionException. > > Ah, sorry, I misunderstood how it was working. Thanks for clearing > that up. This also deals with the original use case I proposed above > (not updating the model right away). I only thought of that case > because it kept trying to convert and reverting the field to it's > previous value, which prevented validation from running its course. > I'll just create my own editor and leave the field the way it was. I read your comment on issue 343 (http://code.google.com/p/google-web-toolkit/issues/detail?id=343#c31). I haven't finished reading the Bean Validation JSR yet, and I haven't looked at Chris Ruffalo's code, but I have dipped my toe into using Hibernate validation in my own server-side code. I *think* validation could be tied into the data binding framework in a pretty straightforward way by extending Editor and Viewer to be validation-aware. At the moment, Viewer and Editor just provide simple interfaces to view (and edit) a value of type T. If there was some way to talk about the validity of a given value, Viewer (and, by extension, Editor) could be extended to provide feedback to the user when the value it's displaying changes from invalid to valid or valid to invalid. I assume that Hibernate validation-style validation requires some kind of "validation service" that is external to the beans being validated. (As opposed to the beans themselves somehow performing validation and reporting the results.) If that's the case, a BoundField could listen to its editor for EditorChangeEvents and filter the new value through validation before/after/around updating the related bean. If you perform validation at that time, you have access to the editor that changed, the bean that's (in)valid, the property that's (in)valid, and the validation state. You could probably give very rich feedback to the user about that particular property, and there are a number of rational ways to handle an invalid value. Handling multi-property validation is a little more complex but, assuming the validation "service" can provide enough feedback, the bound field may be able to co-ordinate with its containing BoundForm to manage the related fields, or it could just punt and disallow the field change that prompted the switch from valid to invalid, depending on what works in context. As for validation "events" that happen "behind the scenes", perhaps bound fields could somehow observe the validation service using their knowledge of bean type and property name. I think data binding and validation probably need to be aware of each other (or, at least, data binding needs to be aware of validation), but I think they're separate concerns. To me, data binding is just a way of automating the display and update of a bean's properties via some widgets. Validation, on the other hand, is a way of making sure that a property is within some bounds, or some combination of properties together follow some rules. Data binding impacts validation because the user could transform a bean into or out of a valid state, and validation impacts data binding because you usually need to give the user feedback about the validity of the bean being edited, but I think the relationship between data binding and validation is probably best mediated through a thin interface that keeps things loosely coupled. What do you think? (Or anyone else, for that matter.) > Ian, I think this data binding framework is really excellent. It's > really well thought out and I think it'll be a major contribution to > GWT. I hope it makes it into the incubator soon. Thanks for your hard > work. Thank you for the compliments and for taking the time to look into the code and come up with questions and concerns--I'm sure you'll find more as you dig deeper. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Code Review: gwt-google-apis gears fix typo in method name.
Hi Miguel,
This patch addresses issue 183, a typo in a method name:
http://code.google.com/p/gwt-google-apis/issues/detail?id=183
I renamed the method in the library class and updated the test.
M test/com/google/gwt/gears/client/localserver/LocalServerTest.java
M
src/com/google/gwt/gears/client/localserver/ResourceStoreUrlCaptureHandler.java
--
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: src/com/google/gwt/gears/client/localserver/ResourceStoreUrlCaptureHandler.java
===
--- src/com/google/gwt/gears/client/localserver/ResourceStoreUrlCaptureHandler.java (revision 869)
+++ src/com/google/gwt/gears/client/localserver/ResourceStoreUrlCaptureHandler.java (working copy)
@@ -52,7 +52,7 @@
*
* @return true if the capture succeeded
*/
-public native boolean isSucceess() /*-{
+public native boolean isSuccess() /*-{
return this.success;
}-*/;
}
Index: test/com/google/gwt/gears/client/localserver/LocalServerTest.java
===
--- test/com/google/gwt/gears/client/localserver/LocalServerTest.java (revision 869)
+++ test/com/google/gwt/gears/client/localserver/LocalServerTest.java (working copy)
@@ -82,7 +82,7 @@
assertFalse(ls.canServeLocally(requestedURL));
rs.capture(new ResourceStoreUrlCaptureHandler() {
public void onCapture(ResourceStoreUrlCaptureEvent event) {
-assertTrue(event.isSucceess());
+assertTrue(event.isSuccess());
assertEquals(requestedURL, event.getUrl());
try {
assertTrue(ls.canServeLocally(requestedURL));
[gwt-contrib] Re: [google-web-toolkit commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl
Will review. On Tue, Oct 7, 2008 at 12:22 PM, Lex Spoon <[EMAIL PROTECTED]> wrote: > Okay, here is a patch that gives the bootstrap entry method an > enclosing class. It went together simply; I simply updated all > references to JProgram.entryMethods. The one non-trivial part was > GenerateJavaScriptAST, which used to pick up entry methods by looking > at the first (or last?) thing that a JProgram visits. Now the entry > methods get seen at difficult to predict times during the traversal of > the JProgram, so GenerateJavaScriptAST has an array to record them as > they come by. It turns out this is the only method I could find that > does not have an enclosing class, so the patch includes an assert. > > I ended up not adding a single entry class, because it would cause > awkwardness for the runAsync entry methods. Each runAsync call > generates a class with multiple methods, and one of those methods is > an entry method. To have a single entry class, that method would have > to be moved over to the entry class, and so the standard generator > framework wouldn't work out of the box. So, I left it be for now. > > Can you review it, Scott, or pass it to someone? > > > -Lex > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: data binding framework for GWT
> When I designed the library, I thought of bound widgets as views on > fields in a bean. If the bean changes, the widget is updated and if > the widget changes, the bean is updated. If you created a "detached" > editor that didn't automatically update the bean, what would you want > to happen if the bean were to change behind the scenes? Right now, if > the bean SourcesPropertyChangeEvents, the editors and viewers are > updated onPropertyChange. Would you want a detached editor to ignore > property change events from the associated bean? When you put it that way, I see that the use case I mentioned isn't really useful. You make some good points and I think that your approach is what we'll end up using. Keeping with the MVC pattern by keeping the model and view in sync is a better idea (and can let people collaborate on a single model). Thanks for clearing that up for me. > I'd be surprised if a > real application had a single field with 100+ dependent viewers, > though. I was thinking more along the lines of 100+ fields bound to various objects, but it probably won't be a problem. I could run some GWT benchmarks to see if there is any issue. > I don't mean to nitpick, but it's actually the editor that puts back > the previous value, not the converter. The converter just throws a > ConversionException if the String couldn't be converted. It's up to > the editor to decide what to do with the ConversionException. Ah, sorry, I misunderstood how it was working. Thanks for clearing that up. This also deals with the original use case I proposed above (not updating the model right away). I only thought of that case because it kept trying to convert and reverting the field to it's previous value, which prevented validation from running its course. I'll just create my own editor and leave the field the way it was. Ian, I think this data binding framework is really excellent. It's really well thought out and I think it'll be a major contribution to GWT. I hope it makes it into the incubator soon. Thanks for your hard work. Regards, Arthur Kalmenson On Oct 7, 11:29 am, "Ian Petersen" <[EMAIL PROTECTED]> wrote: > On Tue, Oct 7, 2008 at 10:56 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote: > > Yes, I'm looking to avoid updating the bean automatically. I want to > > specify when the bean should be updated. > > I see. I hadn't thought of that use case. As it stands, no, you > can't do that. BoundFieldImpl has a nested class Listener that > implements EditorChangeListener. BoundFieldImpl's getEditor() adds > an instance of Listener as a change listener to the editor before > returning it. That listener takes care of updating the bean when the > editor changes and, as it stands, you can't not add the listener. > > When I designed the library, I thought of bound widgets as views on > fields in a bean. If the bean changes, the widget is updated and if > the widget changes, the bean is updated. If you created a "detached" > editor that didn't automatically update the bean, what would you want > to happen if the bean were to change behind the scenes? Right now, if > the bean SourcesPropertyChangeEvents, the editors and viewers are > updated onPropertyChange. Would you want a detached editor to ignore > property change events from the associated bean? > > > It'll also be interesting to see what the performance implications are > > of having the bean updated on any change. Does it work fine for forms > > of 100+ fields? > > I haven't explicitly tested it with that many fields, but I'd expected > it to be okay--only the property bound to a given widget will be > updated when that widget changes. In the example I posted, the Person > class has firstName and lastName properties. When you edit a given > person, the firstName and lastName properties are bound to text boxes. > If you edit the first name, only the firstName property is updated > and likewise for the last name. Where there could be performance > considerations is if you have "lots" of viewers and/or calculated > fields all depending on the same property and then you edit that > property. I don't know what would happen then--the UI would probably > freeze until the updates were all complete. I'd be surprised if a > real application had a single field with 100+ dependent viewers, > though. > > > Hmm, that's a good point. However, the way the current Converters work > > is that they remove the value that is entered by the user if it > > doesn't convert properly. As you mentioned, this probably has to do > > with the way exceptions are handled (putting back the previous value, > > which happened to be empty). > > I don't mean to nitpick, but it's actually the editor that puts back > the previous value, not the converter. The converter just throws a > ConversionException if the String couldn't be converted. It's up to > the editor to decide what to do with the ConversionException. The > existing implementation of HasTextEditor aims to be > "c
[gwt-contrib] Re: A rose by any other name (what to call addHandlersAndSink)
On Tue, Oct 7, 2008 at 12:53 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>>
>>
> It would typically be the case that you would want to sink, however
> this is not always true, so we want users to have the option of whether to
> sink or not.
>
addDomHandlerAndSink()?
>>>
> If we are depending upon javadoc, what about just calling it
> addDomHandler(DomHandler handler) with javadoc directing people to use
> addHandler if they don't want to sink the events?
>
I like it.
>
>
>
>
>
>>
>1. fo/INFO --> addHandler(ClickEvent.INFO, handler)
>
> +1 for type. It's a shame you can't just use the class literal
>>> ClickEvent.type or ClickEvent.TYPE?
>>>
>>
>> If it's a constant, it should be upper.
>>
>
> So +1 for TYPE . I could see arguments for ClickEvent.type as it is the
> moral equivalent if ClickEvent.class, which is why I asked.
>
>
>
>
>
>>>
>>>
>
>>
>> On Mon, Oct 6, 2008 at 5:36 PM, Emily Crutcher <[EMAIL PROTECTED]>wrote:
>>
>>> Here is the current doc on it, to give context:
>>>
>>> /**
>>>* Adds a native event handler to the widget and sinks the
>>> corresponding
>>>* native event.
>>>*
>>>* @param the type of handler to add
>>>* @param key the event key
>>>* @param handler the handler
>>>* @return [EMAIL PROTECTED] HandlerRegistration} used to remove the
>>> handler
>>>*/
>>> protected HandlerRegistration
>>> addHandlerAndSink(
>>> DomEvent.Key key, final HandlerType handler) {
>>> sinkEvents(key.getNativeEventType());
>>> return addHandler(key, handler);
>>>
>>> }
>>>
>>> On Mon, Oct 6, 2008 at 5:35 PM, Emily Crutcher <[EMAIL PROTECTED]>wrote:
>>>
The purpose of the new method "addHandlersAndSink" is to allow users
to add a DOM handler and sink the necessary event in one easy step.
The reason we, the GWT team, care about this is because
traditionally, with the two call separated everyone, including us,
will tend
to sink the events in the constructor rather then when a handler is
actually
added. This can degrade performance significantly for small widgets,
so we'd
like to encourage our developers to do the fast/efficient thing
instead.
addHandlersAndSink has the advantage that when you autocomplete to
find your widget methods, it appears directly under addHandlers.
However,
it sounds somewhat awkward, so a better name might be in order, hence
this
post...
--
"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"
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> "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"
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> "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: A rose by any other name (what to call addHandlersAndSink)
>
>
It would typically be the case that you would want to sink, however this
is not always true, so we want users to have the option of whether to sink
or not.
>>>
>>> addDomHandlerAndSink()?
>>>
>>
If we are depending upon javadoc, what about just calling it
addDomHandler(DomHandler handler) with javadoc directing people to use
addHandler if they don't want to sink the events?
>
1. fo/INFO --> addHandler(ClickEvent.INFO, handler)
+1 for type. It's a shame you can't just use the class literal
>>>
>> ClickEvent.type or ClickEvent.TYPE?
>>
>
> If it's a constant, it should be upper.
>
So +1 for TYPE . I could see arguments for ClickEvent.type as it is the
moral equivalent if ClickEvent.class, which is why I asked.
>>
>>
>>>
>
> On Mon, Oct 6, 2008 at 5:36 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> Here is the current doc on it, to give context:
>>
>> /**
>>* Adds a native event handler to the widget and sinks the
>> corresponding
>>* native event.
>>*
>>* @param the type of handler to add
>>* @param key the event key
>>* @param handler the handler
>>* @return [EMAIL PROTECTED] HandlerRegistration} used to remove the
>> handler
>>*/
>> protected HandlerRegistration
>> addHandlerAndSink(
>> DomEvent.Key key, final HandlerType handler) {
>> sinkEvents(key.getNativeEventType());
>> return addHandler(key, handler);
>>
>> }
>>
>> On Mon, Oct 6, 2008 at 5:35 PM, Emily Crutcher <[EMAIL PROTECTED]>wrote:
>>
>>> The purpose of the new method "addHandlersAndSink" is to allow users
>>> to add a DOM handler and sink the necessary event in one easy step.
>>>
>>> The reason we, the GWT team, care about this is because
>>> traditionally, with the two call separated everyone, including us, will
>>> tend
>>> to sink the events in the constructor rather then when a handler is
>>> actually
>>> added. This can degrade performance significantly for small widgets, so
>>> we'd
>>> like to encourage our developers to do the fast/efficient thing instead.
>>>
>>> addHandlersAndSink has the advantage that when you autocomplete to
>>> find your widget methods, it appears directly under addHandlers.
>>> However,
>>> it sounds somewhat awkward, so a better name might be in order, hence
>>> this
>>> post...
>>>
>>>
>>>
>>>
>>>
>>> --
>>> "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"
>>
>>
>>
>
>
>
--
"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"
>>
>>
>>
>
> >
>
--
"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] r3725 - in trunk: reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum user/src/c...
Author: [EMAIL PROTECTED]
Date: Tue Oct 7 09:17:27 2008
New Revision: 3725
Added:
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue2855.java
(contents, props changed)
Modified:
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/DefaultMuseum.java
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue1169.java
trunk/user/src/com/google/gwt/user/client/ui/PopupPanel.java
trunk/user/test/com/google/gwt/user/client/ui/PopupTest.java
Log:
Added getters/setters to PopupPanel for autoHide and modal variables.
Patch by: jlabanca
Review by: rjrjr
Issue: 2855
Modified:
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/DefaultMuseum.java
==
---
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/DefaultMuseum.java
(original)
+++
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/DefaultMuseum.java
Tue Oct 7 09:17:27 2008
@@ -41,8 +41,8 @@
addIssue(new Issue2392());
addIssue(new Issue2443());
addIssue(new Issue2553());
+addIssue(new Issue2855());
addIssue(new TreeVisuals());
addIssue(new TestFireEvents());
-
}
}
Modified:
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue1169.java
==
---
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue1169.java
(original)
+++
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue1169.java
Tue Oct 7 09:17:27 2008
@@ -18,13 +18,12 @@
import com.google.gwt.museum.client.common.AbstractIssue;
import com.google.gwt.user.client.Command;
import com.google.gwt.user.client.ui.MenuBar;
-import com.google.gwt.user.client.ui.PopupPanel;
import com.google.gwt.user.client.ui.Widget;
/**
- * The [EMAIL PROTECTED] PopupPanel} used to display sub menus in a [EMAIL
PROTECTED] MenuBar}
is not
- * accessible, nor is it under the [EMAIL PROTECTED] MenuBar MenuBar's} DOM
structure, so
- * it cannot be uniquely styled.
+ * The [EMAIL PROTECTED] com.google.gwt.user.client.ui.PopupPanel} used to
display sub
+ * menus in a [EMAIL PROTECTED] MenuBar} is not accessible, nor is it under the
+ * [EMAIL PROTECTED] MenuBar MenuBar's} DOM structure, so it cannot be
uniquely
styled.
*/
public class Issue1169 extends AbstractIssue {
/**
Added:
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue2855.java
==
--- (empty file)
+++
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue2855.java
Tue Oct 7 09:17:27 2008
@@ -0,0 +1,114 @@
+/*
+ * 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.museum.client.defaultmuseum;
+
+import com.google.gwt.museum.client.common.AbstractIssue;
+import com.google.gwt.user.client.Window;
+import com.google.gwt.user.client.ui.Button;
+import com.google.gwt.user.client.ui.ClickListener;
+import com.google.gwt.user.client.ui.PopupPanel;
+import com.google.gwt.user.client.ui.VerticalPanel;
+import com.google.gwt.user.client.ui.Widget;
+
+/**
+ * PopupPanel.setAutoHideEnabled() and setModel()
+ *
+ *
+ * Verify that all states of the [EMAIL PROTECTED] PopupPanel} (combinations
of modal
and
+ * autoHide) work and can be change seemlessly.
+ *
+ */
+public class Issue2855 extends AbstractIssue {
+
+ @Override
+ public Widget createIssue() {
+// Create the popup panel
+final PopupPanel popup = new PopupPanel();
+
+// Add buttons to call getters and setters
+Button toggleAutoHide = new Button("4. Toggle AutoHide",
+new ClickListener() {
+ public void onClick(Widget sender) {
+popup.setAutoHideEnabled(!popup.isAutoHideEnabled());
+ }
+});
+Button toggleModal = new Button("3. Toggle Modal", new ClickListener()
{
+ public void onClick(Widget sender) {
+popup.setModal(!popup.isModal());
+ }
+});
+Button isAutoHide = new Button("isAutoHide?", new ClickListener() {
+ public void onClick(Widget sender) {
+Window.alert("AutoHide: " + popup.isAutoHi
[gwt-contrib] Re: [google-web-toolkit commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl
Okay, here is a patch that gives the bootstrap entry method an enclosing class. It went together simply; I simply updated all references to JProgram.entryMethods. The one non-trivial part was GenerateJavaScriptAST, which used to pick up entry methods by looking at the first (or last?) thing that a JProgram visits. Now the entry methods get seen at difficult to predict times during the traversal of the JProgram, so GenerateJavaScriptAST has an array to record them as they come by. It turns out this is the only method I could find that does not have an enclosing class, so the patch includes an assert. I ended up not adding a single entry class, because it would cause awkwardness for the runAsync entry methods. Each runAsync call generates a class with multiple methods, and one of those methods is an entry method. To have a single entry class, that method would have to be moved over to the entry class, and so the standard generator framework wouldn't work out of the box. So, I left it be for now. Can you review it, Scott, or pass it to someone? -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- allMethodsHaveClass-r3723.patch Description: Binary data
[gwt-contrib] Re: RR: make PopupPanels stay on the screen, even in RTL situations
Thanks for keeping us honest, Ray! Alex and I will add a test for this behavior to DialogBoxTest and reply back on this thread with the code review. On Tue, Oct 7, 2008 at 11:26 AM, Ray Ryan <[EMAIL PROTECTED]> wrote: > Shouldn't there be a change to PopupTest to go along with this? > > On 10/7/08, Alex Rudnick <[EMAIL PROTECTED]> wrote: > > > > Hey Rajeev :) > > > > Thanks for the quick review! > > > > Responses inline. > > > > On Mon, Oct 6, 2008 at 7:08 PM, Rajeev Dayal <[EMAIL PROTECTED]> wrote: > >> DialogBox.java > >> 199: Spelling: sceen --> screen > > OK > > > >> 243: @Overrides on an a method that implements an interface only works > in > >> Java 1.6. While GWT on the the trunk currently support JDK 1.6, the code > >> base still compiles under GWT 1.5. If this change goes in, then GWT will > >> no > >> longer be able to compile under JDK 1.5. Let's get rid of the > annotation. > > OK > > > >> 245: Do you need to recompute clientLeft and clientTop on window resize? > >> Can > >> these change based on a window resize? > > > > I don't think they can change on resize. For example, in RTL mode for > > IE, clientLeft is the width of a scrollbar. > > > >> General: > >> I did some testing and it looks good. Dragging in IE6 in RTL mode is > still > >> somewhat odd with the jumpiness, but workable. I wonder if we could > >> improve > >> RTL dragging in general in IE6/IE7. It might be worth filing a bug for. > If > >> I > >> had to suspect something, it might be the use of CSS expressions and a > >> hidden IFRAME to prevent scrollbar shine-through. This isn't needed in > >> IE7, > >> as they've fixed this at the rendering level, so it might be worth > >> exploring > >> at least an improvement for IE7 at some point. > >> After addressing the above nits, feel free to hit the commit switch. > > > > Committed r3724, put in issue 2957. > > > > -- > > Alex Rudnick > > swe, gwt, atl > > > > > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A rose by any other name (what to call addHandlersAndSink)
On Tue, Oct 7, 2008 at 11:36 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, Oct 7, 2008 at 11:30 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
>
>>
>>
>> On Tue, Oct 7, 2008 at 10:51 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>>
>>>
Would it be typical to addHandler() for a DOM event and *not* want to
sink? If so, then it makes more sense for the names to be uniform, perhaps
even left as is.
>>>
>>> It would typically be the case that you would want to sink, however this
>>> is not always true, so we want users to have the option of whether to sink
>>> or not.
>>>
>>
>> addDomHandlerAndSink()?
>>
>
> I'm worried people might not realize that they can add dom handlers using
> addHandler as well.
>
I'd think JavaDoc can take care of that. This name makes it clear that this
is the preferred way to deal with Dom handlers (and that it's irrelevant to
other kinds), and the doc can provide the fine print.
>
>
>
>>
>>>
>>>
While we're talking about names, the term "key" as in "event key" sounds
confusingly like "key" as in "my keyboard has keys". Perhaps there's
another
term?
>>>
>>> Here are some random suggestions to see if they spark others:
>>>
>>>1. Type/TYPE --> addHandler(ClickEvent.TYPE, handler)
>>>2. Meta/meta --> addHandler(ClickEvent.meta, handler)
>>>3. Info/INFO --> addHandler(ClickEvent.INFO, handler)
>>>
>>> +1 for type. It's a shame you can't just use the class literal
>>
> ClickEvent.type or ClickEvent.TYPE?
>
If it's a constant, it should be upper.
>
>
>
>>
>>>
On Mon, Oct 6, 2008 at 5:36 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> Here is the current doc on it, to give context:
>
> /**
>* Adds a native event handler to the widget and sinks the
> corresponding
>* native event.
>*
>* @param the type of handler to add
>* @param key the event key
>* @param handler the handler
>* @return [EMAIL PROTECTED] HandlerRegistration} used to remove the
> handler
>*/
> protected HandlerRegistration
> addHandlerAndSink(
> DomEvent.Key key, final HandlerType handler) {
> sinkEvents(key.getNativeEventType());
> return addHandler(key, handler);
>
> }
>
> On Mon, Oct 6, 2008 at 5:35 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> The purpose of the new method "addHandlersAndSink" is to allow users
>> to add a DOM handler and sink the necessary event in one easy step.
>>
>> The reason we, the GWT team, care about this is because traditionally,
>> with the two call separated everyone, including us, will tend to sink the
>> events in the constructor rather then when a handler is actually added.
>> This
>> can degrade performance significantly for small widgets, so we'd like to
>> encourage our developers to do the fast/efficient thing instead.
>>
>> addHandlersAndSink has the advantage that when you autocomplete to
>> find your widget methods, it appears directly under addHandlers.
>> However,
>> it sounds somewhat awkward, so a better name might be in order, hence
>> this
>> post...
>>
>>
>>
>>
>>
>> --
>> "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"
>
>
>
>>>
>>>
>>> --
>>> "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: A rose by any other name (what to call addHandlersAndSink)
On Tue, Oct 7, 2008 at 11:30 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, Oct 7, 2008 at 10:51 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>>
>>>
>>> Would it be typical to addHandler() for a DOM event and *not* want to
>>> sink? If so, then it makes more sense for the names to be uniform, perhaps
>>> even left as is.
>>>
>>
>> It would typically be the case that you would want to sink, however this
>> is not always true, so we want users to have the option of whether to sink
>> or not.
>>
>
> addDomHandlerAndSink()?
>
I'm worried people might not realize that they can add dom handlers using
addHandler as well.
>
>>
>>
>>>
>>> While we're talking about names, the term "key" as in "event key" sounds
>>> confusingly like "key" as in "my keyboard has keys". Perhaps there's another
>>> term?
>>>
>>
>> Here are some random suggestions to see if they spark others:
>>
>>1. Type/TYPE --> addHandler(ClickEvent.TYPE, handler)
>>2. Meta/meta --> addHandler(ClickEvent.meta, handler)
>>3. Info/INFO --> addHandler(ClickEvent.INFO, handler)
>>
>> +1 for type. It's a shame you can't just use the class literal
>
ClickEvent.type or ClickEvent.TYPE?
>
>>
>>>
>>> On Mon, Oct 6, 2008 at 5:36 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>>>
Here is the current doc on it, to give context:
/**
* Adds a native event handler to the widget and sinks the
corresponding
* native event.
*
* @param the type of handler to add
* @param key the event key
* @param handler the handler
* @return [EMAIL PROTECTED] HandlerRegistration} used to remove the
handler
*/
protected HandlerRegistration
addHandlerAndSink(
DomEvent.Key key, final HandlerType handler) {
sinkEvents(key.getNativeEventType());
return addHandler(key, handler);
}
On Mon, Oct 6, 2008 at 5:35 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> The purpose of the new method "addHandlersAndSink" is to allow users to
> add a DOM handler and sink the necessary event in one easy step.
>
> The reason we, the GWT team, care about this is because traditionally,
> with the two call separated everyone, including us, will tend to sink the
> events in the constructor rather then when a handler is actually added.
> This
> can degrade performance significantly for small widgets, so we'd like to
> encourage our developers to do the fast/efficient thing instead.
>
> addHandlersAndSink has the advantage that when you autocomplete to find
> your widget methods, it appears directly under addHandlers. However, it
> sounds somewhat awkward, so a better name might be in order, hence this
> post...
>
>
>
>
>
> --
> "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"
>>>
>>>
>>>
>>
>>
>> --
>> "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: A rose by any other name (what to call addHandlersAndSink)
On Tue, Oct 7, 2008 at 10:51 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>>
>> Would it be typical to addHandler() for a DOM event and *not* want to
>> sink? If so, then it makes more sense for the names to be uniform, perhaps
>> even left as is.
>>
>
> It would typically be the case that you would want to sink, however this is
> not always true, so we want users to have the option of whether to sink or
> not.
>
addDomHandlerAndSink()?
>
>
>
>>
>> While we're talking about names, the term "key" as in "event key" sounds
>> confusingly like "key" as in "my keyboard has keys". Perhaps there's another
>> term?
>>
>
> Here are some random suggestions to see if they spark others:
>
>1. Type/TYPE --> addHandler(ClickEvent.TYPE, handler)
>2. Meta/meta --> addHandler(ClickEvent.meta, handler)
>3. Info/INFO --> addHandler(ClickEvent.INFO, handler)
>
> +1 for type. It's a shame you can't just use the class literal
>
>
>>
>> On Mon, Oct 6, 2008 at 5:36 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>>
>>> Here is the current doc on it, to give context:
>>>
>>> /**
>>>* Adds a native event handler to the widget and sinks the
>>> corresponding
>>>* native event.
>>>*
>>>* @param the type of handler to add
>>>* @param key the event key
>>>* @param handler the handler
>>>* @return [EMAIL PROTECTED] HandlerRegistration} used to remove the
>>> handler
>>>*/
>>> protected HandlerRegistration
>>> addHandlerAndSink(
>>> DomEvent.Key key, final HandlerType handler) {
>>> sinkEvents(key.getNativeEventType());
>>> return addHandler(key, handler);
>>>
>>> }
>>>
>>> On Mon, Oct 6, 2008 at 5:35 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>>>
The purpose of the new method "addHandlersAndSink" is to allow users to
add a DOM handler and sink the necessary event in one easy step.
The reason we, the GWT team, care about this is because traditionally,
with the two call separated everyone, including us, will tend to sink the
events in the constructor rather then when a handler is actually added.
This
can degrade performance significantly for small widgets, so we'd like to
encourage our developers to do the fast/efficient thing instead.
addHandlersAndSink has the advantage that when you autocomplete to find
your widget methods, it appears directly under addHandlers. However, it
sounds somewhat awkward, so a better name might be in order, hence this
post...
--
"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"
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> "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: data binding framework for GWT
On Tue, Oct 7, 2008 at 10:56 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote: > Yes, I'm looking to avoid updating the bean automatically. I want to > specify when the bean should be updated. I see. I hadn't thought of that use case. As it stands, no, you can't do that. BoundFieldImpl has a nested class Listener that implements EditorChangeListener. BoundFieldImpl's getEditor() adds an instance of Listener as a change listener to the editor before returning it. That listener takes care of updating the bean when the editor changes and, as it stands, you can't not add the listener. When I designed the library, I thought of bound widgets as views on fields in a bean. If the bean changes, the widget is updated and if the widget changes, the bean is updated. If you created a "detached" editor that didn't automatically update the bean, what would you want to happen if the bean were to change behind the scenes? Right now, if the bean SourcesPropertyChangeEvents, the editors and viewers are updated onPropertyChange. Would you want a detached editor to ignore property change events from the associated bean? > It'll also be interesting to see what the performance implications are > of having the bean updated on any change. Does it work fine for forms > of 100+ fields? I haven't explicitly tested it with that many fields, but I'd expected it to be okay--only the property bound to a given widget will be updated when that widget changes. In the example I posted, the Person class has firstName and lastName properties. When you edit a given person, the firstName and lastName properties are bound to text boxes. If you edit the first name, only the firstName property is updated and likewise for the last name. Where there could be performance considerations is if you have "lots" of viewers and/or calculated fields all depending on the same property and then you edit that property. I don't know what would happen then--the UI would probably freeze until the updates were all complete. I'd be surprised if a real application had a single field with 100+ dependent viewers, though. > Hmm, that's a good point. However, the way the current Converters work > is that they remove the value that is entered by the user if it > doesn't convert properly. As you mentioned, this probably has to do > with the way exceptions are handled (putting back the previous value, > which happened to be empty). I don't mean to nitpick, but it's actually the editor that puts back the previous value, not the converter. The converter just throws a ConversionException if the String couldn't be converted. It's up to the editor to decide what to do with the ConversionException. The existing implementation of HasTextEditor aims to be "convertable" at all times, so a conversion exception in widgetChanged() leads to redisplaying the previous value. You could do something else, like leave the invalid input but mark the field somehow. It's up to the application how it chooses to implement the Editor interface. > I think that the validation that you have in mind is bean based > validation, which is being discussed already (http://code.google.com/p/ > google-web-toolkit/issues/detail?id=343). This is different from the > widget based validation which is currently in the incubator. Things > are all over the place right now, and I think we need some direction > from the GWT team. I have a lunch appointment earlier than I expected, so I haven't had a chance to look into validators or the link you just provided, but I'll look into them this afternoon. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: make PopupPanels stay on the screen, even in RTL situations
Shouldn't there be a change to PopupTest to go along with this? On 10/7/08, Alex Rudnick <[EMAIL PROTECTED]> wrote: > > Hey Rajeev :) > > Thanks for the quick review! > > Responses inline. > > On Mon, Oct 6, 2008 at 7:08 PM, Rajeev Dayal <[EMAIL PROTECTED]> wrote: >> DialogBox.java >> 199: Spelling: sceen --> screen > OK > >> 243: @Overrides on an a method that implements an interface only works in >> Java 1.6. While GWT on the the trunk currently support JDK 1.6, the code >> base still compiles under GWT 1.5. If this change goes in, then GWT will >> no >> longer be able to compile under JDK 1.5. Let's get rid of the annotation. > OK > >> 245: Do you need to recompute clientLeft and clientTop on window resize? >> Can >> these change based on a window resize? > > I don't think they can change on resize. For example, in RTL mode for > IE, clientLeft is the width of a scrollbar. > >> General: >> I did some testing and it looks good. Dragging in IE6 in RTL mode is still >> somewhat odd with the jumpiness, but workable. I wonder if we could >> improve >> RTL dragging in general in IE6/IE7. It might be worth filing a bug for. If >> I >> had to suspect something, it might be the use of CSS expressions and a >> hidden IFRAME to prevent scrollbar shine-through. This isn't needed in >> IE7, >> as they've fixed this at the rendering level, so it might be worth >> exploring >> at least an improvement for IE7 at some point. >> After addressing the above nits, feel free to hit the commit switch. > > Committed r3724, put in issue 2957. > > -- > Alex Rudnick > swe, gwt, atl > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: make PopupPanels stay on the screen, even in RTL situations
Hey Rajeev :) Thanks for the quick review! Responses inline. On Mon, Oct 6, 2008 at 7:08 PM, Rajeev Dayal <[EMAIL PROTECTED]> wrote: > DialogBox.java > 199: Spelling: sceen --> screen OK > 243: @Overrides on an a method that implements an interface only works in > Java 1.6. While GWT on the the trunk currently support JDK 1.6, the code > base still compiles under GWT 1.5. If this change goes in, then GWT will no > longer be able to compile under JDK 1.5. Let's get rid of the annotation. OK > 245: Do you need to recompute clientLeft and clientTop on window resize? Can > these change based on a window resize? I don't think they can change on resize. For example, in RTL mode for IE, clientLeft is the width of a scrollbar. > General: > I did some testing and it looks good. Dragging in IE6 in RTL mode is still > somewhat odd with the jumpiness, but workable. I wonder if we could improve > RTL dragging in general in IE6/IE7. It might be worth filing a bug for. If I > had to suspect something, it might be the use of CSS expressions and a > hidden IFRAME to prevent scrollbar shine-through. This isn't needed in IE7, > as they've fixed this at the rendering level, so it might be worth exploring > at least an improvement for IE7 at some point. > After addressing the above nits, feel free to hit the commit switch. Committed r3724, put in issue 2957. -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review Request - PopupPanel modal and autoHide accessors
It might be good for the javadoc on the setter methods to mention that they
have no immediate effect if called while the dialog is showing. In fact,
should we encourage people to hide the dialog before using the new setters?
It looks like we have no test coverage for the panel's behavior in its four
states? (modal x autohide.) You could factor out the guts of testPopup and
run it four times, once in each combination.
For that matter, we don't test auto-hide or modality at all, beyond your new
check that the bits get set. Is that possible?
rjrjr
On Tue, Oct 7, 2008 at 9:52 AM, John LaBanca <[EMAIL PROTECTED]> wrote:
> Ray -
>
> Please do a code review on this patch that adds getters and setters for
> modal and autoHide properties to PopupPanel.
>
> Description:
> =
> It would be nice to have getters and setters for moal and autoHide
> properties in PopupPanel.
>
> Fix:
> ===
> Added them.
>
> Testing:
> ==
> Manually verified that changing the properties while the popup is visible
> does not cause any state problems. The booleans are checked on
> onEventPreview() at the time of an event, and no special setup/teardown is
> done as a result of them being set. I also added a unit test for the
> setters and getters.
>
> Thanks,
> John LaBanca
> [EMAIL PROTECTED]
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: user/test/com/google/gwt/user/client/ui/PopupTest.java
===
--- user/test/com/google/gwt/user/client/ui/PopupTest.java (revision 3723)
+++ user/test/com/google/gwt/user/client/ui/PopupTest.java (working copy)
@@ -50,6 +50,18 @@
assertFalse(popup.isAnimationEnabled());
popup.setAnimationEnabled(true);
assertTrue(popup.isAnimationEnabled());
+
+// Modal
+popup.setModal(true);
+assertTrue(popup.isModal());
+popup.setModal(false);
+assertFalse(popup.isModal());
+
+// AutoHide enabled
+popup.setAutoHideEnabled(true);
+assertTrue(popup.isAutoHideEnabled());
+popup.setAutoHideEnabled(false);
+assertFalse(popup.isAutoHideEnabled());
}
/**
Index: user/src/com/google/gwt/user/client/ui/PopupPanel.java
===
--- user/src/com/google/gwt/user/client/ui/PopupPanel.java (revision 3723)
+++ user/src/com/google/gwt/user/client/ui/PopupPanel.java (working copy)
@@ -435,6 +435,26 @@
return isAnimationEnabled;
}
+ /**
+ * Returns true if the popup should be automatically hidden when
+ * the user clicks outside of it.
+ *
+ * @return true if autoHide is enabled, false if disabled
+ */
+ public boolean isAutoHideEnabled() {
+return autoHide;
+ }
+
+ /**
+ * Returns true if keyboard or mouse events that do not target
+ * the PopupPanel or its children should be ignored.
+ *
+ * @return true if popup is modal, false if not
+ */
+ public boolean isModal() {
+return modal;
+ }
+
public boolean onEventPreview(Event event) {
Element target = DOM.eventGetTarget(event);
@@ -542,6 +562,16 @@
}
/**
+ * Enable or disable the autoHide feature. When enabled, the popup will be
+ * automatically hidden when the user clicks outside of it.
+ *
+ * @param autoHide true to enable autoHide, false to disable
+ */
+ public void setAutoHideEnabled(boolean autoHide) {
+this.autoHide = autoHide;
+ }
+
+ /**
* Sets the height of the panel's child widget. If the panel's child widget
* has not been set, the height passed in will be cached and used to set the
* height immediately after the child widget is set.
@@ -566,6 +596,16 @@
}
/**
+ * When the popup is modal, keyboard or mouse events that do not target the
+ * PopupPanel or its children will be ignored.
+ *
+ * @param modal true to make the popup modal
+ */
+ public void setModal(boolean modal) {
+this.modal = modal;
+ }
+
+ /**
* Sets the popup's position relative to the browser's client area. The
* popup's position may be set before calling [EMAIL PROTECTED] #show()}.
*
[gwt-contrib] Re: data binding framework for GWT
> I'm not sure what you mean. Are you looking to avoid updating the
> bean until sometime after the editor has changed?
Yes, I'm looking to avoid updating the bean automatically. I want to
specify when the bean should be updated.
It'll also be interesting to see what the performance implications are
of having the bean updated on any change. Does it work fine for forms
of 100+ fields?
> I understand the converters as a way to map between a textual widget
> and some non-String data type T. To me, a validator has as a first
> assumption that the value it's validating is at least of the right
> type. For example, validation on a birth date might require that the
> birth date be before System.currentTimeMillis(), but the validator
> would assume that it's validating a Date and not a String. In this
> case, the converters are necessary as a first pass before the
> validators.
>
> I haven't looked at the validators, though, so I'll have a look when I
> get to the office and think it over some more.
Hmm, that's a good point. However, the way the current Converters work
is that they remove the value that is entered by the user if it
doesn't convert properly. As you mentioned, this probably has to do
with the way exceptions are handled (putting back the previous value,
which happened to be empty).
I think that the validation that you have in mind is bean based
validation, which is being discussed already (http://code.google.com/p/
google-web-toolkit/issues/detail?id=343). This is different from the
widget based validation which is currently in the incubator. Things
are all over the place right now, and I think we need some direction
from the GWT team.
> Thanks! And thanks for looking at it, too. Besides documentation
> (and tests, I guess) another big thing that needs to be handled is
> i18n. Right now, the best way to get nice labels for bound fields is
> with the @Label annotation. That should probably go away and,
> instead, the FormGenerator should spit out a Form implementation that
> gets its labels from a properties file via a Constants subtype. I'm
> not sure the best way to do that, though, because I haven't used GWT's
> i18n facilities much.
We'll try to take a closer look and see if we can help out. We need to
get started on some of our projects, but this data binding framework
would be very helpful since we build/will build a lot of form based
applications. Thanks for sharing your code!
On Oct 7, 10:20 am, "Ian Petersen" <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 7, 2008 at 9:28 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
> > - Is it possible to run the binding on demand instead of automatically
> > with the attached listeners? Say I want to only run the binding after
> > the user pressed the submit button, is that possible?
>
> I'm not sure what you mean. Are you looking to avoid updating the
> bean until sometime after the editor has changed?
>
> > - the converters are useful for general data mapping, but they also
> > seem to be performing the role of validator. Is it possible to use the
> > validation framework from the incubator or the one proposed here:
> >http://code.google.com/p/google-web-toolkit/issues/detail?id=343#c30.
> > Or, should the converters continue to perform the role of converting
> > the data to match the binded data type? The converters wouldn't be a
> > problem if the binding could be delayed and allow validation to run
> > it's course.
>
> I understand the converters as a way to map between a textual widget
> and some non-String data type T. To me, a validator has as a first
> assumption that the value it's validating is at least of the right
> type. For example, validation on a birth date might require that the
> birth date be before System.currentTimeMillis(), but the validator
> would assume that it's validating a Date and not a String. In this
> case, the converters are necessary as a first pass before the
> validators.
>
> I haven't looked at the validators, though, so I'll have a look when I
> get to the office and think it over some more.
>
> > - when executing Integer.parseInt() in the converters on non Integers,
> > an exception should be thrown, but it seems to be getting caught
> > somewhere. Where is that happening?
>
> I'm guessing without looking at the source code, but I think you're
> talking about HasTextEditor.widgetChanged(). There's some code
> that looks roughly like this (the code might be different, and there
> aren't as many comments):
>
> private void widgetChanged() {
> try {
> // calls converter.fromString(widget.getText());
> this.value = doReadValue();
>
> if (this.listeners != null && !this.listeners.isEmpty()) {
> // fire an EditorChangeEvent to notify listeners...
> }
> }
> catch (ConversionException e) {
> // I think this is the exception you're expecting and I'm swallowing
> }
>
> // reformat and display the current value,
> // which won't have changed if the user's
> // input coul
[gwt-contrib] [google-web-toolkit commit] r3724 - trunk/user/src/com/google/gwt/user/client/ui
Author: [EMAIL PROTECTED]
Date: Tue Oct 7 07:54:14 2008
New Revision: 3724
Modified:
trunk/user/src/com/google/gwt/user/client/ui/DialogBox.java
trunk/user/src/com/google/gwt/user/client/ui/PopupPanel.java
Log:
Let users drag DialogBoxes off the screen in any direction, but only as
long as
the mouse pointer stays in the window -- so you can't totally lose a
DialogBox.
patch by: ajr
review by: rdayal
suggested by: jgw
Modified: trunk/user/src/com/google/gwt/user/client/ui/DialogBox.java
==
--- trunk/user/src/com/google/gwt/user/client/ui/DialogBox.java (original)
+++ trunk/user/src/com/google/gwt/user/client/ui/DialogBox.java Tue Oct 7
07:54:14 2008
@@ -15,9 +15,12 @@
*/
package com.google.gwt.user.client.ui;
+import com.google.gwt.dom.client.Document;
import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.Event;
+import com.google.gwt.user.client.Window;
+import com.google.gwt.user.client.WindowResizeListener;
/**
* A form of popup that has a caption area at the top and can be dragged
by the
@@ -69,6 +72,10 @@
private boolean dragging;
private int dragStartX, dragStartY;
private MouseListenerCollection mouseListeners = new
MouseListenerCollection();
+ private WindowResizeListener resizeListener;
+ private int windowWidth;
+ private int clientLeft;
+ private int clientTop;
/**
* Creates an empty dialog box. It should not be shown until its child
widget
@@ -114,6 +121,10 @@
// Set the style name
setStyleName(DEFAULT_STYLENAME);
sinkEvents(Event.MOUSEEVENTS);
+
+windowWidth = Window.getClientWidth();
+clientLeft = Document.get().getBodyOffsetLeft();
+clientTop = Document.get().getBodyOffsetTop();
}
public String getHTML() {
@@ -125,6 +136,12 @@
}
@Override
+ public void hide() {
+Window.removeWindowResizeListener(resizeListener);
+super.hide();
+ }
+
+ @Override
public void onBrowserEvent(Event event) {
super.onBrowserEvent(event);
@@ -178,6 +195,14 @@
if (dragging) {
int absX = x + getAbsoluteLeft();
int absY = y + getAbsoluteTop();
+
+ // if the mouse is off the screen to the left, right, or top, don't
+ // move the dialog box. This would let users lose dialog boxes, which
+ // would be bad for modal popups.
+ if (absX < clientLeft || absX >= windowWidth || absY < clientTop) {
+return;
+ }
+
setPopupPosition(absX - dragStartX, absY - dragStartY);
}
}
@@ -209,6 +234,19 @@
*/
public void setText(String text) {
caption.setText(text);
+ }
+
+ @Override
+ public void show() {
+if (resizeListener == null) {
+ resizeListener = new WindowResizeListener() {
+public void onWindowResized(int width, int height) {
+ windowWidth = width;
+}
+ };
+}
+Window.addWindowResizeListener(resizeListener);
+super.show();
}
@Override
Modified: trunk/user/src/com/google/gwt/user/client/ui/PopupPanel.java
==
--- trunk/user/src/com/google/gwt/user/client/ui/PopupPanel.java
(original)
+++ trunk/user/src/com/google/gwt/user/client/ui/PopupPanel.javaTue Oct
7
07:54:14 2008
@@ -573,17 +573,6 @@
* @param top the top position, in pixels
*/
public void setPopupPosition(int left, int top) {
-// Keep the popup within the browser's client area, so that they can't
get
-// 'lost' and become impossible to interact with. Note that we don't
attempt
-// to keep popups pegged to the bottom and right edges, as they will
then
-// cause scrollbars to appear, so the user can't lose them.
-if (left < 0) {
- left = 0;
-}
-if (top < 0) {
- top = 0;
-}
-
// Save the position of the popup
leftPosition = left;
topPosition = top;
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: A rose by any other name (what to call addHandlersAndSink)
>
> Would it be typical to addHandler() for a DOM event and *not* want to sink?
> If so, then it makes more sense for the names to be uniform, perhaps even
> left as is.
>
It would typically be the case that you would want to sink, however this is
not always true, so we want users to have the option of whether to sink or
not.
>
> While we're talking about names, the term "key" as in "event key" sounds
> confusingly like "key" as in "my keyboard has keys". Perhaps there's another
> term?
>
Here are some random suggestions to see if they spark others:
1. Type/TYPE --> addHandler(ClickEvent.TYPE, handler)
2. Meta/meta --> addHandler(ClickEvent.meta, handler)
3. Info/INFO --> addHandler(ClickEvent.INFO, handler)
>
> On Mon, Oct 6, 2008 at 5:36 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> Here is the current doc on it, to give context:
>>
>> /**
>>* Adds a native event handler to the widget and sinks the corresponding
>>* native event.
>>*
>>* @param the type of handler to add
>>* @param key the event key
>>* @param handler the handler
>>* @return [EMAIL PROTECTED] HandlerRegistration} used to remove the
>> handler
>>*/
>> protected HandlerRegistration
>> addHandlerAndSink(
>> DomEvent.Key key, final HandlerType handler) {
>> sinkEvents(key.getNativeEventType());
>> return addHandler(key, handler);
>>
>> }
>>
>> On Mon, Oct 6, 2008 at 5:35 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>>
>>> The purpose of the new method "addHandlersAndSink" is to allow users to
>>> add a DOM handler and sink the necessary event in one easy step.
>>>
>>> The reason we, the GWT team, care about this is because traditionally,
>>> with the two call separated everyone, including us, will tend to sink the
>>> events in the constructor rather then when a handler is actually added. This
>>> can degrade performance significantly for small widgets, so we'd like to
>>> encourage our developers to do the fast/efficient thing instead.
>>>
>>> addHandlersAndSink has the advantage that when you autocomplete to find
>>> your widget methods, it appears directly under addHandlers. However, it
>>> sounds somewhat awkward, so a better name might be in order, hence this
>>> post...
>>>
>>>
>>>
>>>
>>>
>>> --
>>> "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"
>>
>>
>>
>
> >
>
--
"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: Code Review: correct Overlay.createPeer()
LGTM On Mon, Oct 6, 2008 at 10:16 AM, Eric Ayers <[EMAIL PROTECTED]> wrote: > (Forgot to CC: Miguel) > > On Fri, Sep 26, 2008 at 5:42 PM, Eric Ayers <[EMAIL PROTECTED]> wrote: > >> Hello Miguel, >> >> I would like for you to review the attached patch. >> >> I used the wrong constructor in a native method when implemening >> Overlay.createPeer(). I corrected the mistake and finished off the set of >> unit tests for Overlay.createPeer(). >> >> M maps/test/com/google/gwt/maps/client/overlay/OverlayTest.java >> A maps/test/com/google/gwt/maps/public/geoxml-test.html >> M maps/src/com/google/gwt/maps/client/overlay/Overlay.java >> -- >> Eric Z. Ayers - GWT Team - Atlanta, GA USA >> http://code.google.com/webtoolkit/ >> > > > > -- > Eric Z. Ayers - GWT Team - Atlanta, GA USA > http://code.google.com/webtoolkit/ > -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: remove 'final' modifier from MarkerOptions class
LGTM On Fri, Sep 26, 2008 at 4:33 PM, Eric Ayers <[EMAIL PROTECTED]> wrote: > Hello Miguel, > > Could you please review the attached patch? I've already committed it as > r857. This was brought to my attention from a gwt-maps developer that > attended Google Developer Day in Madrid (Alberto Núñez) > > M maps/src/com/google/gwt/maps/client/overlay/MarkerOptions.java > > -- > Eric Z. Ayers - GWT Team - Atlanta, GA USA > http://code.google.com/webtoolkit/ > -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A rose by any other name (what to call addHandlersAndSink)
If there are really two different kinds of things (that is, (1) logical
handlers and (2) dom handlers), why not change the names to reflect that?
Would it be typical to addHandler() for a DOM event and *not* want to sink?
If so, then it makes more sense for the names to be uniform, perhaps even
left as is.
While we're talking about names, the term "key" as in "event key" sounds
confusingly like "key" as in "my keyboard has keys". Perhaps there's another
term?
On Mon, Oct 6, 2008 at 5:36 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> Here is the current doc on it, to give context:
>
> /**
>* Adds a native event handler to the widget and sinks the corresponding
>* native event.
>*
>* @param the type of handler to add
>* @param key the event key
>* @param handler the handler
>* @return [EMAIL PROTECTED] HandlerRegistration} used to remove the handler
>*/
> protected HandlerRegistration
> addHandlerAndSink(
> DomEvent.Key key, final HandlerType handler) {
> sinkEvents(key.getNativeEventType());
> return addHandler(key, handler);
>
> }
>
> On Mon, Oct 6, 2008 at 5:35 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> The purpose of the new method "addHandlersAndSink" is to allow users to
>> add a DOM handler and sink the necessary event in one easy step.
>>
>> The reason we, the GWT team, care about this is because traditionally,
>> with the two call separated everyone, including us, will tend to sink the
>> events in the constructor rather then when a handler is actually added. This
>> can degrade performance significantly for small widgets, so we'd like to
>> encourage our developers to do the fast/efficient thing instead.
>>
>> addHandlersAndSink has the advantage that when you autocomplete to find
>> your widget methods, it appears directly under addHandlers. However, it
>> sounds somewhat awkward, so a better name might be in order, hence this
>> post...
>>
>>
>>
>>
>>
>> --
>> "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: data binding framework for GWT
On Tue, Oct 7, 2008 at 9:28 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
> - Is it possible to run the binding on demand instead of automatically
> with the attached listeners? Say I want to only run the binding after
> the user pressed the submit button, is that possible?
I'm not sure what you mean. Are you looking to avoid updating the
bean until sometime after the editor has changed?
> - the converters are useful for general data mapping, but they also
> seem to be performing the role of validator. Is it possible to use the
> validation framework from the incubator or the one proposed here:
> http://code.google.com/p/google-web-toolkit/issues/detail?id=343#c30.
> Or, should the converters continue to perform the role of converting
> the data to match the binded data type? The converters wouldn't be a
> problem if the binding could be delayed and allow validation to run
> it's course.
I understand the converters as a way to map between a textual widget
and some non-String data type T. To me, a validator has as a first
assumption that the value it's validating is at least of the right
type. For example, validation on a birth date might require that the
birth date be before System.currentTimeMillis(), but the validator
would assume that it's validating a Date and not a String. In this
case, the converters are necessary as a first pass before the
validators.
I haven't looked at the validators, though, so I'll have a look when I
get to the office and think it over some more.
> - when executing Integer.parseInt() in the converters on non Integers,
> an exception should be thrown, but it seems to be getting caught
> somewhere. Where is that happening?
I'm guessing without looking at the source code, but I think you're
talking about HasTextEditor.widgetChanged(). There's some code
that looks roughly like this (the code might be different, and there
aren't as many comments):
private void widgetChanged() {
try {
// calls converter.fromString(widget.getText());
this.value = doReadValue();
if (this.listeners != null && !this.listeners.isEmpty()) {
// fire an EditorChangeEvent to notify listeners...
}
}
catch (ConversionException e) {
// I think this is the exception you're expecting and I'm swallowing
}
// reformat and display the current value,
// which won't have changed if the user's
// input couldn't be parsed by the converter
doDisplayValue();
}
HasTextEditor wraps a widget of type and it attaches a ChangeListener to that widget
that, in onChange(Widget sender), invokes the appropriate
widgetChanged() method. The widgetChanged() method takes care of
parsing the user's input into a value of type T. If the user's input
can't be parsed, the converter will throw a ConversionException, but
the HasTextEditor swallows that exception and just redisplays
its previous value. This behaviour forces the widget to always be
displaying a value of type T formatted according to the subclass's
instructions.
> This framework looks very promising and well thought out. A less
> verbose binding mechanism would be nice, but I'm not entirely sure how
> it would be done. Thanks for the great work, I hope that this makes it
> into the incubator soon.
Thanks! And thanks for looking at it, too. Besides documentation
(and tests, I guess) another big thing that needs to be handled is
i18n. Right now, the best way to get nice labels for bound fields is
with the @Label annotation. That should probably go away and,
instead, the FormGenerator should spit out a Form implementation that
gets its labels from a properties file via a Constants subtype. I'm
not sure the best way to do that, though, because I haven't used GWT's
i18n facilities much.
Ian
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: data binding framework for GWT
Hello Ian, I had a coworker take a look at the data binding framework. It looks really good so far, but we had a couple of questions: - Is it possible to run the binding on demand instead of automatically with the attached listeners? Say I want to only run the binding after the user pressed the submit button, is that possible? - the converters are useful for general data mapping, but they also seem to be performing the role of validator. Is it possible to use the validation framework from the incubator or the one proposed here: http://code.google.com/p/google-web-toolkit/issues/detail?id=343#c30. Or, should the converters continue to perform the role of converting the data to match the binded data type? The converters wouldn't be a problem if the binding could be delayed and allow validation to run it's course. - when executing Integer.parseInt() in the converters on non Integers, an exception should be thrown, but it seems to be getting caught somewhere. Where is that happening? This framework looks very promising and well thought out. A less verbose binding mechanism would be nice, but I'm not entirely sure how it would be done. Thanks for the great work, I hope that this makes it into the incubator soon. Regards, Arthur Kalmenson On Oct 3, 11:09 pm, "Ian Petersen" <[EMAIL PROTECTED]> wrote: > Here's a sample project. The .tgz includes an updated > data_binding.jar because I found a few bugs while working on the > example. The new JAR also includes .class files as generated by Sun's > javac version 1.5.something. The .tgz includes Sandy McArthur's > PropertyChange stuff, so you _should_ be able to import the Eclipse > project and run it. Let me know if you have problems. > > Ian > > data_binding_example.tgz > 196KViewDownload --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Code Review: gwt-google-apis maps Status Code not translated - issue 189
Hello Miguel,
Here is another patch I'd like for you to review. It addresses issue 189 in
the issue tracker:
http://code.google.com/p/gwt-google-apis/issues/detail?id=189
The problem was very easy to solve, but I went ahead and added some more
unit testing and eliminated some warnings from a couple of other tests.
Note that I moved the StatusCodesTest.java file to the correct package in
the test source tree as well.
M maps/test/com/google/gwt/maps/MapsTestSuite.java
M maps/test/com/google/gwt/maps/client/impl/MinimumMapVersionTest.java
D maps/test/com/google/gwt/maps/client/StatusCodesTest.java
A maps/test/com/google/gwt/maps/client/geocode/StatusCodesTest.java
M maps/test/com/google/gwt/maps/client/MapWidgetEventsTest.java
M maps/test/com/google/gwt/maps/client/geom/BoundsTest.java
M maps/src/com/google/gwt/maps/client/geocode/StatusCodes.java
-Eric.
--
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
M maps/test/com/google/gwt/maps/MapsTestSuite.java
M maps/test/com/google/gwt/maps/client/impl/MinimumMapVersionTest.java
D maps/test/com/google/gwt/maps/client/StatusCodesTest.java
A maps/test/com/google/gwt/maps/client/geocode/StatusCodesTest.java
M maps/test/com/google/gwt/maps/client/MapWidgetEventsTest.java
M maps/test/com/google/gwt/maps/client/geom/BoundsTest.java
M maps/src/com/google/gwt/maps/client/geocode/StatusCodes.java
Index: maps/test/com/google/gwt/maps/MapsTestSuite.java
===
--- maps/test/com/google/gwt/maps/MapsTestSuite.java (revision 865)
+++ maps/test/com/google/gwt/maps/MapsTestSuite.java (working copy)
@@ -21,7 +21,7 @@
import com.google.gwt.maps.client.MapWidgetEventsTest;
import com.google.gwt.maps.client.MapWidgetTest;
import com.google.gwt.maps.client.MapsNotInstalledTest;
-import com.google.gwt.maps.client.StatusCodesTest;
+import com.google.gwt.maps.client.geocode.StatusCodesTest;
import com.google.gwt.maps.client.control.ControlTest;
import com.google.gwt.maps.client.geocode.DirectionsTest;
import com.google.gwt.maps.client.geocode.GeocodeTest;
@@ -54,6 +54,7 @@
suite.addTestSuite(MapWidgetTest.class);
suite.addTestSuite(ControlTest.class);
suite.addTestSuite(GeocodeTest.class);
+suite.addTestSuite(StatusCodesTest.class);
suite.addTestSuite(DirectionsTest.class);
suite.addTestSuite(InfoWindowEventsTest.class);
suite.addTestSuite(MarkerEventsTest.class);
@@ -66,7 +67,6 @@
suite.addTestSuite(PolygonTest.class);
suite.addTestSuite(PolylineTest.class);
suite.addTestSuite(CopyrightEventTest.class);
-suite.addTestSuite(StatusCodesTest.class);
suite.addTestSuite(LatLngTest.class);
suite.addTestSuite(LatLngBoundsTest.class);
suite.addTestSuite(ProjectionTest.class);
Index: maps/test/com/google/gwt/maps/client/impl/MinimumMapVersionTest.java
===
--- maps/test/com/google/gwt/maps/client/impl/MinimumMapVersionTest.java (revision 865)
+++ maps/test/com/google/gwt/maps/client/impl/MinimumMapVersionTest.java (working copy)
@@ -95,12 +95,14 @@
}
public void testConcreteOverlayImpl() {
+@SuppressWarnings("unused")
ConcreteOverlay concreteOverlay = new ConcreteOverlay(
nativeMakeConcreteOverlay());
}
public void testControl() {
ControlPosition pos = new ControlPosition(ControlAnchor.BOTTOM_LEFT, 0, 0);
+@SuppressWarnings("unused")
CustomControl c = new CustomControl(pos) {
@Override
@@ -135,10 +137,12 @@
return result;
}
}
+@SuppressWarnings("unused")
MyGeocodeCache customGc = new MyGeocodeCache();
}
public void testMapImpl() {
+@SuppressWarnings("unused")
MapWidget w = new MapWidget();
}
@@ -146,15 +150,18 @@
initTileLayer();
TileLayer[] layers = new TileLayer[1];
layers[0] = tileLayer;
+@SuppressWarnings("unused")
MapType t = new MapType(layers, new MercatorProjection(1),
"versionTestLayer");
}
public void testMercatorProjection() {
+@SuppressWarnings("unused")
MercatorProjection m = new MercatorProjection(2);
}
public void testOverlayImpl() {
+@SuppressWarnings("unused")
Overlay o = new Overlay() {
@Override
@@ -179,6 +186,7 @@
public void testProjection() {
initTileLayer();
+@SuppressWarnings("unused")
Projection projection = new Projection() {
@Override
@@ -206,6 +214,7 @@
public void testTileLayerOverlay() {
initTileLayer();
+@SuppressWarnings("unused")
TileLayerOverlay overlay = new TileLayerOverlay(tileLayer);
}
Index: maps/test/com/google/gwt/maps/client/StatusCodesTest.jav
