[gwt-contrib] the old Event Listeners will be removed in GWT 2.0?
The old Event Listeners will be removed in GWT 2.0? My vote is yes. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Once more: HTMLPanel with custom root, now IE-proof
Reviewers: jgw, Description: Hey Joel, remember this? I had to roll it back because it didn't work on IE as it was before--IE is finicky about just where and how you write to innerHTML. Can you re-review this robustificated version? Please review this at http://gwt-code-reviews.appspot.com/51808 Affected files: user/src/com/google/gwt/user/client/ui/HTMLPanel.java user/test/com/google/gwt/user/client/ui/HTMLPanelTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Emulate JS stack traces (phase 1)
On Mon, Jul 20, 2009 at 9:20 AM, wrote: > http://gwt-code-reviews.appspot.com/47816 I'll review it. Man, what a great talking point this is going to be. Because GWT has a compiler, we get to do fine-grained rewrites like this one. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Fix a SingleJsoImpl web-mode calculation bug
Thanks. The extra test types were incorporated into singlejso.TypeHierarchyTest. Committed at r5756. http://gwt-code-reviews.appspot.com/51805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Add emma code coverage output to GWT build files
Reviewers: fabbott, Description: Description: === This patch adds emma code coverage statistics to the output of an ant test. In order to add emma stats, use the following command (copied from emma's user guide): > ant emma test Where 'emma' sets a property that enabled emma. Optionally, you can add 'emma.merge' to merge the results: > ant emma test emma.merge emma.merge needs to be its own target because we currently haltonerror when a junit test fails. If emma.merge were the last step of 'test', it would not run on a test failure. However, it does run as its own command line. Testing: I ran the tests a couple of times with emma on and off and verified that the results are as expected. Please review this at http://gwt-code-reviews.appspot.com/51807 Affected files: build-tools/ant-gwt/build.xml build.xml common.ant.xml dev/core/build.xml tools/api-checker/build.xml user/build.xml --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: test fixes for issue 47802, assertions in all (esp. web mode) tests
On 2009/07/15 17:16:37, jat wrote: > LGTM. > I only reviewed the two requested files -- let me know if I should review > anything else. > http://gwt-code-reviews.appspot.com/47817/diff/1/9 > File user/test/com/google/gwt/dev/jjs/test/CoverageTest.java (right): > http://gwt-code-reviews.appspot.com/47817/diff/1/9#newcode199 > Line 199: assertTrue(0.01 > Math.abs(1.2f - val)); > I find ordering it this way to be less clear -- I would prefer Math.abs() < > EPSILON (and defining EPSILON appropriately) as it seems to clearly indicate > what is being done. Done. http://gwt-code-reviews.appspot.com/47817 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal for improving JDO/JPA RPC support
The latter. The first time the class is encountered, GWT would search for setters (field ' theField' would cause a search for a setter 'void setTheField( arg)') and create a map from field names to setters. If there's no setter for a given field, the field would be set directly. Dan On Mon, Jul 20, 2009 at 2:18 PM, Isaac Truett wrote: > > > 5) When the object is sent back to the server, the normal RPC mechanism > is > > altered as follows > > a) the encoded server data is decoded and deserialized into the new > object > > instance > > b) the client data is populated using setXXX() method invocations > rather > > than by directly setting field values > > Is this introducing a requirement that all serializable fields have > setters? Or will direct field access be used where a setter can't be > found? > > > On Mon, Jul 20, 2009 at 2:06 PM, Daniel Rice (דניאל > רייס) wrote: > > Hi all - > > I've been working on a patch to improve support for RPC of > > persistence-enhanced objects that would replace the one I recently > submitted > > as trunk revision 5672. I'd like to give those of you who are interested > in > > the interaction between RPC and persistence a chance to help me validate > the > > design before moving forward. > > The idea is to be able to deal with different persistence mechanisms in > a > > way that does not depend too much on the details of their > implementations. > > We assume that the persistence mechanism provides a way for instances to > be > > detached from the object store, serialized, deserialized, and reattached > in > > a well-defined way. Our strategy leverages this capability as follows: > > 1) User code on the server detaches the object and places it into a state > > such that serialization is valid > > 2) GWT detects whether any instance fields are present on the object that > > were not known to client code > > 3) GWT performs hybrid serialization: > > a) GWT uses its regular RPC mechanism for the client-visible fields > > b) GWT uses Java serialization for any additional server-only instance > > fields > > c) GWT encodes the results of step (b) as a String > > d) GWT prepends the encoded String to the regular RPC data and > transmits > > to the client > > 4) Client code treats the object in the normal way and does not interact > > with the data from step (3b) > > 5) When the object is sent back to the server, the normal RPC mechanism > is > > altered as follows > > a) the encoded server data is decoded and deserialized into the new > object > > instance > > b) the client data is populated using setXXX() method invocations > rather > > than by directly setting field values > > All this is done only for classes that can be send bidirectionally, and > > which are determined to be (potentially) enhanced. > > The potential for enhancement is signaled in one of three ways: > > o The user adds the fully-qualified class name to a 'gwt.enhancedClasses' > > configuration property > > o The class is determined to have the JDO @PersistenceCapable annotation > > with detachable=true > > o The class is determined to have the JPA @Entity annotation > > If a class is determined to be potentially enhanced, the list of fields > > known to the client is added to the '.gwt.rpc' file that contains the RPC > > whitelist. This list is used by step 2 of the RPC process which compares > > the set of client- and server-visible fields. > > Step (5b) is necessary to accommodate mechanisms like that of JDO, > where > > the setter methods are enhanced to provide object state tracking (dirty > > bits). If we were to set the fields directly, the object detached state > > would not be updated properly. > > My hope is that this mechanism would be general enough to support a > > variety of persistence mechanisms without the need to add a lot of > > special-case code. I'm looking forward to any comments that you have as > to > > whether this will work with your favorite persistence API, or any other > > thoughts that you have. Thanks, > > Dan > > > > > > > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal for improving JDO/JPA RPC support
> 5) When the object is sent back to the server, the normal RPC mechanism is > altered as follows > a) the encoded server data is decoded and deserialized into the new object > instance > b) the client data is populated using setXXX() method invocations rather > than by directly setting field values Is this introducing a requirement that all serializable fields have setters? Or will direct field access be used where a setter can't be found? On Mon, Jul 20, 2009 at 2:06 PM, Daniel Rice (דניאל רייס) wrote: > Hi all - > I've been working on a patch to improve support for RPC of > persistence-enhanced objects that would replace the one I recently submitted > as trunk revision 5672. I'd like to give those of you who are interested in > the interaction between RPC and persistence a chance to help me validate the > design before moving forward. > The idea is to be able to deal with different persistence mechanisms in a > way that does not depend too much on the details of their implementations. > We assume that the persistence mechanism provides a way for instances to be > detached from the object store, serialized, deserialized, and reattached in > a well-defined way. Our strategy leverages this capability as follows: > 1) User code on the server detaches the object and places it into a state > such that serialization is valid > 2) GWT detects whether any instance fields are present on the object that > were not known to client code > 3) GWT performs hybrid serialization: > a) GWT uses its regular RPC mechanism for the client-visible fields > b) GWT uses Java serialization for any additional server-only instance > fields > c) GWT encodes the results of step (b) as a String > d) GWT prepends the encoded String to the regular RPC data and transmits > to the client > 4) Client code treats the object in the normal way and does not interact > with the data from step (3b) > 5) When the object is sent back to the server, the normal RPC mechanism is > altered as follows > a) the encoded server data is decoded and deserialized into the new object > instance > b) the client data is populated using setXXX() method invocations rather > than by directly setting field values > All this is done only for classes that can be send bidirectionally, and > which are determined to be (potentially) enhanced. > The potential for enhancement is signaled in one of three ways: > o The user adds the fully-qualified class name to a 'gwt.enhancedClasses' > configuration property > o The class is determined to have the JDO @PersistenceCapable annotation > with detachable=true > o The class is determined to have the JPA @Entity annotation > If a class is determined to be potentially enhanced, the list of fields > known to the client is added to the '.gwt.rpc' file that contains the RPC > whitelist. This list is used by step 2 of the RPC process which compares > the set of client- and server-visible fields. > Step (5b) is necessary to accommodate mechanisms like that of JDO, where > the setter methods are enhanced to provide object state tracking (dirty > bits). If we were to set the fields directly, the object detached state > would not be updated properly. > My hope is that this mechanism would be general enough to support a > variety of persistence mechanisms without the need to add a lot of > special-case code. I'm looking forward to any comments that you have as to > whether this will work with your favorite persistence API, or any other > thoughts that you have. Thanks, > Dan > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Proposal for improving JDO/JPA RPC support
Hi all - I've been working on a patch to improve support for RPC of persistence-enhanced objects that would replace the one I recently submitted as trunk revision 5672. I'd like to give those of you who are interested in the interaction between RPC and persistence a chance to help me validate the design before moving forward. The idea is to be able to deal with different persistence mechanisms in a way that does not depend too much on the details of their implementations. We assume that the persistence mechanism provides a way for instances to be detached from the object store, serialized, deserialized, and reattached in a well-defined way. Our strategy leverages this capability as follows: 1) User code on the server detaches the object and places it into a state such that serialization is valid 2) GWT detects whether any instance fields are present on the object that were not known to client code 3) GWT performs hybrid serialization: a) GWT uses its regular RPC mechanism for the client-visible fields b) GWT uses Java serialization for any additional server-only instance fields c) GWT encodes the results of step (b) as a String d) GWT prepends the encoded String to the regular RPC data and transmits to the client 4) Client code treats the object in the normal way and does not interact with the data from step (3b) 5) When the object is sent back to the server, the normal RPC mechanism is altered as follows a) the encoded server data is decoded and deserialized into the new object instance b) the client data is populated using setXXX() method invocations rather than by directly setting field values All this is done only for classes that can be send bidirectionally, and which are determined to be (potentially) enhanced. The potential for enhancement is signaled in one of three ways: o The user adds the fully-qualified class name to a 'gwt.enhancedClasses' configuration property o The class is determined to have the JDO @PersistenceCapable annotation with detachable=true o The class is determined to have the JPA @Entity annotation If a class is determined to be potentially enhanced, the list of fields known to the client is added to the '.gwt.rpc' file that contains the RPC whitelist. This list is used by step 2 of the RPC process which compares the set of client- and server-visible fields. Step (5b) is necessary to accommodate mechanisms like that of JDO, where the setter methods are enhanced to provide object state tracking (dirty bits). If we were to set the fields directly, the object detached state would not be updated properly. My hope is that this mechanism would be general enough to support a variety of persistence mechanisms without the need to add a lot of special-case code. I'm looking forward to any comments that you have as to whether this will work with your favorite persistence API, or any other thoughts that you have. Thanks, Dan --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Fix a SingleJsoImpl web-mode calculation bug
LGTM, only comment is that for tiny test types that small, it would probably be better to just make them static inners of the test class. http://gwt-code-reviews.appspot.com/51805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RR : Fix a SingleJsoImpl web-mode calculation bug
Reviewers: Lex, scottb, Message: Review requested. Description: JTypeOracle.computeSingleJsoImplData() was using an incorrect test to determine if an interface is a tag interface. It was looking at the number of methods declared on the interface type without looking at the interface's supertypes. Please review this at http://gwt-code-reviews.appspot.com/51805 Affected files: M dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java A user/test/com/google/gwt/dev/jjs/test/singlejso/DiamondImpl.java A user/test/com/google/gwt/dev/jjs/test/singlejso/IDiamond1.java A user/test/com/google/gwt/dev/jjs/test/singlejso/IDiamond2A.java A user/test/com/google/gwt/dev/jjs/test/singlejso/IDiamond2B.java M user/test/com/google/gwt/dev/jjs/test/singlejso/TypeHierarchyTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Emulate JS stack traces (phase 1)
Ping. http://gwt-code-reviews.appspot.com/47816 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
