[gwt-contrib] Re: Code Review Request - Porting Tree fixes to GWT 1.5 branch
Did you run the tests in the museum project to make sure the patches worked as expected? If so, LGTM On Thu, Oct 9, 2008 at 11:28 AM, John LaBanca [EMAIL PROTECTED] wrote: Emily - Can you review the attached patch that has two Tree fixes for the 1.5 branch? Please verify that this patch captures both of the fixes in, which have already been committed to trunk: http://code.google.com/p/google-web-toolkit/issues/detail?id=2853 http://code.google.com/p/google-web-toolkit/issues/detail?id=2491 Thanks, John LaBanca [EMAIL PROTECTED] -- 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] r3729 - releases/1.5/user/src/com/google/gwt/user/client/ui
Author: [EMAIL PROTECTED]
Date: Thu Oct 9 08:44:15 2008
New Revision: 3729
Modified:
releases/1.5/user/src/com/google/gwt/user/client/ui/Tree.java
releases/1.5/user/src/com/google/gwt/user/client/ui/TreeItem.java
Log:
Fixes a couple of alignment bugs in the Tree. One occurs when you remove
all of the TreeItems in a parent, the other occurs because leaf TreeItems
do not line up with their non-leaf siblings.
Patch by: jlabanca
Review by: ecc
Issue: 2853, 2491
Modified: releases/1.5/user/src/com/google/gwt/user/client/ui/Tree.java
==
--- releases/1.5/user/src/com/google/gwt/user/client/ui/Tree.java
(original)
+++ releases/1.5/user/src/com/google/gwt/user/client/ui/Tree.java Thu Oct
9 08:44:15 2008
@@ -777,7 +777,7 @@
* @param treeItem the tree item
*/
void showLeafImage(TreeItem treeItem) {
-if (useLeafImages) {
+if (useLeafImages || treeItem.isFullNode()) {
showImage(treeItem, images.treeLeaf());
} else {
DOM.setStyleAttribute(treeItem.getElement(), paddingLeft,
indentValue);
Modified: releases/1.5/user/src/com/google/gwt/user/client/ui/TreeItem.java
==
--- releases/1.5/user/src/com/google/gwt/user/client/ui/TreeItem.java
(original)
+++ releases/1.5/user/src/com/google/gwt/user/client/ui/TreeItem.java Thu
Oct 9 08:44:15 2008
@@ -107,11 +107,6 @@
void initializeClonableElements() {
super.initializeClonableElements();
if (GWT.isClient()) {
-// Remove the padding from the cells and re-add it to the table
element
-DOM.setElementPropertyInt(BASE_INTERNAL_ELEM, cellPadding, 0);
-DOM.setElementPropertyInt(BASE_INTERNAL_ELEM, cellSpacing, 0);
-BASE_INTERNAL_ELEM.getStyle().setPropertyPx(paddingBottom, 3);
-
// We can't use a 3px padding all around because IE will wrap the
// childSpan to the next line, so we need to add a 3px margin on
the top
// and bottom instead. However, margins overlap, so we need a 6px
bottom
@@ -688,7 +683,7 @@
}
Element getImageHolderElement() {
-if (imageHolder == null) {
+if (!isFullNode()) {
convertToFullNode();
}
return imageHolder;
@@ -700,6 +695,10 @@
DOM.appendChild(getElement(), childSpanElem);
DOM.setStyleAttribute(childSpanElem, whiteSpace, nowrap);
children = new ArrayListTreeItem();
+ }
+
+ boolean isFullNode() {
+return imageHolder != null;
}
void setParentItem(TreeItem parent) {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r3730 - in changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev: . util/log
Author: [EMAIL PROTECTED]
Date: Thu Oct 9 11:45:15 2008
New Revision: 3730
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/ModulePanel.java
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingLoggerPanel.java
Log:
Changes from review.
Review by: bobv
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/ModulePanel.java
==
---
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/ModulePanel.java
(original)
+++
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/ModulePanel.java
Thu Oct 9 11:45:15 2008
@@ -84,7 +84,8 @@
this.tabs = tabs;
JPanel topPanel = new JPanel();
topPanel.add(new JLabel(moduleName));
-JButton compileButton = new JButton(Compile);
+JButton compileButton = new JButton(Compile (not yet implemented));
+compileButton.setEnabled(false);
compileButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
JOptionPane.showMessageDialog(null, Compiling not implemented
yet,
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
Thu Oct 9 11:45:15 2008
@@ -203,8 +203,6 @@
hasFocus);
DefaultMutableTreeNode node = (DefaultMutableTreeNode) value;
Object userObject = node.getUserObject();
- // TODO(jat): doesn't seem to work once disconnected
- setBackground(tree.getBackground());
if (userObject instanceof LogEvent) {
LogEvent event = (LogEvent) userObject;
event.setDisplayProperties(this);
@@ -383,8 +381,6 @@
}
public void disconnected() {
-// TODO(jat): better way to do this, as this doesn't change all the
-// background colors.
tree.setBackground(DISCONNECTED_COLOR);
tree.repaint();
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Flurry of Data binding threads
Sounds good to me, a solution that fits seamlessly with GWT would be very nice. Will you be posting a design document about it? Will this all tie into some form component for GWT? Will you include other useful features like visibility logic? Best regards, Arthur Kalmenson On Oct 8, 10:15 am, Ray Ryan [EMAIL PROTECTED] wrote: We all seem to be talking about data binding and validation a lot, and some of us are even implementing code about it. We on the GWT team hear the need and feel it ourselves. We have some notions of how we'd like to tackle this in a way that blends seamlessly with the rest of GWT, and are looking to start design and implementation in earnest before the year is out. This makes it unlikely that we'll accept core or incubator patches that implement such a system. That said, we don't want to shoot down the excellent work that's being done! If you have a system that's shaping up to meet your needs and that you want to share with the GWT community, please do! Set up a Google Code project, announce it here, embarrass us by shipping first and attracting a user base. We'll probably steal from you shamelessly and ask for your help as our own system takes shape. I hope this doesn't ruffle any feathers, and that you'll understand why we haven't been as responsive on some of these threads as we should have been. Thanks, rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Flurry of Data binding threads
There appears to be the following overlapping/complimentary items being worked on by various people: 1) compile time UI Template markup language proposal (status?) 2) JSR 303 Bean validation annotation stuff 3) HasData/HasValue consistent interface proposal for GWT widgets 4) Data Binding (various) to hook up bean properties with two-way synchronization to GWT widgets 5) Emily's new event handling system in incubator 6) MVC designs in GWT community to that, I would add, look at the XForms model spec. It seems to me that the elements of any solution be based on the following principles: 1) Emphasis on compile-time resolution of bindings as default/Leverages GWT compiler 2) Lightweight (shouldn't add too much to API) 3) Choice of use programmatically (from Java) or in UI templates. (i.e. don't make it require UI templates, but make UI templates work really well, with nice, terse idioms) 4) Extensible. If new types of per-field value metadata are added in future (units, XForms stuff, security principals, etc) it shouldn't mean a huge refactoring 5) Require minimal effort on the part of Widget authors (but perhaps not zero effort) That is, most of the work should be shouldered by people writing new kinds of binding expressions, validators, etc and Widgets should gracefully degrade or simply not respond to new types of per-field metadata that they don't understand. I think key is to remember that validation, calculation, visibility, etc can be generalized to arbitrary per-field metadata (ala XForms) and don't have to be hardcoded first-class, so many of the current proposals floating around can be in fact, combined under one umbrella. -Ray On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan [EMAIL PROTECTED] wrote: We all seem to be talking about data binding and validation a lot, and some of us are even implementing code about it. We on the GWT team hear the need and feel it ourselves. We have some notions of how we'd like to tackle this in a way that blends seamlessly with the rest of GWT, and are looking to start design and implementation in earnest before the year is out. This makes it unlikely that we'll accept core or incubator patches that implement such a system. That said, we don't want to shoot down the excellent work that's being done! If you have a system that's shaping up to meet your needs and that you want to share with the GWT community, please do! Set up a Google Code project, announce it here, embarrass us by shipping first and attracting a user base. We'll probably steal from you shamelessly and ask for your help as our own system takes shape. I hope this doesn't ruffle any feathers, and that you'll understand why we haven't been as responsive on some of these threads as we should have been. Thanks, rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Flurry of Data binding threads
To give you an idea of where I am coming from, here is my understanding of the world: *Metadata Systems, comprising Models and Controllers* xforms, Ian's databinding system, Arthur's validation system, gwt team's upcoming proposal for data management: All part of the larger metadata, binding, code generation class of systems. Hopefully all of these can eventually use the same basic concepts and it going to be a huge undertaking to get it right. In fact, so huge of one that the gwt team has decided to duck for now and are trying very hard not to get involved in these discusions at the current time. *Widget bridge classes, part of the application's view.* Classes used to expose the application's view to the meta data systems. *HasValue*: Provides the bridge between the metadata model and the world of widgets. From the meta data system's point of view it has some way of creating/linking with instances of HasValueString, HasValueBoolean, HasValueDate, etc.. From the widgets point of view, we have a whole bunch of text boxes, text areas, date pickers, etc. on the page. Accordingly, HasValue should only ever be used for simple leaf types on leaf widgets. *EventHandlers*: Provides a way for the meta data system controllers to add callbacks to react to widget changes. -Ray On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan [EMAIL PROTECTED] wrote: We all seem to be talking about data binding and validation a lot, and some of us are even implementing code about it. We on the GWT team hear the need and feel it ourselves. We have some notions of how we'd like to tackle this in a way that blends seamlessly with the rest of GWT, and are looking to start design and implementation in earnest before the year is out. This makes it unlikely that we'll accept core or incubator patches that implement such a system. That said, we don't want to shoot down the excellent work that's being done! If you have a system that's shaping up to meet your needs and that you want to share with the GWT community, please do! Set up a Google Code project, announce it here, embarrass us by shipping first and attracting a user base. We'll probably steal from you shamelessly and ask for your help as our own system takes shape. I hope this doesn't ruffle any feathers, and that you'll understand why we haven't been as responsive on some of these threads as we should have been. Thanks, 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: Flurry of Data binding threads
Going to stick my nose in here a bit: I certainly believe that this is all one ball of wax. I /know/ that the system that I've been working on can be used to modify the data. I know it breaks the JSR-303 paradigm so I've left it alone. The fundamental difference is that I'm expecting some output from the process. A lack of output signifies that everything worked. Also I'm not sure how much other metadata frameworks are putting in to pure JVM mode operation. I'm currently investigating mechanisms for cutting down on code overhead because creating a validator for each class has proven to be large. Maybe what I need to do (and will investigate) is creating a gimpy version of the annotations and other metadata on each method and then packaging that to be consumed by a validator. Or maybe not, still working on that. In any case I'd desperately like to merge functionality with someone else and build a larger user base and feature set. I'm not married to the JSR-303 or anything but it seemed like a good place to start. I agree with Emily's view of the world and I agree mostly with Ray. I'm a little fuzzy on the work being done on UI templates and I'm not sure about the compile-time emphasis. As I've mentioned before I need things to work on both sides of the divide. I'd love to see some work put in to code templates that work through dynamic generation at compile time and at run time. I'm sure that most people don't want me relying on constant introspection to get the job done just for performance reasons. Also the HasValue (or HasData) is a must. I thought I came up with that in the shower this morning. I must have read it somewhere here first right? Anyway I'm looking forward to what is coming in the days ahead. Shameless plug: http://code.google.com/p/gwt-validation/ Chris Ruffalo On Oct 9, 4:15 pm, Emily Crutcher [EMAIL PROTECTED] wrote: To give you an idea of where I am coming from, here is my understanding of the world: *Metadata Systems, comprising Models and Controllers* xforms, Ian's databinding system, Arthur's validation system, gwt team's upcoming proposal for data management: All part of the larger metadata, binding, code generation class of systems. Hopefully all of these can eventually use the same basic concepts and it going to be a huge undertaking to get it right. In fact, so huge of one that the gwt team has decided to duck for now and are trying very hard not to get involved in these discusions at the current time. *Widget bridge classes, part of the application's view.* Classes used to expose the application's view to the meta data systems. *HasValue*: Provides the bridge between the metadata model and the world of widgets. From the meta data system's point of view it has some way of creating/linking with instances of HasValueString, HasValueBoolean, HasValueDate, etc.. From the widgets point of view, we have a whole bunch of text boxes, text areas, date pickers, etc. on the page. Accordingly, HasValue should only ever be used for simple leaf types on leaf widgets. *EventHandlers*: Provides a way for the meta data system controllers to add callbacks to react to widget changes. -Ray On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan [EMAIL PROTECTED] wrote: We all seem to be talking about data binding and validation a lot, and some of us are even implementing code about it. We on the GWT team hear the need and feel it ourselves. We have some notions of how we'd like to tackle this in a way that blends seamlessly with the rest of GWT, and are looking to start design and implementation in earnest before the year is out. This makes it unlikely that we'll accept core or incubator patches that implement such a system. That said, we don't want to shoot down the excellent work that's being done! If you have a system that's shaping up to meet your needs and that you want to share with the GWT community, please do! Set up a Google Code project, announce it here, embarrass us by shipping first and attracting a user base. We'll probably steal from you shamelessly and ask for your help as our own system takes shape. I hope this doesn't ruffle any feathers, and that you'll understand why we haven't been as responsive on some of these threads as we should have been. Thanks, 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] Flurry of Data binding threads
[+gwt-c] -- Forwarded message -- Accordingly, HasValue should only ever be used for simple leaf types on leaf widgets. I think I object to issue with this statement, but first I'd like to see a definition of leaf types and widgets. By leaf type, I assume you mean primitive wrapper classes and String, but why is Date thrown in there? Why would DatePicker implements HasValueDate be acceptable but not PersonPicker implements HasValuePerson? What's to be gained by discouraging HasValue for complex data types? On Thu, Oct 9, 2008 at 4:15 PM, Emily Crutcher [EMAIL PROTECTED] wrote: To give you an idea of where I am coming from, here is my understanding of the world: *Metadata Systems, comprising Models and Controllers* xforms, Ian's databinding system, Arthur's validation system, gwt team's upcoming proposal for data management: All part of the larger metadata, binding, code generation class of systems. Hopefully all of these can eventually use the same basic concepts and it going to be a huge undertaking to get it right. In fact, so huge of one that the gwt team has decided to duck for now and are trying very hard not to get involved in these discusions at the current time. *Widget bridge classes, part of the application's view.* Classes used to expose the application's view to the meta data systems. *HasValue*: Provides the bridge between the metadata model and the world of widgets. From the meta data system's point of view it has some way of creating/linking with instances of HasValueString, HasValueBoolean, HasValueDate, etc.. From the widgets point of view, we have a whole bunch of text boxes, text areas, date pickers, etc. on the page. Accordingly, HasValue should only ever be used for simple leaf types on leaf widgets. *EventHandlers*: Provides a way for the meta data system controllers to add callbacks to react to widget changes. -Ray On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan [EMAIL PROTECTED] wrote: We all seem to be talking about data binding and validation a lot, and some of us are even implementing code about it. We on the GWT team hear the need and feel it ourselves. We have some notions of how we'd like to tackle this in a way that blends seamlessly with the rest of GWT, and are looking to start design and implementation in earnest before the year is out. This makes it unlikely that we'll accept core or incubator patches that implement such a system. That said, we don't want to shoot down the excellent work that's being done! If you have a system that's shaping up to meet your needs and that you want to share with the GWT community, please do! Set up a Google Code project, announce it here, embarrass us by shipping first and attracting a user base. We'll probably steal from you shamelessly and ask for your help as our own system takes shape. I hope this doesn't ruffle any feathers, and that you'll understand why we haven't been as responsive on some of these threads as we should have been. Thanks, 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: Flurry of Data binding threads
Would you normally have a UI widget as specific as a person picker? That seems like the model (a person) and the widget displaying the person might be a bit too closely bound, and we'd rather that binding took place using some sort of data binding solution. The reason for this distinction is to make it clear that the HasValue interface is not designed to be a data-binding solution, it is designed to enable* other* people to create data binding solutions. On Thu, Oct 9, 2008 at 4:55 PM, Isaac Truett [EMAIL PROTECTED] wrote: [+gwt-c] -- Forwarded message -- Accordingly, HasValue should only ever be used for simple leaf types on leaf widgets. I think I object to issue with this statement, but first I'd like to see a definition of leaf types and widgets. By leaf type, I assume you mean primitive wrapper classes and String, but why is Date thrown in there? Why would DatePicker implements HasValueDate be acceptable but not PersonPicker implements HasValuePerson? What's to be gained by discouraging HasValue for complex data types? On Thu, Oct 9, 2008 at 4:15 PM, Emily Crutcher [EMAIL PROTECTED] wrote: To give you an idea of where I am coming from, here is my understanding of the world: *Metadata Systems, comprising Models and Controllers* xforms, Ian's databinding system, Arthur's validation system, gwt team's upcoming proposal for data management: All part of the larger metadata, binding, code generation class of systems. Hopefully all of these can eventually use the same basic concepts and it going to be a huge undertaking to get it right. In fact, so huge of one that the gwt team has decided to duck for now and are trying very hard not to get involved in these discusions at the current time. *Widget bridge classes, part of the application's view.* Classes used to expose the application's view to the meta data systems. *HasValue*: Provides the bridge between the metadata model and the world of widgets. From the meta data system's point of view it has some way of creating/linking with instances of HasValueString, HasValueBoolean, HasValueDate, etc.. From the widgets point of view, we have a whole bunch of text boxes, text areas, date pickers, etc. on the page. Accordingly, HasValue should only ever be used for simple leaf types on leaf widgets. *EventHandlers*: Provides a way for the meta data system controllers to add callbacks to react to widget changes. -Ray On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan [EMAIL PROTECTED] wrote: We all seem to be talking about data binding and validation a lot, and some of us are even implementing code about it. We on the GWT team hear the need and feel it ourselves. We have some notions of how we'd like to tackle this in a way that blends seamlessly with the rest of GWT, and are looking to start design and implementation in earnest before the year is out. This makes it unlikely that we'll accept core or incubator patches that implement such a system. That said, we don't want to shoot down the excellent work that's being done! If you have a system that's shaping up to meet your needs and that you want to share with the GWT community, please do! Set up a Google Code project, announce it here, embarrass us by shipping first and attracting a user base. We'll probably steal from you shamelessly and ask for your help as our own system takes shape. I hope this doesn't ruffle any feathers, and that you'll understand why we haven't been as responsive on some of these threads as we should have been. Thanks, rjrjr -- 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: Flurry of Data binding threads
That is true, as the answer never is certainly too simplistic. The point is that the primary use case of HasValue is not to bind data objects to widgets, but to allow widgets to provide an easy to use interface for other systems. As the data binder should not have to care what the physical widget type is as long as it knows what type of value the widget can set and get. On Thu, Oct 9, 2008 at 5:32 PM, Ray Cromwell [EMAIL PROTECTED] wrote: There may be cases where this is permissible. For example, a MapWidget might return LatLng objects, rather than having a Long and Lat field which are separately bound. In the context of OpenSocial or GData, I could see a common reusable widget for picking from your network that would naturally return something like a Person. The reason it might do this, is because the binding itself might be overly complex. The widget might present friends in a tree of groups, allow search, pull from multiple networks. In general, the internal state of the widget might be too complex to expose for binding to via getter methods. -Ray On Thu, Oct 9, 2008 at 2:23 PM, Emily Crutcher [EMAIL PROTECTED] wrote: Would you normally have a UI widget as specific as a person picker? That seems like the model (a person) and the widget displaying the person might be a bit too closely bound, and we'd rather that binding took place using some sort of data binding solution. The reason for this distinction is to make it clear that the HasValue interface is not designed to be a data-binding solution, it is designed to enable other people to create data binding solutions. On Thu, Oct 9, 2008 at 4:55 PM, Isaac Truett [EMAIL PROTECTED] wrote: [+gwt-c] -- Forwarded message -- Accordingly, HasValue should only ever be used for simple leaf types on leaf widgets. I think I object to issue with this statement, but first I'd like to see a definition of leaf types and widgets. By leaf type, I assume you mean primitive wrapper classes and String, but why is Date thrown in there? Why would DatePicker implements HasValueDate be acceptable but not PersonPicker implements HasValuePerson? What's to be gained by discouraging HasValue for complex data types? On Thu, Oct 9, 2008 at 4:15 PM, Emily Crutcher [EMAIL PROTECTED] wrote: To give you an idea of where I am coming from, here is my understanding of the world: Metadata Systems, comprising Models and Controllers xforms, Ian's databinding system, Arthur's validation system, gwt team's upcoming proposal for data management: All part of the larger metadata, binding, code generation class of systems. Hopefully all of these can eventually use the same basic concepts and it going to be a huge undertaking to get it right. In fact, so huge of one that the gwt team has decided to duck for now and are trying very hard not to get involved in these discusions at the current time. Widget bridge classes, part of the application's view. Classes used to expose the application's view to the meta data systems. HasValue: Provides the bridge between the metadata model and the world of widgets. From the meta data system's point of view it has some way of creating/linking with instances of HasValueString, HasValueBoolean, HasValueDate, etc.. From the widgets point of view, we have a whole bunch of text boxes, text areas, date pickers, etc. on the page. Accordingly, HasValue should only ever be used for simple leaf types on leaf widgets. EventHandlers: Provides a way for the meta data system controllers to add callbacks to react to widget changes. -Ray On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan [EMAIL PROTECTED] wrote: We all seem to be talking about data binding and validation a lot, and some of us are even implementing code about it. We on the GWT team hear the need and feel it ourselves. We have some notions of how we'd like to tackle this in a way that blends seamlessly with the rest of GWT, and are looking to start design and implementation in earnest before the year is out. This makes it unlikely that we'll accept core or incubator patches that implement such a system. That said, we don't want to shoot down the excellent work that's being done! If you have a system that's shaping up to meet your needs and that you want to share with the GWT community, please do! Set up a Google Code project, announce it here, embarrass us by shipping first and attracting a user base. We'll probably steal from you shamelessly and ask for your help as our own system takes shape. I hope this doesn't ruffle any feathers, and that you'll understand why we haven't been as responsive on some of these threads as we should have been. Thanks, rjrjr -- There are only 10 types of people in the world:
[gwt-contrib] [google-web-toolkit commit] r3732 - releases/1.6
Author: [EMAIL PROTECTED] Date: Thu Oct 9 14:46:38 2008 New Revision: 3732 Added: releases/1.6/ - copied from r3683, /trunk/ Log: Creating 1.6 release branch based on [EMAIL PROTECTED] --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r3733 - releases/1.6
Author: [EMAIL PROTECTED] Date: Thu Oct 9 14:59:31 2008 New Revision: 3733 Added: releases/1.6/branch-info.txt (contents, props changed) Log: Creating branch info for releases/1.6. Added: releases/1.6/branch-info.txt == --- (empty file) +++ releases/1.6/branch-info.txtThu Oct 9 14:59:31 2008 @@ -0,0 +1,9 @@ +branch-info.txt for GWT 1.6 release: +Tracks interactions between this branch and other branches. +See: http://code.google.com/p/google-web-toolkit/wiki/ManagingMerges + +Copies: +/releases/1.6/ was created (r3732) as a straight copy from /trunk/@r3683 + +Merges: +--- The next merge into trunk is not yet determined, we will need to skip a few revisions to first back-port changes from trunk. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] code review requested for 1.5 branch, RPC quoting, issues 1137, 1906, and more
The attached patch, relative to releases/1.5 r3731, fixes a number of RPC
quoting issues and adds more robust tests. In addition to the listed
issues, this fixes problems with RPC working at all in the Android WebKit
browser, or for sending serialized responses via IE form post (which mangles
the U+ separator character). Also, some plugins for OOPHM run into
problems using the U+ character.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: user/test/com/google/gwt/user/server/rpc/UnicodeEscapingServiceImpl.java
===
--- user/test/com/google/gwt/user/server/rpc/UnicodeEscapingServiceImpl.java (revision 3731)
+++ user/test/com/google/gwt/user/server/rpc/UnicodeEscapingServiceImpl.java (working copy)
@@ -16,6 +16,7 @@
package com.google.gwt.user.server.rpc;
import com.google.gwt.user.client.rpc.UnicodeEscapingService;
+import com.google.gwt.user.client.rpc.UnicodeEscapingTest;
/**
* Implementation of the [EMAIL PROTECTED] UnicodeEscapingService} interface.
@@ -24,18 +25,18 @@
UnicodeEscapingService {
/**
- * @see com.google.gwt.user.client.rpc.UnicodeEscapingService#getStringContainingCharacterRange(int,
- * int)
+ * @see UnicodeEscapingService#getStringContainingCharacterRange(int, int)
*/
public String getStringContainingCharacterRange(int start, int end) {
-int nChars = end - start;
-
-char[] chars = new char[nChars];
-for (int i = 0; i nChars; ++i) {
- char ch = (char) (start + i);
- chars[i] = ch;
-}
+return UnicodeEscapingTest.getStringContainingCharacterRange(start, end);
+ }
-return new String(chars);
+ /**
+ * @see UnicodeEscapingService#verifyStringContainingCharacterRange(int, int, String)
+ */
+ public boolean verifyStringContainingCharacterRange(int start, int end,
+ String str) throws InvalidCharacterException {
+UnicodeEscapingTest.verifyStringContainingCharacterRange(start, end, str);
+return true;
}
}
Index: user/test/com/google/gwt/user/server/rpc/RPCTest.java
===
--- user/test/com/google/gwt/user/server/rpc/RPCTest.java (revision 3731)
+++ user/test/com/google/gwt/user/server/rpc/RPCTest.java (working copy)
@@ -15,10 +15,14 @@
*/
package com.google.gwt.user.server.rpc;
+import static com.google.gwt.user.client.rpc.impl.AbstractSerializationStream.RPC_SEPARATOR_CHAR;
+
import com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException;
import com.google.gwt.user.client.rpc.RemoteService;
import com.google.gwt.user.client.rpc.SerializableException;
import com.google.gwt.user.client.rpc.SerializationException;
+import com.google.gwt.user.client.rpc.impl.AbstractSerializationStream;
+import com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader;
import junit.framework.TestCase;
@@ -27,6 +31,7 @@
/**
* Tests for the [EMAIL PROTECTED] com.google.gwt.user.server.rpc.RPC RPC} class.
*/
[EMAIL PROTECTED](deprecation)
public class RPCTest extends TestCase {
private static interface A extends RemoteService {
@@ -41,60 +46,97 @@
void method1();
}
- private static final String VALID_ENCODED_REQUEST = 4\u + // version
- 0\u + // flags
- 4\u + // string table entry count
- A.class.getName() + \u + // string table entry #0
- method2 + \u + // string table entry #1
- moduleBaseURL + \u + // string table entry #2
- whitelistHashcode + \u + // string table entry #4
- 3\u + // module base URL
- 4\u + // whitelist hashcode
- 1\u + // interface name
- 2\u + // method name
- 0\u; // param count
+ private static final String VALID_ENCODED_REQUEST = +
+ AbstractSerializationStream.SERIALIZATION_STREAM_VERSION +
+ RPC_SEPARATOR_CHAR + // version
+ 0 + RPC_SEPARATOR_CHAR + // flags
+ 4 + RPC_SEPARATOR_CHAR + // string table entry count
+ A.class.getName() + RPC_SEPARATOR_CHAR + // string table entry #1
+ method2 + RPC_SEPARATOR_CHAR + // string table entry #2
+ moduleBaseURL + RPC_SEPARATOR_CHAR + // string table entry #3
+ whitelistHashcode + RPC_SEPARATOR_CHAR + // string table entry #4
+ 3 + RPC_SEPARATOR_CHAR + // module base URL
+ 4 + RPC_SEPARATOR_CHAR + // whitelist hashcode
+ 1 + RPC_SEPARATOR_CHAR + // interface name
+ 2 + RPC_SEPARATOR_CHAR + // method name
+ 0 + RPC_SEPARATOR_CHAR; // param count
- private static final String INVALID_METHOD_REQUEST = 4\u + // version
+ private static final String INVALID_METHOD_REQUEST = +
+ AbstractSerializationStream.SERIALIZATION_STREAM_VERSION +
+ RPC_SEPARATOR_CHAR + // version
+ 0 + RPC_SEPARATOR_CHAR +
[gwt-contrib] Re: [google-web-toolkit commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl
LGTM. Minor: In Pruner, it strikes me that you shouldn't have to do this. Perhaps most of the code in visit(JMethodCall) should be moved into visit(JMethod) BTW: your patch name is teh lolz. :) Scott On Thu, Oct 9, 2008 at 6:25 PM, Lex Spoon [EMAIL PROTECTED] wrote: Thanks, Scott. The patch should apply to trunk. Would you mind it going into trunk if it looks good? I'll merge it over to the runAsync branch the next time I sync it with trunk. The linear search you point at does not look so good on closer inspection. For each method in the program, there is a linear search through all the *entry* methods of the program. That's okay right now, but if there are ever a lot of entry methods, it could get expensive. Attached is an update that is just like the previous one, but it replaces the linear scan by a lookup in an IdentityHashMap. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
