[gwt-contrib] Comment on WAR_Design_1_6 in google-web-toolkit
Comment by mbiama.e...@live.fr: http://httpd.apache.org/docs/2.0/mod/core.html/?prefered=www.angosso_com_cgi.html/directive-dict.html#serverroot For more information: http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Add a tab key to wire protocol
On 2009/08/10 23:10:02, jat wrote: I also renamed the write* methods based on your earlier feedback. Minor nit, but is it really appropriate to call this a 'tab' key? It seems like more of a window key, by which I mean browser window, which may be a top-level window, a tab, or a frame. http://gwt-code-reviews.appspot.com/56812 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Add a tab key to wire protocol
On Tue, Aug 11, 2009 at 9:26 AM, j...@google.com wrote: On 2009/08/10 23:10:02, jat wrote: I also renamed the write* methods based on your earlier feedback. Minor nit, but is it really appropriate to call this a 'tab' key? It seems like more of a window key, by which I mean browser window, which may be a top-level window, a tab, or a frame. Maybe by connotation is just different, but it seems to me that the unit is a browser tab, whether it is contained in its own window or shares another window with other tabs. Window seems way to overloaded, including the JS window object and window-manager windows. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder first impressions
Hey Gary, I can't speak more generally about GWT, but can give you some info on the plugin. We'll need more than just an XML schema (though we'll still have a simple schema defining the legal top-level elements, for example). The autocomplete choices will be too dynamic to be included in a schema. For example, when opening a tag, we'll offer autocomplete choices for each UiBinder widget in your code base. We could generate an XSD from this information, but it may not be worthwhile adding that extra step. Thanks, jason On Mon, Aug 10, 2009 at 9:43 PM, Gary Miller miller.ga...@gmail.com wrote: I'd like to start off by saying a big THANKS. We've been hanging out for this, and it is making a great first impression. In regards to GEP, validation, code completion etc. Would it be possible to use a xml schema per name space? My XSD skills aren't to the point where I would know if this is even viable. If this is a Buddha nature question, then please let me unask it. Could the need to custom parsers be solved by the same mechanism as the GEP support? Again with some meta data for widgets or widget packages. e.g. XSD per package or an UiBinder Widget Annotations. Are more custom parsers being written for the GWT UI components? Or is this the set until the public parsing interface is nailed down? As an example I tried to use visibleItemCount on ListBox go an exception class ListBox has no appropriate setVisibleItemCount() method. This is easy enough to work around by place the setVisibleItemCount all in the java code. Would it make any sense for @UiField to be applied to a setter/getter method. It might then be possible to code an interface that is bound to the ui and allow different implementions. e.g. a common dialog interface. Regards Gary Miller On Aug 11, 12:08 am, Miguel Méndez mmen...@google.com wrote: On Mon, Aug 10, 2009 at 9:59 AM, Arthur Kalmenson arthur.k...@gmail.com wrote: Hello everyone, We've been playing with UiBinder and I thought it'd be a good idea to share what we've seen so far (and ask some questions). Some of the apps we write are used by more then one hospital and this requires a tailored UI depending on the user's preferences and to store additional information that a particular hospital needs to keep track of. At the moment, writing UI in a swing style, we program to interfaces and use GIN to bind everything together. Using different AbstractGinModules and Ginjectors, we can tie the application together in different ways using different UI implementations. What would be the way to do this with UiBinder? From what we could tell, one would use UiTemplate, but there doesn't seem to be a way to configure the String in UiTemplate easily through a GIN module. Are there alternatives? Following the programming to interfaces theme, we've been doing that with UiBinder, but have run into an issue when trying to build a larger UI page out of smaller ui.xml classes. It seems that referring to interfaces in ui.xml doesn't work, so you need to work with direct concrete classes. But this would force you to use a particular implementation when we'd like to keep it generic. Lastly, I guess this is something just for consideration for the future, but having the GEP work with UiBinder would make using it a lot easier. For example, having code completion, refactoring support and error messages right in Eclipse. This would be something like the Spring IDE plugin that one you configure Spring XML files with all the above features. We have started looking at how the GPE could support UiBinder. Of course, validation with markers and quick fixes, refactoring, etc are all part of it. Thanks again for the UiBinder, we'll definitely have to spend more time with it. Best regards, -- Arthur Kalmenson -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] add names to runAsync calls
Reviewers: scottb, Description: This patch allows naming a runAsync call using a class literal. There are now two overloads of GWT.runAsync, and the second one takes a class literal as an argument. That literal is recorded by the ReplaceRunAsyncs pass. It can then be used in the specification of an initial split point sequence, which is implemented in A successful test case is added in InitialLoadSequenceTest, and a failing test case is added in RunAsyncNameTest. The naming tests are currently skimpy. We could update them once the compiler testing framework patch is in. Please review this at http://gwt-code-reviews.appspot.com/56814 Affected files: dev/core/src/com/google/gwt/dev/jdt/FindDeferredBindingSitesVisitor.java dev/core/src/com/google/gwt/dev/jjs/impl/CodeSplitter.java dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java dev/core/test/com/google/gwt/dev/javac/RunAsyncNameTest.java dev/core/test/com/google/gwt/dev/javac/TypeOracleTestingUtils.java dev/core/test/com/google/gwt/dev/javac/impl/JavaResourceBase.java user/src/com/google/gwt/core/client/GWT.java user/test/com/google/gwt/dev/jjs/InitialLoadSequence.gwt.xml user/test/com/google/gwt/dev/jjs/test/InitialLoadSequenceTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5938 committed - Changed recently-committed test to exclude HtmlUnit, because it relies...
Revision: 5938
Author: j...@google.com
Date: Tue Aug 11 09:09:06 2009
Log: Changed recently-committed test to exclude HtmlUnit, because it relies
on
correct layout.
http://code.google.com/p/google-web-toolkit/source/detail?r=5938
Modified:
/trunk/user/test/com/google/gwt/user/client/ui/PopupTest.java
===
--- /trunk/user/test/com/google/gwt/user/client/ui/PopupTest.java Mon Aug
10 13:56:51 2009
+++ /trunk/user/test/com/google/gwt/user/client/ui/PopupTest.java Tue Aug
11 09:09:06 2009
@@ -116,6 +116,7 @@
* Tests that a large PopupPanel is not positioned off the top or left
edges
* of the browser window, making part of the panel unreachable.
*/
+ @DoNotRunWith(Platform.Htmlunit)
public void testCenterLargePopup() {
PopupPanel popup = new PopupPanel();
popup.setHeight(4096px);
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5939 committed - /trunk 5936 was merged into this branch...
Revision: 5939
Author: rj...@google.com
Date: Tue Aug 11 09:25:40 2009
Log: /trunk 5936 was merged into this branch
another wire protocol change to support the future ability to
differentiate opening a new tab from refreshing an existing one
svn merge -c5936 https://google-web-toolkit.googlecode.com/svn/trunk .
http://code.google.com/p/google-web-toolkit/source/detail?r=5939
Modified:
/branches/snapshot-2009.08.04-ihm-r5888/branch-info.txt
/branches/snapshot-2009.08.04-ihm-r5888/dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html
/branches/snapshot-2009.08.04-ihm-r5888/dev/core/src/com/google/gwt/dev/SwtHostedModeBase.java
/branches/snapshot-2009.08.04-ihm-r5888/dev/core/src/com/google/gwt/dev/shell/BrowserWidgetHost.java
/branches/snapshot-2009.08.04-ihm-r5888/dev/oophm/src/com/google/gwt/dev/OophmHostedModeBase.java
/branches/snapshot-2009.08.04-ihm-r5888/dev/oophm/src/com/google/gwt/dev/shell/BrowserChannel.java
/branches/snapshot-2009.08.04-ihm-r5888/dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
/branches/snapshot-2009.08.04-ihm-r5888/dev/oophm/src/com/google/gwt/dev/shell/OophmSessionHandler.java
/branches/snapshot-2009.08.04-ihm-r5888/dev/oophm/test/com/google/gwt/dev/shell/BrowserChannelTest.java
===
--- /branches/snapshot-2009.08.04-ihm-r5888/branch-info.txt Mon Aug 10
15:37:54 2009
+++ /branches/snapshot-2009.08.04-ihm-r5888/branch-info.txt Tue Aug 11
09:25:40 2009
@@ -22,3 +22,7 @@
/trunk c5928 was merged into this branch
Fixes plugin backwards-compatibility fallback error in Safari introduced
by trunk r5910:5912
svn merge -c5928 https://google-web-toolkit.googlecode.com/svn/trunk .
+
+/trunk 5936 was merged into this branch
+ another wire protocol change to support the future ability to
differentiate opening a new tab from refreshing an existing one
+ svn merge -c5936 https://google-web-toolkit.googlecode.com/svn/trunk .
===
---
/branches/snapshot-2009.08.04-ihm-r5888/dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html
Mon Aug 10 15:37:54 2009
+++
/branches/snapshot-2009.08.04-ihm-r5888/dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html
Tue Aug 11 09:25:40 2009
@@ -229,7 +229,7 @@
}
} catch (e) {
}
- }
+ }
loadIframe(http://google-web-toolkit.googlecode.com/svn/trunk/plugins/MissingBrowserPlugin.html;);
} else {
if (!plugin.connect(url, topWin.__gwt_SessionID, $hosted,
$moduleName,
===
---
/branches/snapshot-2009.08.04-ihm-r5888/dev/core/src/com/google/gwt/dev/SwtHostedModeBase.java
Fri Aug 7 15:17:40 2009
+++
/branches/snapshot-2009.08.04-ihm-r5888/dev/core/src/com/google/gwt/dev/SwtHostedModeBase.java
Tue Aug 11 09:25:40 2009
@@ -76,8 +76,9 @@
}
public ModuleSpaceHost createModuleSpaceHost(TreeLogger logger,
-String moduleName, String userAgent, String url, String sessionKey,
-String remoteEndpoint) throws UnableToCompleteException {
+String moduleName, String userAgent, String url, String tabKey,
+String sessionKey, String remoteEndpoint)
+throws UnableToCompleteException {
throw new UnsupportedOperationException();
}
===
---
/branches/snapshot-2009.08.04-ihm-r5888/dev/core/src/com/google/gwt/dev/shell/BrowserWidgetHost.java
Fri Aug 7 15:17:40 2009
+++
/branches/snapshot-2009.08.04-ihm-r5888/dev/core/src/com/google/gwt/dev/shell/BrowserWidgetHost.java
Tue Aug 11 09:25:40 2009
@@ -53,12 +53,14 @@
* @param logger
* @param moduleName
* @param userAgent
- * @param url URL of top-level window (may be null for old browser
plugins)
- * @param sessionKey unique session key (may be null for old browser
plugins)
+ * @param url URL of top-level window, may be null for old browser
plugins
+ * @param tabKey opaque key for the tab, may be empty string if the
plugin
+ * can't distinguish tabs or null if using an old browser plugin
+ * @param sessionKey unique session key, may be null for old browser
plugins
* @param remoteEndpoint
*/
ModuleSpaceHost createModuleSpaceHost(TreeLogger logger, String
moduleName,
- String userAgent, String url, String sessionKey,
+ String userAgent, String url, String tabKey, String sessionKey,
String remoteEndpoint) throws UnableToCompleteException;
TreeLogger getLogger();
===
---
/branches/snapshot-2009.08.04-ihm-r5888/dev/oophm/src/com/google/gwt/dev/OophmHostedModeBase.java
Fri Aug 7 15:17:40 2009
+++
/branches/snapshot-2009.08.04-ihm-r5888/dev/oophm/src/com/google/gwt/dev/OophmHostedModeBase.java
Tue Aug 11 09:25:40 2009
@@ -142,8 +142,9 @@
}
public ModuleSpaceHost
[gwt-contrib] Fix non-fatal WeakMapping compile errors
LGTM http://gwt-code-reviews.appspot.com/57810 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5940 committed - Fix compiler errors when importing only Core.gwt.xml....
Revision: 5940
Author: b...@google.com
Date: Tue Aug 11 10:21:03 2009
Log: Fix compiler errors when importing only Core.gwt.xml.
Fix generic type warnings in WeakMapping.
Patch by: bobv
Review by: rjrjr
http://code.google.com/p/google-web-toolkit/source/detail?r=5940
Added:
/trunk/user/super/com/google/gwt/core
/trunk/user/super/com/google/gwt/core/translatable
/trunk/user/super/com/google/gwt/core/translatable/com
/trunk/user/super/com/google/gwt/core/translatable/com/google
/trunk/user/super/com/google/gwt/core/translatable/com/google/gwt
/trunk/user/super/com/google/gwt/core/translatable/com/google/gwt/core
/trunk/user/super/com/google/gwt/core/translatable/com/google/gwt/core/client
/trunk/user/super/com/google/gwt/core/translatable/com/google/gwt/core/client/impl
/trunk/user/super/com/google/gwt/core/translatable/com/google/gwt/core/client/impl/WeakMapping.java
Deleted:
/trunk/user/super/com/google/gwt/user/translatable/com/google/gwt/core/client/impl/WeakMapping.java
Modified:
/trunk/user/src/com/google/gwt/core/Core.gwt.xml
/trunk/user/src/com/google/gwt/core/client/impl/WeakMapping.java
===
--- /dev/null
+++
/trunk/user/super/com/google/gwt/core/translatable/com/google/gwt/core/client/impl/WeakMapping.java
Tue Aug 11 10:21:03 2009
@@ -0,0 +1,65 @@
+/*
+ * Copyright 2009 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.core.client.impl;
+
+import com.google.gwt.core.client.GwtScriptOnly;
+
+/**
+ * A class associating a (String, Object) map with arbitrary source objects
+ * (except for Strings). This implementation is used in web mode.
+ */
+...@gwtscriptonly
+public class WeakMapping {
+
+ /*
+ * This implementation is used in web mode only. It stores the (key,
value)
+ * maps in an expando field on their source objects.
+ */
+
+ /**
+ * Returns the Object associated with the given key in the (key, value)
+ * mapping associated with the given Object instance.
+ *
+ * @param instance the source Object.
+ * @param key a String key.
+ * @return an Object associated with that key on the given instance, or
null.
+ */
+ public static native Object get(Object instance, String key) /*-{
+return instan...@java.lang.object::expando[':' + key];
+ }-*/;
+
+ /**
+ * Associates a value with a given key in the (key, value) mapping
associated
+ * with the given Object instance. Note that the key space is
module-wide, so
+ * some care should be taken to choose sufficiently unique identifiers.
+ *
+ * @param instance the source Object.
+ * @param key a String key.
+ * @param value the Object to associate with the key on the given source
+ * Object.
+ */
+ public static void set(Object instance, String key, Object value) {
+assert !(instance instanceof String) : Cannot use Strings with
WeakMapping;
+setNative(instance, key, value);
+ }
+
+ private static native void setNative(Object instance, String key, Object
value) /*-{
+if (!instan...@java.lang.object::expando) {
+ instan...@java.lang.object::expando = {};
+}
+instan...@java.lang.object::expando[':' + key] = value;
+ }-*/;
+}
===
---
/trunk/user/super/com/google/gwt/user/translatable/com/google/gwt/core/client/impl/WeakMapping.java
Tue Jul 28 11:57:21 2009
+++ /dev/null
@@ -1,65 +0,0 @@
-/*
- * Copyright 2009 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.core.client.impl;
-
-import com.google.gwt.core.client.GwtScriptOnly;
-
-/**
- * A class associating a (String, Object) map with arbitrary source objects
- * (except for Strings). This implementation is used in web mode.
- */
-...@gwtscriptonly
-public class WeakMapping {
-
- /*
- * This implementation is used in web mode only. It stores the (key,
value)
- * maps in an expando
[gwt-contrib] [google-web-toolkit] r5941 committed - Swap expectaed and actual args in assertEquals()
Revision: 5941
Author: r...@google.com
Date: Tue Aug 11 10:26:45 2009
Log: Swap expectaed and actual args in assertEquals()
http://code.google.com/p/google-web-toolkit/source/detail?r=5941
Modified:
/trunk/user/test/com/google/gwt/emultest/java/util/EnumSetTest.java
===
--- /trunk/user/test/com/google/gwt/emultest/java/util/EnumSetTest.java Thu
Aug 6 10:54:59 2009
+++ /trunk/user/test/com/google/gwt/emultest/java/util/EnumSetTest.java Tue
Aug 11 10:26:45 2009
@@ -46,7 +46,7 @@
*/
public void testDuplicates() {
EnumSetNumbers set = EnumSet.of(Numbers.Two, Numbers.One,
Numbers.Two, Numbers.One);
-assertEquals(set.size(), 2);
+assertEquals(2, set.size());
assertTrue(set.contains(Numbers.One));
assertTrue(set.contains(Numbers.Two));
}
@@ -58,7 +58,7 @@
EnumSetNumbers set = EnumSet.of(Numbers.Two, Numbers.One,
Numbers.Two, Numbers.One);
Numbers[] array = set.toArray(new Numbers[set.size()]);
assertNotNull(array);
-assertEquals(array.length, 2);
+assertEquals(2, array.length);
if (array[0] != Numbers.One array[1] != Numbers.One) {
fail(Numbers.One not found);
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5942 committed - Delete empty directory left by r5940....
Revision: 5942 Author: b...@google.com Date: Tue Aug 11 10:28:52 2009 Log: Delete empty directory left by r5940. Should have used 'git svn dcommit --rmdir' http://code.google.com/p/google-web-toolkit/source/detail?r=5942 Deleted: /trunk/user/super/com/google/gwt/user/translatable/com/google/gwt/core --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Fix non-fatal WeakMapping compile errors
LGTM http://gwt-code-reviews.appspot.com/57810 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DTO compiler optimization
There's sometimes an important difference between the kind of object model
that is appropriate to send to the client and one you'd use on the server.
That's the reason we haven't historically tried to make it easier to do
no-brainer sharing of server-side object models to the client (i.e.
because it seems likely on average there would be way too much wasted data
transferred, which would lead to slowness). Clearly, you see that issue,
too, based on your suggestion.
How well would the transient keyword or the @GwtTransient annotation
satisfy the use case you gave?
On Mon, Aug 10, 2009 at 1:10 PM, Nathan Wells nwwe...@gmail.com wrote:
I have hesitated to bring this up, since I'm relatively new to GWT,
and I would hate to waste anyone's time with explaining what is
hopefully common knowledge to me.
Specifically, I thinking about the DTO problem. I think the general
opinion about DTOs is that they are a necessary evil when working with
GWT. And let me say, they are a very minor blemish on a life-saving
framework. But, It seems to me that the problem has a more elegant
solution. I would propose that all we need to do is increase the
granularity of GWT compiler control.
For clarification, I would like to be able to tell the compiler at the
class member level (either through annotations or *.gwt.xml) what
should be client-side and what should be server-side. As an example,
compiling the following class wouldn't be a problem:
class Foo implements Serializable {
@ServerOnly
static long serialVersionUID = 325490285;
//default, of course compiles to java byte-code and js.
String bar;
@ServerOnly
void setBar(String bar) {
//a method which might reference un-emulated JRE classes
}
String getBar() {
return bar;
}
}
I hope that makes sense... that way, our the same class could be used
on server and client side. Hurray for OO!
Again, I'm sure there are some unforeseen consequences of this design,
not the least of which is the possibility that it would require
basically rebuilding the GWT compiler. I'm just hoping that this
discussion might answer other n00b questions in the future :)
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Amir, Kango, A UI like Reader is very easy to formulate (it will be a lot easier when I check in DeckLayoutPanel). If you imagine a DeckPanel where 100% height actually works properly, you would write something like this: p.add(header, NORTH); p.add(navPane, WEST); p.add(footer, SOUTH); p.add(content, CENTER); Amir's right to point out that this *doesn't* work if you don't want the layout to be 100% height (or some other fixed height, but where there's no scrollbar on the body element). But that actually already works just fine with plain old CSS or DockPanels. It's the 100% height and interior scrolling that's hard to do at present. Cheers, joel. On Mon, Aug 10, 2009 at 6:34 PM, Kango_V djb.b...@gmail.com wrote: Amir, this is the exact case I am working on. I'm trting to implement an interface not dissimilar to Google Reader. It has a footer at the bottom of the grid for next prev buttons. Can this layout handle this? Excellent work as always. I'm keenly following this. Can't get it quick enough :) On Aug 10, 9:26 am, Amir Kashani amirkash...@gmail.com wrote: Joel, I love how this is turning out so far, great work. While this system handles a vast majority of layout situations, correct me if I'm wrong, but I think it breaks down with non-100% height layouts that require a footer. An example: a header area, followed by a horizontally split content area (body and side nav), followed by a footer. I can't think of a way you could represent this using absolute positioning that would guarantee the footer area isn't encroached upon. Any thoughts on how LayoutPanel would handle this? Maybe this doesn't fall under desktop-like layouts and it's handled with floats (which aren't so terrible in this particular case)? - Amir On Mon, Aug 3, 2009 at 12:13 PM, j...@google.com wrote: Reviewers: jlabanca, Please review this athttp://gwt-code-reviews.appspot.com/51830 Affected files: A layout/Layout.gwt.xml A layout/client/Layout.java A layout/client/LayoutImpl.java A layout/client/LayoutImplIE6.java A layout/client/UserAgent.java A user/client/ui/HasAnimatedLayout.java A user/client/ui/HasLayout.java A user/client/ui/LayoutComposite.java A user/client/ui/LayoutPanel.java A user/client/ui/RootLayoutPanel.java M user/client/ui/Widget.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5943 committed - Creates infrastructure to test individual compiler passes....
Revision: 5943
Author: sco...@google.com
Date: Tue Aug 11 12:45:07 2009
Log: Creates infrastructure to test individual compiler passes.
Also started some very basic tests for ControlFlowAnalyzer,
ExpressionAnalyzer, and DeadCodeElimination.
Hopefully this will start the process of fixing broken windows and result
in more test coverage in the future. :)
Review by: spoon, cromwellian
http://code.google.com/p/google-web-toolkit/source/detail?r=5943
Added:
/trunk/dev/core/src/com/google/gwt/dev/jdt/BasicWebModeCompiler.java
/trunk/dev/core/test/com/google/gwt/dev/jjs
/trunk/dev/core/test/com/google/gwt/dev/jjs/JavaAstConstructor.java
/trunk/dev/core/test/com/google/gwt/dev/jjs/impl
/trunk/dev/core/test/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzerTest.java
/trunk/dev/core/test/com/google/gwt/dev/jjs/impl/DeadCodeEliminationTest.java
/trunk/dev/core/test/com/google/gwt/dev/jjs/impl/ExpressionAnalyzerTest.java
/trunk/dev/core/test/com/google/gwt/dev/jjs/impl/OptimizerTestBase.java
Modified:
/trunk/dev/core/src/com/google/gwt/dev/jdt/WebModeCompilerFrontEnd.java
/trunk/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
/trunk/dev/core/test/com/google/gwt/dev/javac/impl/JavaResourceBase.java
/trunk/dev/core/test/com/google/gwt/dev/javac/impl/MockJavaResource.java
/trunk/dev/core/test/com/google/gwt/dev/javac/impl/MockResourceOracle.java
===
--- /dev/null
+++ /trunk/dev/core/src/com/google/gwt/dev/jdt/BasicWebModeCompiler.java
Tue Aug 11 12:45:07 2009
@@ -0,0 +1,157 @@
+/*
+ * 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.dev.jdt;
+
+import com.google.gwt.core.ext.TreeLogger;
+import com.google.gwt.core.ext.UnableToCompleteException;
+import com.google.gwt.core.ext.typeinfo.JClassType;
+import com.google.gwt.core.ext.typeinfo.TypeOracle;
+import com.google.gwt.dev.javac.CompilationState;
+import com.google.gwt.dev.javac.CompilationUnit;
+import com.google.gwt.dev.javac.CompiledClass;
+import com.google.gwt.dev.javac.JdtCompiler.CompilationUnitAdapter;
+import com.google.gwt.dev.util.Empty;
+import com.google.gwt.dev.util.JsniRef;
+import com.google.gwt.dev.util.Memory;
+
+import org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration;
+import org.eclipse.jdt.internal.compiler.env.ICompilationUnit;
+
+import java.util.ArrayList;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+
+/**
+ * Provides a basic front-end based on the JDT compiler that incorporates
+ * GWT-specific concepts such as JSNI.
+ */
+public class BasicWebModeCompiler extends AbstractCompiler {
+
+ public static CompilationUnitDeclaration[]
getCompilationUnitDeclarations(
+ TreeLogger logger, CompilationState state, String... seedTypeNames)
+ throws UnableToCompleteException {
+return new BasicWebModeCompiler(state).getCompilationUnitDeclarations(
+logger, seedTypeNames);
+ }
+
+ /**
+ * Construct a BasicWebModeCompiler.
+ */
+ public BasicWebModeCompiler(CompilationState compilationState) {
+super(compilationState, false);
+ }
+
+ /**
+ * Build the initial set of compilation units.
+ */
+ public CompilationUnitDeclaration[] getCompilationUnitDeclarations(
+ TreeLogger logger, String[] seedTypeNames)
+ throws UnableToCompleteException {
+
+TypeOracle oracle = compilationState.getTypeOracle();
+SetJClassType intfTypes = oracle.getSingleJsoImplInterfaces();
+MapString, CompiledClass classMapBySource =
compilationState.getClassFileMapBySource();
+
+/*
+ * The alreadyAdded set prevents duplicate CompilationUnits from being
added
+ * to the icu list in the case of multiple JSO implementations as inner
+ * classes in the same top-level class or seed classes as
SingleJsoImpls
+ * (e.g. JSO itself as the SingleImpl for all tag interfaces).
+ */
+SetCompilationUnit alreadyAdded = new HashSetCompilationUnit();
+
+ListICompilationUnit icus = new ArrayListICompilationUnit(
+seedTypeNames.length + intfTypes.size());
+
+for (String seedTypeName : seedTypeNames) {
+ CompilationUnit unit = getUnitForType(logger, classMapBySource,
+ seedTypeName);
+
+ if (alreadyAdded.add(unit)) {
+icus.add(new CompilationUnitAdapter(unit));
+ } else {
+logger.log(TreeLogger.WARN, Duplicate
[gwt-contrib] [google-web-toolkit] r5944 committed - Removes javax/servlet/*.java source files from gwt-user.jar....
Revision: 5944
Author: sco...@google.com
Date: Tue Aug 11 12:50:31 2009
Log: Removes javax/servlet/*.java source files from gwt-user.jar.
By popular demand, we're removing these source files from gwt-user.jar
because Maven chokes on them and tries to recompile them.
Issue: 3851
Review by: bobv
http://code.google.com/p/google-web-toolkit/source/detail?r=5944
Modified:
/trunk/user/build.xml
===
--- /trunk/user/build.xml Fri Aug 7 15:52:15 2009
+++ /trunk/user/build.xml Tue Aug 11 12:50:31 2009
@@ -86,7 +86,7 @@
fileset dir=src excludes=**/package.html /
fileset dir=super excludes=**/package.html /
fileset dir=${javac.out} /
- zipfileset src=${gwt.tools.lib}/tomcat/servlet-api-2.5.jar /
+ zipfileset src=${gwt.tools.lib}/tomcat/servlet-api-2.5.jar
excludes=**/*.java/
zipfileset src=${gwt.tools.lib}/w3c/sac/sac-1.3.jar /
zipfileset src=${gwt.tools.lib}/w3c/flute/flute-1.3.jar /
/gwt.jar
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: DTO compiler optimization
There's sometimes an important difference between the kind of object model
that is appropriate to send to the client and one you'd use on the server.
I absolutely agree with you here. And if I fully understand the
current reasoning, DTO creation is a way of forcing developers to
include as little as possible in their transfers. However, as I'm sure
you'll agree, this also introduces a pain point. Namely, I've got a
lot of code that I can't reuse. Not only that, but it introduces
latency in mapping while I instantiate a new object and then transfer
all necessary fields (only to have GWT then serialize them). This
latency grows with the number of fields I transfer, thus at least
partially mitigating the benefit of forcing me to decide if I REALLY
needed all those fields there to begin with.
So, as it stands, I have taken time to (1) decide that I actually need
the entire object on the client side (which I really already knew
because I was creating it on the server side specifically to send it
to the client side) (2) create the DTO, and (3) do the mapping, as
well as the per-request latency. The latency, I admit, is probably
insignificant in most cases, but it's still unnecessary CPU and memory
usage, IF we can assume that the developer has a reasonable
understanding of optimizing their application. I think there are even
ways around making that assumption.
I believe (admittedly, this is simply my case) that DTOs usually end
up being JavaBeans with no logic and a subset of fields. If that's all
they are, then why can't I throw some instructions at the compiler to
say Compile and create a serializer for this class to javascript,
excluding everything except these methods and these fields. This way,
the default action is less sent to the client. In addition, since
these classes won't typically be part of a client package, you could
have some special *.gwt.xml tag to specify transfer objects that
would be very hard to stumble upon and use without understanding the
benefit of optimizing data transfer.
My primary concern with this thread is ease of maintaining software,
without, of course, sacrificing user experience in any way.
How well would the transient keyword or the @GwtTransient annotation
satisfy the use case you gave?
The transient keyword and annotation work well, but don't allow me
to compile classes that have server-side logic in them. If I so much
as throw a ParseException, whoops, sorry, no usage on the client
side :)
I apologize if any of this seems a little dry or caustic. I really do
appreciate all the work you guys do, and know your interests lie in
making responsive web applications possible. I only bring this up
because it is really the only thing that prevents me from telling
everyone and their cousin to use GWT for everything they do.
On Aug 11, 11:57 am, Bruce Johnson br...@google.com wrote:
There's sometimes an important difference between the kind of object model
that is appropriate to send to the client and one you'd use on the server.
That's the reason we haven't historically tried to make it easier to do
no-brainer sharing of server-side object models to the client (i.e.
because it seems likely on average there would be way too much wasted data
transferred, which would lead to slowness). Clearly, you see that issue,
too, based on your suggestion.
How well would the transient keyword or the @GwtTransient annotation
satisfy the use case you gave?
On Mon, Aug 10, 2009 at 1:10 PM, Nathan Wells nwwe...@gmail.com wrote:
I have hesitated to bring this up, since I'm relatively new to GWT,
and I would hate to waste anyone's time with explaining what is
hopefully common knowledge to me.
Specifically, I thinking about the DTO problem. I think the general
opinion about DTOs is that they are a necessary evil when working with
GWT. And let me say, they are a very minor blemish on a life-saving
framework. But, It seems to me that the problem has a more elegant
solution. I would propose that all we need to do is increase the
granularity of GWT compiler control.
For clarification, I would like to be able to tell the compiler at the
class member level (either through annotations or *.gwt.xml) what
should be client-side and what should be server-side. As an example,
compiling the following class wouldn't be a problem:
class Foo implements Serializable {
�...@serveronly
static long serialVersionUID = 325490285;
//default, of course compiles to java byte-code and js.
String bar;
�...@serveronly
void setBar(String bar) {
//a method which might reference un-emulated JRE classes
}
String getBar() {
return bar;
}
}
I hope that makes sense... that way, our the same class could be used
on server and client side. Hurray for OO!
Again, I'm sure there are some unforeseen consequences of this design,
not the least of which is the possibility that it would require
basically rebuilding the GWT compiler. I'm
[gwt-contrib] Re: DTO compiler optimization
Nathan,
To some extent you can make this happen by wrapping your method
implementations with GWT.isScript() or GWT.isClient() calls as appropriate.
Another approach is to use super-src so that you in fact have two
implementations of your class, one for the client, one for the server.
I realize neither quite hits the sweet spot you're looking for, but may help
you in a pragmatic sense.
Fred
On Mon, Aug 10, 2009 at 10:10 AM, Nathan Wells nwwe...@gmail.com wrote:
I have hesitated to bring this up, since I'm relatively new to GWT,
and I would hate to waste anyone's time with explaining what is
hopefully common knowledge to me.
Specifically, I thinking about the DTO problem. I think the general
opinion about DTOs is that they are a necessary evil when working with
GWT. And let me say, they are a very minor blemish on a life-saving
framework. But, It seems to me that the problem has a more elegant
solution. I would propose that all we need to do is increase the
granularity of GWT compiler control.
For clarification, I would like to be able to tell the compiler at the
class member level (either through annotations or *.gwt.xml) what
should be client-side and what should be server-side. As an example,
compiling the following class wouldn't be a problem:
class Foo implements Serializable {
@ServerOnly
static long serialVersionUID = 325490285;
//default, of course compiles to java byte-code and js.
String bar;
@ServerOnly
void setBar(String bar) {
//a method which might reference un-emulated JRE classes
}
String getBar() {
return bar;
}
}
I hope that makes sense... that way, our the same class could be used
on server and client side. Hurray for OO!
Again, I'm sure there are some unforeseen consequences of this design,
not the least of which is the possibility that it would require
basically rebuilding the GWT compiler. I'm just hoping that this
discussion might answer other n00b questions in the future :)
--
Fred Sauer
Developer Advocate
Google Inc. 1600 Amphitheatre Parkway
Mountain View, CA 94043
fre...@google.com
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: How to enable web mode debugging in GWT
gwt-log will print those stack traces for you. To get the most out of it
you'll want to use GWT trunk and gwt-log trunk.
To get started:
http://code.google.com/p/gwt-log/wiki/GettingStarted
In particular, make sure you:
inherits name=com.google.gwt.core.EmulateJsStack/
set-configuration-property
name=compiler.emulatedStack.recordLineNumbers value=true/
set-configuration-property
name=compiler.emulatedStack.recordFileNames value=true/
And use the deferred command pattern to capture initialization exceptions:
public void onModuleLoad() {
Log.setUncaughtExceptionHandler();
DeferredCommand.addCommand(new Command() {
public void execute() {
onModuleLoad2();
}
});
}
private void onModuleLoad2() {
// Your client code goes here
}
HTH
Fred
On Mon, Aug 10, 2009 at 1:36 AM, Joy goswami@gmail.com wrote:
Hi All,
I can see hosted mode debug message in eclipse console. When I compile
and run mt application in IE I get some javascipt error messages. But
I am uanble to debug because I am not getting the culprit java file
which might have caused the error.
So I want to know how to enable web mode debugging, so that i can see
the java stack trace in eclipse console, while running the application
in IE.
Thanks in advance.
--
Fred Sauer
Developer Advocate
Google Inc. 1600 Amphitheatre Parkway
Mountain View, CA 94043
fre...@google.com
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Set cache headers properly in embedded Jetty for hosted mode
Does this address issue 3682? http://code.google.com/p/google-web-toolkit/issues/detail?id=3682 http://gwt-code-reviews.appspot.com/56807 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DTO compiler optimization
Fred,
If I understand you correctly, if I have a method
void doFoo() {
if (!(GWT.isClient() || GWT.isScript())){
//do server-side stuff with breaking JRE references
}
}//doFoo
... the compiler will ignore everything after the conditional. Is that
accurate?
On Aug 11, 2:13 pm, Fred Sauer fre...@google.com wrote:
Nathan,
To some extent you can make this happen by wrapping your method
implementations with GWT.isScript() or GWT.isClient() calls as appropriate.
Another approach is to use super-src so that you in fact have two
implementations of your class, one for the client, one for the server.
I realize neither quite hits the sweet spot you're looking for, but may help
you in a pragmatic sense.
Fred
On Mon, Aug 10, 2009 at 10:10 AM, Nathan Wells nwwe...@gmail.com wrote:
I have hesitated to bring this up, since I'm relatively new to GWT,
and I would hate to waste anyone's time with explaining what is
hopefully common knowledge to me.
Specifically, I thinking about the DTO problem. I think the general
opinion about DTOs is that they are a necessary evil when working with
GWT. And let me say, they are a very minor blemish on a life-saving
framework. But, It seems to me that the problem has a more elegant
solution. I would propose that all we need to do is increase the
granularity of GWT compiler control.
For clarification, I would like to be able to tell the compiler at the
class member level (either through annotations or *.gwt.xml) what
should be client-side and what should be server-side. As an example,
compiling the following class wouldn't be a problem:
class Foo implements Serializable {
�...@serveronly
static long serialVersionUID = 325490285;
//default, of course compiles to java byte-code and js.
String bar;
�...@serveronly
void setBar(String bar) {
//a method which might reference un-emulated JRE classes
}
String getBar() {
return bar;
}
}
I hope that makes sense... that way, our the same class could be used
on server and client side. Hurray for OO!
Again, I'm sure there are some unforeseen consequences of this design,
not the least of which is the possibility that it would require
basically rebuilding the GWT compiler. I'm just hoping that this
discussion might answer other n00b questions in the future :)
--
Fred Sauer
Developer Advocate
Google Inc. 1600 Amphitheatre Parkway
Mountain View, CA 94043
fre...@google.com
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: DTO compiler optimization
Also, I don't know much about super-src. Can you point me to some
documentation about that? Everything I've read says do X and this
will happen I would like to have an understanding (superficial as my
understanding is probably going to be) of what going on under the
hood so that I know better when to apply it and when not to.
On Aug 11, 2:13 pm, Fred Sauer fre...@google.com wrote:
Nathan,
To some extent you can make this happen by wrapping your method
implementations with GWT.isScript() or GWT.isClient() calls as appropriate.
Another approach is to use super-src so that you in fact have two
implementations of your class, one for the client, one for the server.
I realize neither quite hits the sweet spot you're looking for, but may help
you in a pragmatic sense.
Fred
On Mon, Aug 10, 2009 at 10:10 AM, Nathan Wells nwwe...@gmail.com wrote:
I have hesitated to bring this up, since I'm relatively new to GWT,
and I would hate to waste anyone's time with explaining what is
hopefully common knowledge to me.
Specifically, I thinking about the DTO problem. I think the general
opinion about DTOs is that they are a necessary evil when working with
GWT. And let me say, they are a very minor blemish on a life-saving
framework. But, It seems to me that the problem has a more elegant
solution. I would propose that all we need to do is increase the
granularity of GWT compiler control.
For clarification, I would like to be able to tell the compiler at the
class member level (either through annotations or *.gwt.xml) what
should be client-side and what should be server-side. As an example,
compiling the following class wouldn't be a problem:
class Foo implements Serializable {
�...@serveronly
static long serialVersionUID = 325490285;
//default, of course compiles to java byte-code and js.
String bar;
�...@serveronly
void setBar(String bar) {
//a method which might reference un-emulated JRE classes
}
String getBar() {
return bar;
}
}
I hope that makes sense... that way, our the same class could be used
on server and client side. Hurray for OO!
Again, I'm sure there are some unforeseen consequences of this design,
not the least of which is the possibility that it would require
basically rebuilding the GWT compiler. I'm just hoping that this
discussion might answer other n00b questions in the future :)
--
Fred Sauer
Developer Advocate
Google Inc. 1600 Amphitheatre Parkway
Mountain View, CA 94043
fre...@google.com
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
You mean DockLayoutPanel, right? Anyway, makes perfect sense. The true challenge has always been with the 100% height desktop-app style layouts, which the new stuff will handle beautifully. Thanks. - Amir On Tue, Aug 11, 2009 at 12:38 PM, Joel Webber j...@google.com wrote: Amir, Kango, A UI like Reader is very easy to formulate (it will be a lot easier when I check in DeckLayoutPanel). If you imagine a DeckPanel where 100% height actually works properly, you would write something like this: p.add(header, NORTH); p.add(navPane, WEST); p.add(footer, SOUTH); p.add(content, CENTER); Amir's right to point out that this *doesn't* work if you don't want the layout to be 100% height (or some other fixed height, but where there's no scrollbar on the body element). But that actually already works just fine with plain old CSS or DockPanels. It's the 100% height and interior scrolling that's hard to do at present. Cheers, joel. On Mon, Aug 10, 2009 at 6:34 PM, Kango_V djb.b...@gmail.com wrote: Amir, this is the exact case I am working on. I'm trting to implement an interface not dissimilar to Google Reader. It has a footer at the bottom of the grid for next prev buttons. Can this layout handle this? Excellent work as always. I'm keenly following this. Can't get it quick enough :) On Aug 10, 9:26 am, Amir Kashani amirkash...@gmail.com wrote: Joel, I love how this is turning out so far, great work. While this system handles a vast majority of layout situations, correct me if I'm wrong, but I think it breaks down with non-100% height layouts that require a footer. An example: a header area, followed by a horizontally split content area (body and side nav), followed by a footer. I can't think of a way you could represent this using absolute positioning that would guarantee the footer area isn't encroached upon. Any thoughts on how LayoutPanel would handle this? Maybe this doesn't fall under desktop-like layouts and it's handled with floats (which aren't so terrible in this particular case)? - Amir On Mon, Aug 3, 2009 at 12:13 PM, j...@google.com wrote: Reviewers: jlabanca, Please review this athttp://gwt-code-reviews.appspot.com/51830 Affected files: A layout/Layout.gwt.xml A layout/client/Layout.java A layout/client/LayoutImpl.java A layout/client/LayoutImplIE6.java A layout/client/UserAgent.java A user/client/ui/HasAnimatedLayout.java A user/client/ui/HasLayout.java A user/client/ui/LayoutComposite.java A user/client/ui/LayoutPanel.java A user/client/ui/RootLayoutPanel.java M user/client/ui/Widget.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: add names to runAsync calls
Hi Lex,
I reviewed everything except CodeSplitter. I looked at it briefly, but
that class is fairly unfamiliar to me. Maybe Kathrin or Bob is a better
choice?
http://gwt-code-reviews.appspot.com/56814/diff/1/10
File dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
(right):
http://gwt-code-reviews.appspot.com/56814/diff/1/10#newcode107
Line 107: assert (x.getArgs().size() == 1 || x.getArgs().size() == 2);
This code might be a little more readable as a switch statement, and you
won't need the last() method; just throw an ICE on the default case.
http://gwt-code-reviews.appspot.com/56814/diff/1/5
File dev/core/test/com/google/gwt/dev/javac/RunAsyncNameTest.java
(right):
http://gwt-code-reviews.appspot.com/56814/diff/1/5#newcode37
Line 37: makeComGoogleGwtCoreClientGwt();
Leftover from a time when that method had side effects?
http://gwt-code-reviews.appspot.com/56814/diff/1/5#newcode59
Line 59: return makeCompilationUnit(com.google.gwt.core.client.GWT,
code);
Can't you just use new MockCompilationUnit here as per line 89?
http://gwt-code-reviews.appspot.com/56814/diff/1/7
File dev/core/test/com/google/gwt/dev/javac/TypeOracleTestingUtils.java
(right):
http://gwt-code-reviews.appspot.com/56814/diff/1/7#newcode70
Line 70: // run FindDeferredBindingSitesVisitor because it detects
errors, too
This raises a flag for me since this is part of web mode compilation..
it's not part of TypeOracle build or testing it.
Maybe you want to use the new compiler test infrastructure I just
committed? I think that would do exactly what you want. It also
includes a basic definition of the GWT compilation unit (with create())
and you could add your runAsync decls to that.
http://gwt-code-reviews.appspot.com/56814/diff/1/6
File dev/core/test/com/google/gwt/dev/javac/impl/JavaResourceBase.java
(right):
http://gwt-code-reviews.appspot.com/56814/diff/1/6#newcode96
Line 96: code.append( public Class? getClass() { return null; }\n);
I checked in a conflict to this line. My version returns Object.class..
will that work for you?
http://gwt-code-reviews.appspot.com/56814/diff/1/4
File user/src/com/google/gwt/core/client/GWT.java (right):
http://gwt-code-reviews.appspot.com/56814/diff/1/4#newcode211
Line 211: public static void runAsync(Class? name, RunAsyncCallback
callback) {
The fundamental question I have is why this is a class name instead of a
string literal? If it's literally just an arbitrary string identifier,
it seems misleading to attach a class to it.
http://gwt-code-reviews.appspot.com/56814
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Set cache headers properly in embedded Jetty for hosted mode
I think so, I reassigned that bug to jat for that reason. On Tue, Aug 11, 2009 at 4:27 PM, fre...@gmail.com wrote: Does this address issue 3682? http://code.google.com/p/google-web-toolkit/issues/detail?id=3682 http://gwt-code-reviews.appspot.com/56807 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Set cache headers properly in embedded Jetty for hosted mode
Adding potential second eyeball reviewers. http://gwt-code-reviews.appspot.com/56807 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: add names to runAsync calls
On Tue, Aug 11, 2009 at 5:05 PM, sco...@google.com wrote:
Hi Lex,
I reviewed everything except CodeSplitter. I looked at it briefly, but
that class is fairly unfamiliar to me. Maybe Kathrin or Bob is a better
choice?
Both of them already have reviews for me (or soon will). It's not
really a code splitter change, but new code to associate names with
AST nodes (in ReplaceRunAsync). CodeSplitter then looks up the names
as recorded. I was really wondering what you'd think is good style
for this sort of thing.
On little issues:
http://gwt-code-reviews.appspot.com/56814/diff/1/7#newcode70
Line 70: // run FindDeferredBindingSitesVisitor because it detects
errors, too
This raises a flag for me since this is part of web mode compilation..
it's not part of TypeOracle build or testing it.
Maybe you want to use the new compiler test infrastructure I just
committed? I think that would do exactly what you want. It also
includes a basic definition of the GWT compilation unit (with create())
and you could add your runAsync decls to that.
Sure, I can do that.
http://gwt-code-reviews.appspot.com/56814/diff/1/6#newcode96
Line 96: code.append( public Class? getClass() { return null; }\n);
I checked in a conflict to this line. My version returns Object.class..
will that work for you?
Yeah, I saw. That version is also fine.
http://gwt-code-reviews.appspot.com/56814/diff/1/4
File user/src/com/google/gwt/core/client/GWT.java (right):
http://gwt-code-reviews.appspot.com/56814/diff/1/4#newcode211
Line 211: public static void runAsync(Class? name, RunAsyncCallback
callback) {
The fundamental question I have is why this is a class name instead of a
string literal? If it's literally just an arbitrary string identifier,
it seems misleading to attach a class to it.
http://gwt-code-reviews.appspot.com/56814
I should have dug up the thread that discussed the design of this
naming scheme. Here it is:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/99751ee4ccd02d06/2ecbc72988b91a5b
It was a long discussion, and this is the scheme that came out of it.
I initially pushed for strings, myself, because they are simple and
they are enough for applications. Looking forward, though, libraries
might include runAsync calls, in which case class literals have some
advantages:
1. They reuse the global Java package hierarchy, so it's hard for two
libraries to use the same name by accident.
2. Despite being in a global hierarchy--and thus long--you can use
Java imports to shorten them back up.
3. They can have Javadoc attached.
4. They can have other annotations attached, if we ever come up with a
need to attach more information to a split point.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Joel, is there a way to get the widget's default width/height? Maybe I do something wrong, but this code layer.setTopHeight(0, Unit.PX, north.getOffsetHeight(), Unit.PX); does not work, returned height is too small. Thanks, George. On Aug 11, 10:38 pm, Joel Webber j...@google.com wrote: Amir, Kango, A UI like Reader is very easy to formulate (it will be a lot easier when I check in DeckLayoutPanel). If you imagine a DeckPanel where 100% height actually works properly, you would write something like this: p.add(header, NORTH); p.add(navPane, WEST); p.add(footer, SOUTH); p.add(content, CENTER); Amir's right to point out that this *doesn't* work if you don't want the layout to be 100% height (or some other fixed height, but where there's no scrollbar on the body element). But that actually already works just fine with plain old CSS or DockPanels. It's the 100% height and interior scrolling that's hard to do at present. Cheers, joel. On Mon, Aug 10, 2009 at 6:34 PM, Kango_V djb.b...@gmail.com wrote: Amir, this is the exact case I am working on. I'm trting to implement an interface not dissimilar to Google Reader. It has a footer at the bottom of the grid for next prev buttons. Can this layout handle this? Excellent work as always. I'm keenly following this. Can't get it quick enough :) On Aug 10, 9:26 am, Amir Kashani amirkash...@gmail.com wrote: Joel, I love how this is turning out so far, great work. While this system handles a vast majority of layout situations, correct me if I'm wrong, but I think it breaks down with non-100% height layouts that require a footer. An example: a header area, followed by a horizontally split content area (body and side nav), followed by a footer. I can't think of a way you could represent this using absolute positioning that would guarantee the footer area isn't encroached upon. Any thoughts on how LayoutPanel would handle this? Maybe this doesn't fall under desktop-like layouts and it's handled with floats (which aren't so terrible in this particular case)? - Amir On Mon, Aug 3, 2009 at 12:13 PM, j...@google.com wrote: Reviewers: jlabanca, Please review this athttp://gwt-code-reviews.appspot.com/51830 Affected files: A layout/Layout.gwt.xml A layout/client/Layout.java A layout/client/LayoutImpl.java A layout/client/LayoutImplIE6.java A layout/client/UserAgent.java A user/client/ui/HasAnimatedLayout.java A user/client/ui/HasLayout.java A user/client/ui/LayoutComposite.java A user/client/ui/LayoutPanel.java A user/client/ui/RootLayoutPanel.java M user/client/ui/Widget.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Invalid version number 2.0 passed to external.gwtOnLoad()
When switching GWT versions on my project I get this error (when I'm lucky): *[ERROR] Invalid version number 2.0 passed to external.gwtOnLoad(), expected 1.6; your hosted mode bootstrap file may be out of date; if you are using -noserver try recompiling and redeploying your app* However, if I'm switching within a given version of GWT (say because I'm working off of trunk and updating or rolling back) I may in fact have incorrect contents in hosted.html but a correct version. This means the above error message is never thrown, but hosted mode is unexplainably broken. Should this be an issue? It would be great if GWT checked the contents of hosted.html and replaced the file if needed. Thoughts? -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Invalid version number 2.0 passed to external.gwtOnLoad()
On Tue, Aug 11, 2009 at 7:50 PM, Fred Sauer fre...@google.com wrote: When switching GWT versions on my project I get this error (when I'm lucky): *[ERROR] Invalid version number 2.0 passed to external.gwtOnLoad(), expected 1.6; your hosted mode bootstrap file may be out of date; if you are using -noserver try recompiling and redeploying your app* However, if I'm switching within a given version of GWT (say because I'm working off of trunk and updating or rolling back) I may in fact have incorrect contents in hosted.html but a correct version. This means the above error message is never thrown, but hosted mode is unexplainably broken. Should this be an issue? It would be great if GWT checked the contents of hosted.html and replaced the file if needed. I'm not sure I understand the issue. If you have different versions of hosted.html and GWT, things are likely to not work and that is why that check was added in 1.6. I don't see how you could have the incorrect contents of hosted.html but the correct version, unless you update/rollback parts of GWT separately, in which case you are already likely to break things if you don't know what you are doing. In the -noserver case, GWT never sees the hosted.html your web server serves, and the version number is passed to the plugin from hosted.html (or gwt.external in legacy hosted mode) -- it could conceivably do an XHR for hosted.html and send the entire contents (or a hash) rather than just the version number, but that seems overkill as I don't see a reasonable way the version number contained in the hosted.html file will get out of sync with the rest of the hosted.html file. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Issue 3903 (cont'd) Add noscript tag to existing HTML pages
Reviewers: Ray Ryan, Description: The .htmlsrc template was updated in http://gwt-code-reviews.appspot.com/51825 This review updates existing examples as well Please review this at http://gwt-code-reviews.appspot.com/57812 Affected files: eclipse/reference/code-museum/war/DefaultMuseum.html eclipse/reference/code-museum/war/SingleIssue.html samples/dynatable/war/DynaTable.html samples/hello/war/Hello.html samples/i18n/war/I18N.html samples/json/war/JSON.html samples/mail/war/Mail.html samples/showcase/war/Showcase.html samples/simplerpc/war/SimpleRPC.html samples/simplexml/war/SimpleXML.html --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Invalid version number 2.0 passed to external.gwtOnLoad()
On Tue, Aug 11, 2009 at 5:14 PM, John Tamplin j...@google.com wrote: On Tue, Aug 11, 2009 at 7:50 PM, Fred Sauer fre...@google.com wrote: When switching GWT versions on my project I get this error (when I'm lucky): *[ERROR] Invalid version number 2.0 passed to external.gwtOnLoad(), expected 1.6; your hosted mode bootstrap file may be out of date; if you are using -noserver try recompiling and redeploying your app* However, if I'm switching within a given version of GWT (say because I'm working off of trunk and updating or rolling back) I may in fact have incorrect contents in hosted.html but a correct version. This means the above error message is never thrown, but hosted mode is unexplainably broken. Should this be an issue? It would be great if GWT checked the contents of hosted.html and replaced the file if needed. I'm not sure I understand the issue. If you have different versions of hosted.html and GWT, things are likely to not work and that is why that check was added in 1.6. I don't see how you could have the incorrect contents of hosted.html but the correct version, unless you update/rollback parts of GWT separately, in which case you are already likely to break things if you don't know what you are doing. Yep, that's exactly the scenario :). Knowing that you have to watch out for this stuff is one thing. Being bit by it every now and again and going down a rabbit hole, is (mildly) annoying. Not a huge deal as this affect contributors only, but could be a good sanity check to save time down the road. Thanks Fred In the -noserver case, GWT never sees the hosted.html your web server serves, and the version number is passed to the plugin from hosted.html (or gwt.external in legacy hosted mode) -- it could conceivably do an XHR for hosted.html and send the entire contents (or a hash) rather than just the version number, but that seems overkill as I don't see a reasonable way the version number contained in the hosted.html file will get out of sync with the rest of the hosted.html file. -- John A. Tamplin Software Engineer (GWT), Google -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5945 committed - Correct misleading statement regarding plural forms reference....
Revision: 5945 Author: j...@google.com Date: Tue Aug 11 17:03:44 2009 Log: Correct misleading statement regarding plural forms reference. Patch by: rebeccaward Review by: abowers, bruce, jat http://code.google.com/p/google-web-toolkit/source/detail?r=5945 Modified: /trunk/user/src/com/google/gwt/i18n/client/impl/plurals/DefaultRule.java === --- /trunk/user/src/com/google/gwt/i18n/client/impl/plurals/DefaultRule.java Mon Mar 17 16:50:16 2008 +++ /trunk/user/src/com/google/gwt/i18n/client/impl/plurals/DefaultRule.java Tue Aug 11 17:03:44 2009 @@ -32,8 +32,8 @@ * DefaultRule_en_uk for English spoken in the UK (note the lower-cased * tag). * - * Many of the rules implemented in subclasses of this class are from: - * http://translate.sourceforge.net/wiki/l10n/pluralforms + * This is an implementation of the language pluralization rules described + * at http://translate.sourceforge.net/wiki/l10n/pluralforms * * Eventually, all these rules will be machine generated from Unicode's * CLDR, perhaps with some additional data that isn't kept there if --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Invalid version number 2.0 passed to external.gwtOnLoad()
On Tue, Aug 11, 2009 at 8:22 PM, Fred Sauer fre...@google.com wrote: I'm not sure I understand the issue. If you have different versions of hosted.html and GWT, things are likely to not work and that is why that check was added in 1.6. I don't see how you could have the incorrect contents of hosted.html but the correct version, unless you update/rollback parts of GWT separately, in which case you are already likely to break things if you don't know what you are doing. Yep, that's exactly the scenario :). Knowing that you have to watch out for this stuff is one thing. Being bit by it every now and again and going down a rabbit hole, is (mildly) annoying. Not a huge deal as this affect contributors only, but could be a good sanity check to save time down the road. There are so many ways you can screw things up by mixing different versions of parts of GWT, I don't see how this is any different. For example, if you rollback an old TypeOracleMediator but don't roll back related TypeOracle changes, things are going to break horribly. I think trying to add code inside GWT to detect such situations is counterproductive and unlikely to be effective anyway. I would hope that anyone knows building a version of GWT that is not at a consistent revision across the board means they better know exactly what they are doing or they will get weird breakages. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DTO compiler optimization
I agree the problem is begging out for a more elegant solution. From the Google IO presentation on Google Wave powered by GWT a solution using proto buffer and JSON instead of GWT RPC is mentioned. I've been thinking that a similar result could be achieved annotation the server side object model with annotation (e.g. jsonmarshaller http://code.google.com/p/jsonmarshaller/) and the generating the client side JavaScriptObject code using an annotation processor. Thoughts? Gary --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: add names to runAsync calls
On Tue, Aug 11, 2009 at 6:29 PM, Lex Spoon sp...@google.com wrote: Both of them already have reviews for me (or soon will). It's not really a code splitter change, but new code to associate names with AST nodes (in ReplaceRunAsync). CodeSplitter then looks up the names as recorded. I was really wondering what you'd think is good style for this sort of thing. Okay, I'll go back and take another look. The fundamental question I have is why this is a class name instead of a string literal? If it's literally just an arbitrary string identifier, it seems misleading to attach a class to it. http://gwt-code-reviews.appspot.com/56814 I should have dug up the thread that discussed the design of this naming scheme. Here it is: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/99751ee4ccd02d06/2ecbc72988b91a5b It was a long discussion, and this is the scheme that came out of it. I initially pushed for strings, myself, because they are simple and they are enough for applications. Looking forward, though, libraries might include runAsync calls, in which case class literals have some advantages: 1. They reuse the global Java package hierarchy, so it's hard for two libraries to use the same name by accident. 2. Despite being in a global hierarchy--and thus long--you can use Java imports to shorten them back up. 3. They can have Javadoc attached. 4. They can have other annotations attached, if we ever come up with a need to attach more information to a split point. That makes perfect sense, I could imagine using annotations to give the compiler hints about how to split your code. Not that I would want to second-guess that design discussion anyway. I mainly just wanted to know what the reasons were. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5946 committed - HtmlUnit should release its resources when the webClient reference is ...
Revision: 5946
Author: amitman...@google.com
Date: Tue Aug 11 18:19:35 2009
Log: HtmlUnit should release its resources when the webClient reference is
no longer held.
Patch by: amitmanjhi
Review by: kprobst (TBR)
http://code.google.com/p/google-web-toolkit/source/detail?r=5946
Modified:
/trunk/user/src/com/google/gwt/junit/RunStyleHtmlUnit.java
===
--- /trunk/user/src/com/google/gwt/junit/RunStyleHtmlUnit.java Thu Jul 30
13:47:31 2009
+++ /trunk/user/src/com/google/gwt/junit/RunStyleHtmlUnit.java Tue Aug 11
18:19:35 2009
@@ -97,14 +97,13 @@
+ ((HtmlPage) page).asXml());
} catch (FailingHttpStatusCodeException e) {
treeLogger.log(TreeLogger.ERROR, HTTP request failed, e);
-return;
} catch (MalformedURLException e) {
treeLogger.log(TreeLogger.ERROR, Bad URL, e);
-return;
} catch (IOException e) {
treeLogger.log(TreeLogger.ERROR, I/O error on HTTP request, e);
-return;
- }
+ }
+ webClient.closeAllWindows();
+ return;
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder first impressions
Sounds great. Is there enough information in the classes for new GEP functionality or is extra information in going to need to be provided. Eg. the capabilities of the com.google.gwt.uibinder.parsers classes. There might be an opportunity to solve the custom widget parsing issue and the GEP auto complete etc. with the introduction of widget annotations. Thanks Gary On Aug 11, 11:50 pm, Jason Parekh jasonpar...@gmail.com wrote: Hey Gary, I can't speak more generally about GWT, but can give you some info on the plugin. We'll need more than just an XML schema (though we'll still have a simple schema defining the legal top-level elements, for example). The autocomplete choices will be too dynamic to be included in a schema. For example, when opening a tag, we'll offer autocomplete choices for each UiBinder widget in your code base. We could generate an XSD from this information, but it may not be worthwhile adding that extra step. Thanks, jason On Mon, Aug 10, 2009 at 9:43 PM, Gary Miller miller.ga...@gmail.com wrote: I'd like to start off by saying a big THANKS. We've been hanging out for this, and it is making a great first impression. In regards to GEP, validation, code completion etc. Would it be possible to use a xml schema per name space? My XSD skills aren't to the point where I would know if this is even viable. If this is a Buddha nature question, then please let me unask it. Could the need to custom parsers be solved by the same mechanism as the GEP support? Again with some meta data for widgets or widget packages. e.g. XSD per package or an UiBinder Widget Annotations. Are more custom parsers being written for the GWT UI components? Or is this the set until the public parsing interface is nailed down? As an example I tried to use visibleItemCount on ListBox go an exception class ListBox has no appropriate setVisibleItemCount() method. This is easy enough to work around by place the setVisibleItemCount all in the java code. Would it make any sense for @UiField to be applied to a setter/getter method. It might then be possible to code an interface that is bound to the ui and allow different implementions. e.g. a common dialog interface. Regards Gary Miller On Aug 11, 12:08 am, Miguel Méndez mmen...@google.com wrote: On Mon, Aug 10, 2009 at 9:59 AM, Arthur Kalmenson arthur.k...@gmail.com wrote: Hello everyone, We've been playing with UiBinder and I thought it'd be a good idea to share what we've seen so far (and ask some questions). Some of the apps we write are used by more then one hospital and this requires a tailored UI depending on the user's preferences and to store additional information that a particular hospital needs to keep track of. At the moment, writing UI in a swing style, we program to interfaces and use GIN to bind everything together. Using different AbstractGinModules and Ginjectors, we can tie the application together in different ways using different UI implementations. What would be the way to do this with UiBinder? From what we could tell, one would use UiTemplate, but there doesn't seem to be a way to configure the String in UiTemplate easily through a GIN module. Are there alternatives? Following the programming to interfaces theme, we've been doing that with UiBinder, but have run into an issue when trying to build a larger UI page out of smaller ui.xml classes. It seems that referring to interfaces in ui.xml doesn't work, so you need to work with direct concrete classes. But this would force you to use a particular implementation when we'd like to keep it generic. Lastly, I guess this is something just for consideration for the future, but having the GEP work with UiBinder would make using it a lot easier. For example, having code completion, refactoring support and error messages right in Eclipse. This would be something like the Spring IDE plugin that one you configure Spring XML files with all the above features. We have started looking at how the GPE could support UiBinder. Of course, validation with markers and quick fixes, refactoring, etc are all part of it. Thanks again for the UiBinder, we'll definitely have to spend more time with it. Best regards, -- Arthur Kalmenson -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DTO compiler optimization
Gary, I'm really much more concerned about the API itself, rather than the implementation details. That being said, I like the look of json marshaller. On Aug 11, 7:01 pm, Gary Miller miller.ga...@gmail.com wrote: I agree the problem is begging out for a more elegant solution. From the Google IO presentation on Google Wave powered by GWT a solution using proto buffer and JSON instead of GWT RPC is mentioned. I've been thinking that a similar result could be achieved annotation the server side object model with annotation (e.g. jsonmarshallerhttp://code.google.com/p/jsonmarshaller/) and the generating the client side JavaScriptObject code using an annotation processor. Thoughts? Gary --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5947 committed - Sort format SerializableTypeOracleBuilderTest.
Revision: 5947 Author: sco...@google.com Date: Tue Aug 11 19:11:51 2009 Log: Sort format SerializableTypeOracleBuilderTest. http://code.google.com/p/google-web-toolkit/source/detail?r=5947 Modified: /trunk/user/test/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilderTest.java === --- /trunk/user/test/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilderTest.java Fri Apr 17 14:15:58 2009 +++ /trunk/user/test/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilderTest.java Tue Aug 11 19:11:51 2009 @@ -1,12 +1,12 @@ /* * 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 @@ -320,7 +320,7 @@ /** * Test with a generic class whose type parameter is exposed only in certain * subclasses. - * + * * NOTE: This test has been disabled because it requires a better pruner in * STOB. See SerializableTypeOracleBuilder.pruneUnreachableTypes(). */ @@ -381,7 +381,7 @@ /** * Tests abstract root types that are field serializable. - * + * * @throws UnableToCompleteException * @throws NotFoundException */ @@ -682,7 +682,7 @@ /** * Tests the rules that govern whether a type qualifies for serialization. - * + * * @throws UnableToCompleteException * @throws NotFoundException */ @@ -810,20 +810,19 @@ // Local types should not qualify for serialization JClassType iFoo = to.getType(AutoSerializable.IFoo); problems = new ProblemReport(); -assertFalse(sob.shouldConsiderFieldsForSerialization( -iFoo.getSubtypes()[0], problems)); + assertFalse(sob.shouldConsiderFieldsForSerialization(iFoo.getSubtypes()[0], +problems)); // Static nested types qualify for serialization JClassType staticNested = to.getType(OuterClass.StaticNested); problems = new ProblemReport(); -assertTrue(sob.shouldConsiderFieldsForSerialization(staticNested, -problems)); +assertTrue(sob.shouldConsiderFieldsForSerialization(staticNested, problems)); // Non-static nested types do not qualify for serialization JClassType nonStaticNested = to.getType(OuterClass.NonStaticNested); problems = new ProblemReport(); -assertFalse(sob.shouldConsiderFieldsForSerialization( -nonStaticNested, problems)); +assertFalse(sob.shouldConsiderFieldsForSerialization(nonStaticNested, +problems)); // Abstract classes that implement Serializable should not qualify JClassType abstractSerializableClass = to.getType(AbstractSerializableClass); @@ -860,8 +859,8 @@ // Enum with subclasses should qualify, but their subtypes should not JClassType enumWithSubclasses = to.getType(EnumWithSubclasses); problems = new ProblemReport(); -assertTrue(sob.shouldConsiderFieldsForSerialization( -enumWithSubclasses, problems)); +assertTrue(sob.shouldConsiderFieldsForSerialization(enumWithSubclasses, +problems)); problems = new ProblemReport(); assertFalse(sob.shouldConsiderFieldsForSerialization( @@ -877,7 +876,7 @@ /** * Tests that both the generic and raw forms of type that has a type parameter * that erases to object are not serializable. - * + * * @throws NotFoundException */ public void testClassWithTypeParameterThatErasesToObject() @@ -902,7 +901,7 @@ /** * Test the situation where an abstract class has an unconstrained type * parameter but all of its concrete subclasses add helpful constraints to it. - * + * * @throws NotFoundException * @throws UnableToCompleteException */ @@ -1038,7 +1037,7 @@ /** * If the query type extends a raw type, be sure to pick up the parameters of * the raw subertype. - * + * * @throws UnableToCompleteException * @throws NotFoundException */ @@ -,7 +1110,7 @@ * If a subtype of a root type extends from the raw version of that root type, * then when visiting the fields of the raw version, take advantage of * information from the original root type. - * + * * @throws UnableToCompleteException * @throws NotFoundException */ @@ -1672,8 +1671,7 @@ } /** - * Tests a hierarchy blending various serializable and non-serializable - * types. + * Tests a hierarchy blending various serializable and non-serializable types. */ public void testProblemReporting() throws UnableToCompleteException,
[gwt-contrib] [google-web-toolkit] r5948 committed - Build fix: SerializableTypeOracleBuilderTest should use all the standa...
Revision: 5948
Author: sco...@google.com
Date: Tue Aug 11 19:15:27 2009
Log: Build fix: SerializableTypeOracleBuilderTest should use all the
standard units.
Also some minor related cleanup.
http://code.google.com/p/google-web-toolkit/source/detail?r=5948
Modified:
/trunk/dev/core/test/com/google/gwt/dev/javac/MockCompilationUnit.java
/trunk/dev/core/test/com/google/gwt/dev/javac/impl/JavaResourceBase.java
/trunk/user/test/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilderTest.java
===
--- /trunk/dev/core/test/com/google/gwt/dev/javac/MockCompilationUnit.java
Tue Nov 25 17:05:53 2008
+++ /trunk/dev/core/test/com/google/gwt/dev/javac/MockCompilationUnit.java
Tue Aug 11 19:15:27 2009
@@ -15,6 +15,8 @@
*/
package com.google.gwt.dev.javac;
+import com.google.gwt.dev.util.Name.BinaryName;
+
public class MockCompilationUnit extends CompilationUnit {
private final String typeName;
@@ -31,7 +33,7 @@
}
public String getDisplayLocation() {
-return /mock/ + getTypeName();
+return /mock/ + BinaryName.toInternalName(typeName) + .java;
}
@Override
===
---
/trunk/dev/core/test/com/google/gwt/dev/javac/impl/JavaResourceBase.java
Tue Aug 11 12:45:07 2009
+++
/trunk/dev/core/test/com/google/gwt/dev/javac/impl/JavaResourceBase.java
Tue Aug 11 19:15:27 2009
@@ -95,7 +95,7 @@
code.append(public class Object {\n);
code.append( public String toString() { return \Object\; }\n);
code.append( public Object clone() { return this; } );
- code.append( public Class getClass() { return Object.class; } );
+ code.append( public Class? getClass() { return Object.class;
} );
code.append(}\n);
return code;
}
===
---
/trunk/user/test/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilderTest.java
Tue Aug 11 19:11:51 2009
+++
/trunk/user/test/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilderTest.java
Tue Aug 11 19:15:27 2009
@@ -38,6 +38,7 @@
import com.google.gwt.dev.javac.TypeOracleTestingUtils;
import com.google.gwt.dev.javac.impl.JavaResourceBase;
import com.google.gwt.dev.javac.impl.SourceFileCompilationUnit;
+import com.google.gwt.dev.resource.Resource;
import com.google.gwt.dev.util.log.PrintWriterTreeLogger;
import
com.google.gwt.user.rebind.rpc.testcases.client.AbstractSerializableTypes;
import
com.google.gwt.user.rebind.rpc.testcases.client.ClassWithTypeParameterThatErasesToObject;
@@ -131,10 +132,6 @@
units.add(createMockCompilationUnit(
com.google.gwt.user.client.rpc.IsSerializable, code));
}
-
- private static void addJavaIoSerializable(SetCompilationUnit units) {
-units.add(new
SourceFileCompilationUnit(JavaResourceBase.SERIALIZABLE));
- }
private static void addJavaLangException(SetCompilationUnit units) {
StringBuffer code = new StringBuffer();
@@ -144,14 +141,6 @@
units.add(createMockCompilationUnit(java.lang.Exception, code));
}
-
- private static void addJavaLangObject(SetCompilationUnit units) {
-units.add(new SourceFileCompilationUnit(JavaResourceBase.OBJECT));
- }
-
- private static void addJavaLangString(SetCompilationUnit units) {
-units.add(new SourceFileCompilationUnit(JavaResourceBase.STRING));
- }
private static void addJavaLangThrowable(SetCompilationUnit units) {
StringBuffer code = new StringBuffer();
@@ -175,10 +164,10 @@
}
private static void addStandardClasses(SetCompilationUnit units) {
+for (Resource resource : JavaResourceBase.getStandardResources()) {
+ units.add(new SourceFileCompilationUnit(resource));
+}
addGwtTransient(units);
-addJavaIoSerializable(units);
-addJavaLangObject(units);
-addJavaLangString(units);
addJavaUtilMap(units);
addICRSE(units);
addJavaLangException(units);
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5949 committed - Make SerializableTypeOracleBuilderTest run much faster by not building...
Revision: 5949
Author: sco...@google.com
Date: Tue Aug 11 19:16:05 2009
Log: Make SerializableTypeOracleBuilderTest run much faster by not building
the same type oracle over and over.
http://code.google.com/p/google-web-toolkit/source/detail?r=5949
Modified:
/trunk/user/test/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilderTest.java
===
---
/trunk/user/test/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilderTest.java
Tue Aug 11 19:15:27 2009
+++
/trunk/user/test/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilderTest.java
Tue Aug 11 19:16:05 2009
@@ -106,6 +106,8 @@
private static final int EXPOSURE_NONE =
TypeParameterExposureComputer.EXPOSURE_NONE;
+ private static TypeOracle sTypeOracle;
+
private static void addGwtTransient(SetCompilationUnit units) {
StringBuffer code = new StringBuffer();
code.append(package com.google.gwt.user.client.rpc;\n);
@@ -250,6 +252,20 @@
sort(actual);
return actual;
}
+
+ private static TypeOracle getTestTypeOracle()
+ throws UnableToCompleteException {
+if (sTypeOracle == null) {
+ TreeLogger logger = createLogger();
+ ModuleDef moduleDef = ModuleDefLoader.createSyntheticModule(logger,
+ com.google.gwt.user.rebind.rpc.testcases.RebindRPCTestCases.JUnit,
+ new String[] {
+ com.google.gwt.user.rebind.rpc.testcases.RebindRPCTestCases,
+ com.google.gwt.junit.JUnit}, true);
+ sTypeOracle = moduleDef.getTypeOracle(logger);
+}
+return sTypeOracle;
+ }
private static String makeSourceName(String binaryName) {
return binaryName.replace('$', '.');
@@ -290,21 +306,6 @@
assertTrue(Expected: \n + toString(expected) + ,\n Actual: \n
+ toString(actual), Arrays.equals(expected, actual));
}
-
- private final ModuleDef moduleDef;
-
- private final TypeOracle typeOracle;
-
- public SerializableTypeOracleBuilderTest() throws
UnableToCompleteException {
-TreeLogger logger = createLogger();
-
-moduleDef = ModuleDefLoader.createSyntheticModule(logger,
-com.google.gwt.user.rebind.rpc.testcases.RebindRPCTestCases.JUnit,
-new String[] {
-com.google.gwt.user.rebind.rpc.testcases.RebindRPCTestCases,
-com.google.gwt.junit.JUnit}, true);
-typeOracle = moduleDef.getTypeOracle(logger);
- }
/**
* Test with a generic class whose type parameter is exposed only in
certain
@@ -872,6 +873,7 @@
throws NotFoundException, UnableToCompleteException {
TreeLogger logger = createLogger();
+TypeOracle typeOracle = getTestTypeOracle();
JRawType rawType = typeOracle.getType(
ClassWithTypeParameterThatErasesToObject.class.getCanonicalName()).isGenericType().getRawType();
@@ -1400,6 +1402,7 @@
UnableToCompleteException {
TreeLogger logger = createLogger();
+TypeOracle typeOracle = getTestTypeOracle();
SerializableTypeOracleBuilder stob =
createSerializableTypeOracleBuilder(
logger, typeOracle);
JClassType a =
typeOracle.getType(ManualSerialization.A.class.getCanonicalName());
@@ -1418,6 +1421,7 @@
UnableToCompleteException {
TreeLogger logger = createLogger();
+TypeOracle typeOracle = getTestTypeOracle();
JClassType rawList = typeOracle.getType(List.class.getName());
SerializableTypeOracleBuilder stob =
createSerializableTypeOracleBuilder(
logger, typeOracle);
@@ -1562,6 +1566,7 @@
UnableToCompleteException {
TreeLogger logger = createLogger();
+TypeOracle typeOracle = getTestTypeOracle();
JClassType a =
typeOracle.getType(NoSerializableTypes.A.class.getCanonicalName());
SerializableTypeOracleBuilder stob =
createSerializableTypeOracleBuilder(
logger, typeOracle);
@@ -1583,6 +1588,7 @@
throws UnableToCompleteException, NotFoundException {
TreeLogger logger = createLogger();
+TypeOracle typeOracle = getTestTypeOracle();
JClassType a =
typeOracle.getType(NotAllSubtypesAreSerializable.A.class.getCanonicalName());
SerializableTypeOracleBuilder stob =
createSerializableTypeOracleBuilder(
logger, typeOracle);
@@ -1605,6 +1611,7 @@
public void testObjectArrayNotInstantiable() throws
UnableToCompleteException {
TreeLogger logger = createLogger();
+TypeOracle typeOracle = getTestTypeOracle();
JArrayType objectArray =
typeOracle.getArrayType(typeOracle.getJavaLangObject());
SerializableTypeOracleBuilder stob =
createSerializableTypeOracleBuilder(
logger, typeOracle);
@@ -1623,6 +1630,7 @@
public void testObjectNotInstantiable() throws UnableToCompleteException
{
TreeLogger logger = createLogger();
+TypeOracle typeOracle = getTestTypeOracle();
SerializableTypeOracleBuilder stob =
createSerializableTypeOracleBuilder(
logger, typeOracle);
[gwt-contrib] Re: DTO compiler optimization
Nathan, I'm not quite sure which API you are referring too. As there isn't an API for DTOs. My interpritation of Fred's post presents alternate ways of implementing DTO. If the Wave protobuffer mechanism was publicly available it would be a great alternative to hand coded DTOs. An annotation processor for json marshaller to generate client side JSO would be another great alternative. If you get interested in implementing an alternative to hand coded DTOs let me know as I would be interesting in getting involved. Regards Gary --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] SOYC for multiple permutations, plus updated layout
Reviewers: Lex, Description: Hi Lex, would you review this patch to the SOYC dashboard for me? It has two main parts: 1) SOYC for multiple permutations. The dashboard will now read all files in the symbolMaps directory and from it derive all the permutations and their attributes. The dashboard will show a front page that lists (and links to) all permutations. 2) This patch updates the dashboard according to Joel's new layout mockup. The next steps are summarized in follow-up issues 2048346 (more info on front page) and 2048348 (remaining layout issues). Time permitting, we can also avoid some code reduplication in MakeTopLevelHtmlForPerm.java. Please review this at http://gwt-code-reviews.appspot.com/57813 Affected files: tools/soyc-vis/src/com/google/gwt/soyc/GlobalInformation.java tools/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java tools/soyc-vis/src/com/google/gwt/soyc/Settings.java tools/soyc-vis/src/com/google/gwt/soyc/SizeBreakdown.java tools/soyc-vis/src/com/google/gwt/soyc/SoycDashboard.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Prettier GWT version names for upcoming 2.0 releases
Mostly, this writeup is aimed at people who have been working on GWT's own build-related stuff, but if anyone else has objections, now would be a good time to raise them (though it seems unlikely anyone would). In the past, we've never had a good naming scheme for distros other than the general availability distro. For milestones, we used the convention 0.0.rev, which probably scares people off and isn't at all self-descriptive. For RCs and GAs, we used major.minor.bugfix (e.g. 1.5.0 was 1.5 RC1, 1.5.1 was 1.5 RC2, and 1.5.2 was GA). This is all too ad hoc and confusing. Here's the new proposal: major.minor.bugfix (e.g. 2.1.0, 2.1.1, 2.1.2) = This is an official, supported build. Every new minor (or bigger) release would start with a bugfix number of 0. major.minor.bugfix-rcn (e.g. 2.0.0-rc1, 2.0.0-rc2) = This is release candidate build n for the specified upcoming GWT release major.minor.bugfix-mn (e.g. 2.0.0-m1, 2.0.0-m2) = This is milestone build n for the specified upcoming GWT release In other words, the stream of announced code drops for 2.0 will look like this (assuming 2 milestone and 1 rc): 1) gwt-2.0.0-m1.zip 2) gwt-2.0.0-m2.zip 3) gwt-2.0.0-rc1.zip 4) gwt-2.0.0.zip Note that we would always include the RC number, even if there's just one (because you never know if another one is coming). I'm very happy to report that there seems to be no need to change even a single line of code, as best I can tell. (Thank you to whomever wrote the version string parsing code to ignore non-digit prefixes and suffixes.) Thus, by simply following this convention when we set GWT_VERSION in the continuous build, everything should work just fine. -- Bruce P.S. No, Joel, we can't start counting at 0, even though it makes more sense :-) I can read your mind. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Invalid version number 2.0 passed to external.gwtOnLoad()
On Tue, Aug 11, 2009 at 5:47 PM, John Tamplin j...@google.com wrote: On Tue, Aug 11, 2009 at 8:22 PM, Fred Sauer fre...@google.com wrote: I'm not sure I understand the issue. If you have different versions of hosted.html and GWT, things are likely to not work and that is why that check was added in 1.6. I don't see how you could have the incorrect contents of hosted.html but the correct version, unless you update/rollback parts of GWT separately, in which case you are already likely to break things if you don't know what you are doing. Yep, that's exactly the scenario :). Knowing that you have to watch out for this stuff is one thing. Being bit by it every now and again and going down a rabbit hole, is (mildly) annoying. Not a huge deal as this affect contributors only, but could be a good sanity check to save time down the road. There are so many ways you can screw things up by mixing different versions of parts of GWT, I don't see how this is any different. For example, if you rollback an old TypeOracleMediator but don't roll back related TypeOracle changes, things are going to break horribly. I think trying to add code inside GWT to detect such situations is counterproductive and unlikely to be effective anyway. You had me at There are so many ways you can screw things up Thanks Fred I would hope that anyone knows building a version of GWT that is not at a consistent revision across the board means they better know exactly what they are doing or they will get weird breakages. -- John A. Tamplin Software Engineer (GWT), Google -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DTO compiler optimization
@Gary I have not seen the GoogleIo vid, why do you say wave uses json AND protocol buffers to talk between client - server...? On 12/08/2009, at 11:01 AM, Gary Miller miller.ga...@gmail.com wrote: I agree the problem is begging out for a more elegant solution. From the Google IO presentation on Google Wave powered by GWT a solution using proto buffer and JSON instead of GWT RPC is mentioned. I've been thinking that a similar result could be achieved annotation the server side object model with annotation (e.g. jsonmarshaller http://code.google.com/p/jsonmarshaller/) and the generating the client side JavaScriptObject code using an annotation processor. Thoughts? Gary --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
