[gwt-contrib] Re: IE8 support
On Fri, Apr 24, 2009 at 7:17 AM, Joel Webber j...@google.com wrote: Oddly, we seem to have lost the supported browsers list in the transition to 1.6 (or I'm just too blind to see it). The 1.5 doc read as follows: - Internet Explorer 6 and 7 (Windows) - Firefox 2 and 3 (Linux, Mac, and Windows) - Safari 3 (Mac) - Opera 9.5 (Mac and Windows) - Google Chrome What isn't supposed to work on FF1.5 (FF1.5-2 used Gecko 1.8, FF3 uses Gecko 1.9)? I have tested my personal app on it and I have seen no problems. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 support
Whoops, good call. That's actually a mistake -- GWT still works fine on FF 1.5 (which corresponds to Gecko 1.8.0). I'll make sure that gets fixed in the doc. On Fri, Apr 24, 2009 at 8:41 AM, John Tamplin j...@google.com wrote: On Fri, Apr 24, 2009 at 7:17 AM, Joel Webber j...@google.com wrote: Oddly, we seem to have lost the supported browsers list in the transition to 1.6 (or I'm just too blind to see it). The 1.5 doc read as follows: - Internet Explorer 6 and 7 (Windows) - Firefox 2 and 3 (Linux, Mac, and Windows) - Safari 3 (Mac) - Opera 9.5 (Mac and Windows) - Google Chrome What isn't supposed to work on FF1.5 (FF1.5-2 used Gecko 1.8, FF3 uses Gecko 1.9)? I have tested my personal app on it and I have seen no problems. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: One line patch to run emma tests as well during ant test
Amit, can you review the attached patch for solution #1 as originally outlined. Do we have a short/long test breakdown for Emma (i.e. is what's there long, and EmmaClassLoading test only short)? And do we actually want to go with short/long emma, only, or more generally have a short/long breakdown of tests for all categories (and, specifically, a smoketest entry to do short emma, hosted, and local-web tests)? I'm reluctant to do the extended version without having thought a bit more about the expected usage... On Thu, Apr 23, 2009 at 5:06 PM, Amit Manjhi amitman...@google.com wrote: I like #1 as is, but would like it better with a minor modification. I think there should be 2 explicit named targets for emma stuff: one consisting of the short tests and the other consisting of long tests. The short tests should always run while the long tests should at least run during the continuous build. For now, both test targets can be included in default with the understanding that we can cut the long test from the default, if 'ant test' starts taking too long. This would mean moving the second gwt.unit from test.hosted as a separate target that is always invoked and fixing the bad test.out value of default.hosted.emma.tests and also specifically excluding EmmaClassLoadingTest.class from the long tests. Amit On Thu, Apr 23, 2009 at 12:58 PM, Freeland Abbott fabb...@google.comwrote: Er. Can I take back my approval? It looks like test.hosted already and also runs the Emma tests, and the test.hosted.emma target has a bad test.out value. We can, I think, do any one of: 1. have test.hosted.emma as an explicit named target, fix its test.out, cut the second gwt.junit from test.hosted, and keep your patch, or 2. have test.hosted embody emma tests, cutting your patch and the test.hosted.emma target, or 3. have test.hosted embody emma tests, but allow them to be run separately, cutting your patch and fixing test.hosted.emma's test.out. I think I prefer #1 and dislike #3. Any dissenting opinion, while I make the patch for that? On Thu, Apr 23, 2009 at 2:01 PM, Amit Manjhi amitman...@google.comwrote: Makes sense. Thanks. Commited as r5275 On Thu, Apr 23, 2009 at 10:52 AM, Freeland Abbott fabb...@google.comwrote: But now we're running them twice. I'll give you the LGTM as testing is good, but I'm a bit worried for the time penalty. But if it's a problem, we can fall back to the other approach when it's clear it's a problem. On Thu, Apr 23, 2009 at 1:50 PM, Amit Manjhi amitman...@google.comwrote: It just requires emma.jar which is pulled in from the tools dir. The time is basically the same as running hosted mode user tests. Amit On Thu, Apr 23, 2009 at 10:41 AM, Freeland Abbott fabb...@google.comwrote: Well, that will run emma tests for everyone everywhere who does ant test... Does it require anything in particular to work, which people might not have installed? And is the time significant? We can easily enough tweak the continuous builder configuration to explicitly run the emma tests, if either of those questions gets a bad answer. If they're both good, then maybe it's reasonable for all users to run all tests (with the caveat that non-local web tests also need properties set, or they become no-ops...) On Thu, Apr 23, 2009 at 1:10 PM, Amit Manjhi amitman...@google.comwrote: Hi Freeland, The patch makes the emma tests run as part of our continuous build. The tests basically run all tests in user, except where sun's and openjdk's javac are broken, with emma.jar on the classpath. Regards, Amit --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- emma-refix.trunk@r5279.patch Description: Binary data
[gwt-contrib] Re: RR: One line patch to run emma tests as well during ant test
LGTM. Yes, the short/long test breakdown should be EmmaClassLoadingTest and others. It is okay if we do this short/long partitioning later, when we do it across all tests. Amit On Fri, Apr 24, 2009 at 10:13 AM, Freeland Abbott fabb...@google.comwrote: Amit, can you review the attached patch for solution #1 as originally outlined. Do we have a short/long test breakdown for Emma (i.e. is what's there long, and EmmaClassLoading test only short)? And do we actually want to go with short/long emma, only, or more generally have a short/long breakdown of tests for all categories (and, specifically, a smoketest entry to do short emma, hosted, and local-web tests)? I'm reluctant to do the extended version without having thought a bit more about the expected usage... On Thu, Apr 23, 2009 at 5:06 PM, Amit Manjhi amitman...@google.comwrote: I like #1 as is, but would like it better with a minor modification. I think there should be 2 explicit named targets for emma stuff: one consisting of the short tests and the other consisting of long tests. The short tests should always run while the long tests should at least run during the continuous build. For now, both test targets can be included in default with the understanding that we can cut the long test from the default, if 'ant test' starts taking too long. This would mean moving the second gwt.unit from test.hosted as a separate target that is always invoked and fixing the bad test.out value of default.hosted.emma.tests and also specifically excluding EmmaClassLoadingTest.class from the long tests. Amit On Thu, Apr 23, 2009 at 12:58 PM, Freeland Abbott fabb...@google.comwrote: Er. Can I take back my approval? It looks like test.hosted already and also runs the Emma tests, and the test.hosted.emma target has a bad test.out value. We can, I think, do any one of: 1. have test.hosted.emma as an explicit named target, fix its test.out, cut the second gwt.junit from test.hosted, and keep your patch, or 2. have test.hosted embody emma tests, cutting your patch and the test.hosted.emma target, or 3. have test.hosted embody emma tests, but allow them to be run separately, cutting your patch and fixing test.hosted.emma's test.out. I think I prefer #1 and dislike #3. Any dissenting opinion, while I make the patch for that? On Thu, Apr 23, 2009 at 2:01 PM, Amit Manjhi amitman...@google.comwrote: Makes sense. Thanks. Commited as r5275 On Thu, Apr 23, 2009 at 10:52 AM, Freeland Abbott fabb...@google.comwrote: But now we're running them twice. I'll give you the LGTM as testing is good, but I'm a bit worried for the time penalty. But if it's a problem, we can fall back to the other approach when it's clear it's a problem. On Thu, Apr 23, 2009 at 1:50 PM, Amit Manjhi amitman...@google.comwrote: It just requires emma.jar which is pulled in from the tools dir. The time is basically the same as running hosted mode user tests. Amit On Thu, Apr 23, 2009 at 10:41 AM, Freeland Abbott fabb...@google.com wrote: Well, that will run emma tests for everyone everywhere who does ant test... Does it require anything in particular to work, which people might not have installed? And is the time significant? We can easily enough tweak the continuous builder configuration to explicitly run the emma tests, if either of those questions gets a bad answer. If they're both good, then maybe it's reasonable for all users to run all tests (with the caveat that non-local web tests also need properties set, or they become no-ops...) On Thu, Apr 23, 2009 at 1:10 PM, Amit Manjhi amitman...@google.comwrote: Hi Freeland, The patch makes the emma tests run as part of our continuous build. The tests basically run all tests in user, except where sun's and openjdk's javac are broken, with emma.jar on the classpath. Regards, Amit --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5280 - Fixing the duplicate emma test drivers: only test.hosted.emma remains, not the implicit e...
Author: fabb...@google.com
Date: Fri Apr 24 11:03:25 2009
New Revision: 5280
Modified:
trunk/user/build.xml
Log:
Fixing the duplicate emma test drivers: only test.hosted.emma remains, not
the implicit emma test in test.hosted. Its output is (correctly)
$os-hosted-mode-emma, not $os-hosted-mode.
Review by: amitmanjhi
Modified: trunk/user/build.xml
==
--- trunk/user/build.xml(original)
+++ trunk/user/build.xmlFri Apr 24 11:03:25 2009
@@ -110,7 +110,7 @@
/target
target name=test.hosted.emma depends=compile, compile.tests
description=Run all hosted-mode tests in emma mode.
-gwt.junit test.args=${test.args}
test.out=${junit.out}/${build.host.platform}-hosted-mode
test.cases=default.hosted.emma.tests
+gwt.junit test.args=${test.args}
test.out=${junit.out}/${build.host.platform}-hosted-mode-emma
test.cases=default.hosted.emma.tests
extraclasspaths
pathelement location=${gwt.build}/out/dev/core/bin-test /
pathelement location=${gwt.tools.redist}/emma/emma.jar /
@@ -122,12 +122,6 @@
gwt.junit test.args=${test.args}
test.out=${junit.out}/${build.host.platform}-hosted-mode
test.cases=default.hosted.tests
extraclasspaths
pathelement location=${gwt.build}/out/dev/core/bin-test /
- /extraclasspaths
-/gwt.junit
-gwt.junit test.args=${test.args}
test.out=${junit.out}/${build.host.platform}-hosted-mode-emma
test.cases=default.emma.tests
- extraclasspaths
-pathelement location=${gwt.build}/out/dev/core/bin-test /
-pathelement location=${gwt.tools.redist}/emma/emma.jar /
/extraclasspaths
/gwt.junit
/target
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 support
LGTM I see a lot of tab characters, but the code looks great. It also looks like you've consolidated a lot of code. http://gwt-code-reviews.appspot.com/29803/diff/1/5 File user/src/com/google/gwt/dom/DOM.gwt.xml (right): http://gwt-code-reviews.appspot.com/29803/diff/1/5#newcode56 Line 56: when-property-is name=user.agent value=ie6/ too many spaces http://gwt-code-reviews.appspot.com/29803/diff/1/12 File user/src/com/google/gwt/user/Form.gwt.xml (right): http://gwt-code-reviews.appspot.com/29803/diff/1/12#newcode31 Line 31: when-property-is name=user.agent value=ie6/ Spacing, and what are those two red arrows? »» http://gwt-code-reviews.appspot.com/29803/diff/1/7 File user/src/com/google/gwt/user/RichText.gwt.xml (right): http://gwt-code-reviews.appspot.com/29803/diff/1/7#newcode27 Line 27: when-property-is name=user.agent value=ie6 / Remove the »», which I assume are tabs. http://gwt-code-reviews.appspot.com/29803/diff/1/8 File user/src/com/google/gwt/user/TextBox.gwt.xml (right): http://gwt-code-reviews.appspot.com/29803/diff/1/8#newcode32 Line 32: when-property-is name=user.agent value=ie6/ Remove »» http://gwt-code-reviews.appspot.com/29803/diff/1/6 File user/src/com/google/gwt/xml/XML.gwt.xml (right): http://gwt-code-reviews.appspot.com/29803/diff/1/6#newcode39 Line 39: when-property-is name=user.agent value=ie6/ tabs again »» http://gwt-code-reviews.appspot.com/29803 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
GWT over RPC transports Re: [gwt-contrib] Re: cross site RPC through iframes
Here's a new blog post from me that might help you in implementing: http://timepedia.blogspot.com/2009/04/gwt-rpc-over-arbitrary-transports-uber.html -Ray 2009/4/22 Piotr Jaroszyński p.jaroszyn...@gmail.com: 2009/4/21 Ray Cromwell cromwell...@gmail.com: It wouldn't be hard to do it using this: http://timepedia.blogspot.com/2008/07/cross-domain-formpanel-submissions-in.html http://development.lombardi.com/?p=611 Thank you very much, window.name hack looks really nice. I will look into making it possible to use GWT RPC through it easily. -- Best Regards, Piotr Jaroszyński --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5281 - First draft, based on initial meeting wherein consensus was essentially achieved.
Author: br...@google.com
Date: Fri Apr 24 14:53:02 2009
New Revision: 5281
Added:
wiki/MultiValuedConfigProperties.wiki
Log:
First draft, based on initial meeting wherein consensus was essentially
achieved.
Added: wiki/MultiValuedConfigProperties.wiki
==
--- (empty file)
+++ wiki/MultiValuedConfigProperties.wiki Fri Apr 24 14:53:02 2009
@@ -0,0 +1,103 @@
+#summary Design doc describing how to enhance config properties to support
multiple values
+#labels Phase-Design
+
+== Background ==
+In GWT 1.6, a new module XML element was introduced called
`set-configuration-property`.
+Its purpose is to provide to generators and linkers configuration
parameters that cannot be appropriately expressed via deferred binding
properties,
+either because they would never drive multiple permutations or because
they have values that aren't enumerable.
+For example, if a generator needs to be passed a filename at compile-time,
deferred binding properties make no sense, but a configuration property is
perfect.
+
+However, in a recent design discussion for RPC blacklist support, we found
`set-configuration-property` a bit deficient.
+The subsequent sections explain the current behavior, spotlighting the
problematic aspects.
+
+=== Shared namespace ===
+At present, the namespaces of deferred binding properties and
configuration properties are the same.
+This was intentional, and the original motivations were good:
+ * module writers couldn't accidentally create a configuration property
and deferred binding property with the same name, causing subsequent
ambiguity and
+ * it might be useful to transparently change a property from a
configuration property into a deferred binding property.
+Based on the reasoning above, `PropertyOracle#getPropertyValue` is
specified to return either a deferred binding property or a configuration
property.
+Generators can simply query for a property value without knowing whether
they are receiving a configuration property or a deferred binding property
as an answer.
+
+In retrospect, unifying the namespace creates more problems than it solves.
+Although deferred binding properties have a strict identifier-like token
syntax, configuration properties do not,
+so the idea of swapping a property from one type to the other could break
accidental assumptions about the format of a result value of a
`getPropertyValue` call in generators.
+Additionally, `PropertyOracle#getProperyValueSet` has no relevant meaning
for configuration properties,
+creating the hard-to-understand behavior that a given property name can
succeed in a call to `getPropertyValue`
+even though `getPropertyValueSet` with the same property name will throw
an exception (that is, in the case where the name refers to a configuration
property).
+
+=== Single-valued versus multi-valued configuration properties ===
+The original design of configuration properties was supposed to be very
simple, similar to Java system properties.
+But what happens when a multi-valued configuration property is needed?
+In the case of RPC blacklists, we needed to allow multiple modules to
contribute to an accumulated value -- the list of types that should not
participate in RPC.
+
+There are two main ways to approach this. The most obvious is something
like `append-configuration-property` which simply appends to the string
value, perhaps adding a delimiter.
+This has the virtue of being simple and not requiring APIs changes.
+However, it pushes extra complications onto generator writers.
+Questions such as
+ * Should a delimiter be added automatically?
+* If so, which one will make everyone happy (if such a thing exists)?
+* If not, what happens if the string was previously empty, thus
creating a bogus initial delimiter?
+ * How do we differentiate the concept of 'no value' from the concept
of 'has a value that is the empty string'?
+* Can you append a 'no value'?
+ * How would we recommend people parse this string within generators?
+So, it gets tricky using strings fro multi-valued configuration properties.
+
+== Proposal ==
+To address the above weakness, approximately the following changes are
proposed.
+
+1) Deprecate `PropertyOracle#getPropertyValue` and `#getPropertyValueSet`,
leaving their behavior unchanged
+
+2) Add `com.google.gwt.core.ext.generator.SelectionProperty`
+{{{
+package com.google.gwt.core.ext.generator;
+public interface SelectionProperty {
+ // The name of the property.
+ String getName();
+
+ // The value for the permutation currently being considered.
+ String getCurrentValue();
+
+ // In unspecified but consistent order.
+ SortedSetString getPossibleValues();
+}
+}}}
+
+3) Add `com.google.gwt.core.ext.generator.ConfigurationProperty`
+{{{
+package com.google.gwt.core.ext.generator;
+public interface ConfigurationProperty {
+ // The name of the property.
+
[gwt-contrib] RR: Design doc for multi-valued configuration properties
Hi GWT community, At a recent meeting intended to be a discussion of how to design blacklist support for RPC, we realized that we wanted to make some changes to the new set-configuration-property module XML support. It ended up becaming a prerequisite to continuing with RPC blacklist support. In an effort to get these changes made quickly so that we can get on with blacklist support, I've written up notes from that meeting into the following design doc: http://code.google.com/p/google-web-toolkit/wiki/MultiValuedConfigProperties Please comment in the design doc or on this thread if you have thoughts. -- Bruce --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5282 - Edited wiki page through web user interface.
Author: br...@google.com Date: Fri Apr 24 15:02:18 2009 New Revision: 5282 Modified: wiki/MultiValuedConfigProperties.wiki Log: Edited wiki page through web user interface. Modified: wiki/MultiValuedConfigProperties.wiki == --- wiki/MultiValuedConfigProperties.wiki (original) +++ wiki/MultiValuedConfigProperties.wiki Fri Apr 24 15:02:18 2009 @@ -2,21 +2,18 @@ #labels Phase-Design == Background == -In GWT 1.6, a new module XML element was introduced called `set-configuration-property`. -Its purpose is to provide to generators and linkers configuration parameters that cannot be appropriately expressed via deferred binding properties, -either because they would never drive multiple permutations or because they have values that aren't enumerable. -For example, if a generator needs to be passed a filename at compile-time, deferred binding properties make no sense, but a configuration property is perfect. +In GWT 1.6, a new module XML element was introduced called `set-configuration-property`. Its purpose is to provide to generators and linkers configuration parameters that cannot be appropriately expressed via deferred binding properties, +either because they would never drive multiple permutations or because they have values that aren't enumerable. For example, if a generator needs to be passed a filename at compile-time, deferred binding properties make no sense, but a configuration property is perfect. -However, in a recent design discussion for RPC blacklist support, we found `set-configuration-property` a bit deficient. -The subsequent sections explain the current behavior, spotlighting the problematic aspects. +However, in a recent design discussion for RPC blacklist support, we found `set-configuration-property` a bit deficient. The subsequent sections explain the current behavior, spotlighting the problematic aspects. === Shared namespace === -At present, the namespaces of deferred binding properties and configuration properties are the same. -This was intentional, and the original motivations were good: +At present, the namespaces of deferred binding properties and configuration properties are the same. This was intentional, and the original motivations were good: + * module writers couldn't accidentally create a configuration property and deferred binding property with the same name, causing subsequent ambiguity and - * it might be useful to transparently change a property from a configuration property into a deferred binding property. -Based on the reasoning above, `PropertyOracle#getPropertyValue` is specified to return either a deferred binding property or a configuration property. -Generators can simply query for a property value without knowing whether they are receiving a configuration property or a deferred binding property as an answer. + * it might be useful to transparently change a property from a configuration property into a deferred binding property. + +Based on the reasoning above, `PropertyOracle#getPropertyValue` is specified to return either a deferred binding property or a configuration property. Generators can simply query for a property value without knowing whether they are receiving a configuration property or a deferred binding property as an answer. In retrospect, unifying the namespace creates more problems than it solves. Although deferred binding properties have a strict identifier-like token syntax, configuration properties do not, --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 support
My 2 c€nts.
...and this patch could also address issue 2815
http://code.google.com/p/google-web-toolkit/issues/detail?id=2815
(and do not forget issue 2938:
http://code.google.com/p/google-web-toolkit/issues/detail?id=2938 )
http://gwt-code-reviews.appspot.com/29803/diff/1/9
File user/src/com/google/gwt/user/UserAgent.gwt.xml (right):
http://gwt-code-reviews.appspot.com/29803/diff/1/9#newcode38
Line 38: if (v = 8000) {
I believe ie8 here means X-UA-Compatibility: IE=8, so detecting the
version from the navigator.userAgent is probably not enough [1], and
document.documentMode should be used instead [2], otherwise the ie8
implementation would have to do a
quirks-vs-standards-vs-super-standards-mode-detection, which would make
the ie6 impl quite useless.
[1] Mike Ormond reports that a document can be displayed in IE=5 or IE=7
mode while the UA is still reported as MSIE 8.0
http://blogs.msdn.com/mikeormond/archive/2008/09/25/ie-8-compatibility-meta-tags-http-headers-user-agent-strings-etc-etc.aspx
[2] http://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx#GetMode
http://gwt-code-reviews.appspot.com/29803
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
