[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

[codesite-noreply]

Comment by andre.ruediger:

vararg convenience factory methods would be handy.

--- MutableArray ma = makeSnackArray();
--- ImmutableArray ia = ma.freeze();
+++ ImmutableArray ia =  
createImmutableArray("apple", "banana", "coconut", "donut");



For more information:
http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

[codesite-noreply]

Comment by andre.ruediger:

vararg convenience factory methods would be handy.

so

{{{MutableArray? ma = makeSnackArray();
ImmutableArray? ia = ma.freeze();}}}

could become

{{{ImmutableArray? ia =  
createImmutableArray("apple", "banana", "coconut", "donut");}}}




For more information:
http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

[codesite-noreply]

Comment by andre.ruediger:

vararg convenience factory methods would be handy.

so

{{{MutableArray ma = makeSnackArray();
ImmutableArray ia = ma.freeze();}}}

could become

{{{ImmutableArray ia =  
createImmutableArray("apple", "banana", "coconut", "donut");}}}




For more information:
http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

[codesite-noreply]

Comment by andre.ruediger:

vararg convenience factory methods would be handy.

so

{{{
MutableArray ma = makeSnackArray();
ImmutableArray ia = ma.freeze();
}}}

could become

{{{
ImmutableArray ia =  
createImmutableArray("apple", "banana", "coconut", "donut");

}}}


For more information:
http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] UIObject methods return type improvement.

[Qcho]

Hi, I am currently working on a project using GWT.

Maybe is a good suggestion to change the return value of functions
such as addStyleDependentName or addStyleName from void to the UI
modified itself, so you can do things like this:

DockLayoutPanel appPanel = new DockLayoutPanel(Unit.EM);
appPanel.addNorth(new HTML("hh1").addStyleName("header"), 4);
appPanel.addNorth(new HTML("hh2").addStyleName("subHeader"), 
10);
appPanel.addSouth(new HTML("foot").addStyleName("footer"), 4);
appPanel.addWest(new HTML("nav").addStyleName("navigation"), 
10);

this code wont compile since the chaining of addStyleName returns void
and not the Widget element.

Simple example provided.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] UIObject methods return type improvement.

[Joel Webber]

We could argue the merits of method chaining (I'll let the compiler guys
speak to whether or not this is better, worse, or indifferent for code
generation) -- but the bigger problem is that we'd have to change the style
of code throughout the system to make it useful, but any attempt to do so
would break existing subclasses that override these methods.

On Tue, Mar 2, 2010 at 7:19 PM, Qcho  wrote:

> Hi, I am currently working on a project using GWT.
>
> Maybe is a good suggestion to change the return value of functions
> such as addStyleDependentName or addStyleName from void to the UI
> modified itself, so you can do things like this:
>
> DockLayoutPanel appPanel = new DockLayoutPanel(Unit.EM);
>appPanel.addNorth(new HTML("hh1").addStyleName("header"),
> 4);
>appPanel.addNorth(new HTML("hh2").addStyleName("subHeader"),
> 10);
>appPanel.addSouth(new HTML("foot").addStyleName("footer"),
> 4);
>appPanel.addWest(new HTML("nav").addStyleName("navigation"),
> 10);
>
> this code wont compile since the chaining of addStyleName returns void
> and not the Widget element.
>
> Simple example provided.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: when-linker-added

[bobv]

http://gwt-code-reviews.appspot.com/150801/diff/1/5
File dev/core/src/com/google/gwt/dev/cfg/Condition.java (right):

http://gwt-code-reviews.appspot.com/150801/diff/1/5#newcode44
Line 44: public final boolean isTrue(TreeLogger logger, PropertyOracle
propertyOracle,
Could you collapse the parameters for isTrue() and doEval() into a
BagOfStuffThatAffectsEvaluation object?  That way, the next new
Condition type won't lead to more and more parameters on this method.

http://gwt-code-reviews.appspot.com/150801/diff/1/14
File dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java (right):

http://gwt-code-reviews.appspot.com/150801/diff/1/14#newcode913
Line 913: protected Schema __when_linker_added_begin(String linkerName)
{
The parameter should be a LinkerName type.

http://gwt-code-reviews.appspot.com/150801/diff/1/15
File dev/core/src/com/google/gwt/dev/cfg/Properties.java (right):

http://gwt-code-reviews.appspot.com/150801/diff/1/15#newcode83
Line 83: public int numPermutations(Set activeLinkerNames) {
This seems wrong.  Why should a property matrix care about the linkers?
Wouldn't it be better to update the callers of this method to call
through PropertyPermutations instead?

http://gwt-code-reviews.appspot.com/150801

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Fix for issue 4596 (broken layout on tab visibility change in IE6). Changes

[jgw]

Reviewers: jlabanca,

Description:
Fix for issue 4596 (broken layout on tab visibility change in IE6).
Changes
LayoutPanel to provide an explicit setWidgetVisible() method, which
ensures
that the layout is properly updated on a visibility change. Also adds a
test
to catch this particular flavor of failure on IE6.


Please review this at http://gwt-code-reviews.appspot.com/153820

Affected files:
  M user/src/com/google/gwt/user/client/ui/LayoutPanel.java
  M user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java
  M user/test/com/google/gwt/user/client/ui/TabLayoutPanelTest.java


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Fix for KeyPressEvent.getCharCode and overall key events improvements

[jlabanca]

Reviewers: jgw,

Description:
See original report by tbroyer (I can't upload a patch set to the
original report):
http://gwt-code-reviews.appspot.com/142801/show

This version fixes a couple of JSNI bugs and adds more unit tests.  Also
reverts createKeyPressEvent so it isn't breaking.


Please review this at http://gwt-code-reviews.appspot.com/154812

Affected files:
  user/src/com/google/gwt/dom/client/DOMImpl.java
  user/src/com/google/gwt/dom/client/DOMImplMozilla.java
  user/src/com/google/gwt/dom/client/DOMImplOpera.java
  user/src/com/google/gwt/dom/client/DOMImplSafari.java
  user/src/com/google/gwt/dom/client/DOMImplStandard.java
  user/src/com/google/gwt/dom/client/DOMImplTrident.java
  user/src/com/google/gwt/dom/client/Document.java
  user/src/com/google/gwt/dom/client/NativeEvent.java
  user/src/com/google/gwt/event/dom/client/KeyPressEvent.java
  user/test/com/google/gwt/user/client/ui/CreateEventTest.java


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Added the ability to customize the timeout to begin the tests.

[fabbott]

LGTM

http://gwt-code-reviews.appspot.com/153819

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7646 committed - Fixing possible NPE in ImageSrcIE6 when an img element is copied....

[codesite-noreply]

Revision: 7646
Author: jlaba...@google.com
Date: Wed Mar  3 05:43:42 2010
Log: Fixing possible NPE in ImageSrcIE6 when an img element is copied.
http://gwt-code-reviews.appspot.com/150807

http://code.google.com/p/google-web-toolkit/source/detail?r=7646

Added:
 /trunk/user/test/com/google/gwt/dom/client/ImageElementTest.java
 /trunk/user/test/com/google/gwt/dom/public-test
 /trunk/user/test/com/google/gwt/dom/public-test/largeImage0.jpg
 /trunk/user/test/com/google/gwt/dom/public-test/largeImage1.jpg
 /trunk/user/test/com/google/gwt/dom/public-test/largeImage2.jpg
 /trunk/user/test/com/google/gwt/dom/public-test/smallImage0.jpg
 /trunk/user/test/com/google/gwt/dom/public-test/smallImage1.jpg
 /trunk/user/test/com/google/gwt/dom/public-test/smallImage2.jpg
Modified:
 /trunk/user/src/com/google/gwt/dom/client/DOMImplIE6.java
 /trunk/user/src/com/google/gwt/dom/client/ImageElement.java
 /trunk/user/src/com/google/gwt/dom/client/ImageSrcIE6.java
 /trunk/user/src/com/google/gwt/layout/client/LayoutImplIE6.java
 /trunk/user/src/com/google/gwt/user/client/ui/impl/ClippedImageImplIE6.java
 /trunk/user/test/com/google/gwt/dom/DOMTest.gwt.xml

===
--- /dev/null
+++ /trunk/user/test/com/google/gwt/dom/client/ImageElementTest.java	Wed  
Mar  3 05:43:42 2010

@@ -0,0 +1,93 @@
+/*
+ * 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.dom.client;
+
+import com.google.gwt.junit.client.GWTTestCase;
+
+/**
+ * Tests for {...@link ImageElement}.
+ */
+public class ImageElementTest extends GWTTestCase {
+
+  @Override
+  public String getModuleName() {
+return "com.google.gwt.dom.DOMTest";
+  }
+
+  /**
+   * IE6 has a special implementation of {...@link  
ImageElement#setSrc(String)}
+   * that prevents the browser from loading uncached images multiple  
times. In
+   * order to test this properly, the browser should be set to clear its  
cache

+   * on exit.
+   */
+  public void testSetSrc() {
+// The parent element will actually load the image.
+ImageElement parent = Document.get().createImageElement();
+parent.setSrc("largeImage0.jpg");
+assertTrue(parent.getSrc().endsWith("largeImage0.jpg"));
+
+// The child element does not have its source set until the parent  
loads.

+ImageElement child = Document.get().createImageElement();
+child.setSrc("largeImage0.jpg");
+assertTrue(child.getSrc().endsWith("largeImage0.jpg"));
+
+child.setSrc("smallImage1.jpg");
+assertTrue(child.getSrc().endsWith("smallImage1.jpg"));
+  }
+
+  public void testSetSrcCloneParent() {
+// The parent element will actually load the image.
+ImageElement parent = Document.get().createImageElement();
+parent.setSrc("largeImage1.jpg");
+assertTrue(parent.getSrc().endsWith("largeImage1.jpg"));
+
+// The child element does not have its source set until the parent  
loads.

+ImageElement child = Document.get().createImageElement();
+child.setSrc("largeImage1.jpg");
+assertTrue(child.getSrc().endsWith("largeImage1.jpg"));
+
+// The parent clone will have its source set. We call setSrc to  
convert it

+// to a child.
+final ImageElement cloneParent = parent.cloneNode(true).cast();
+cloneParent.setSrc("largeImage1.jpg");
+assertTrue(cloneParent.getSrc().endsWith("largeImage1.jpg"));
+
+cloneParent.setSrc("smallImage1.jpg");
+assertTrue(cloneParent.getSrc().endsWith("smallImage1.jpg"));
+  }
+
+  public void testSetSrcCloneChild() {
+// The parent element will actually load the image.
+ImageElement parent = Document.get().createImageElement();
+parent.setSrc("largeImage2.jpg");
+assertTrue(parent.getSrc().endsWith("largeImage2.jpg"));
+
+// The child element does not have its source set until the parent  
loads.

+ImageElement child = Document.get().createImageElement();
+child.setSrc("largeImage2.jpg");
+assertTrue(child.getSrc().endsWith("largeImage2.jpg"));
+
+// The child clone will not have its source set. We call setSrc to  
ensure

+// it is registered as a child.
+final ImageElement cloneChild = parent.cloneNode(true).cast();
+cloneChild.setSrc("largeImage2.jpg");
+assertTrue(cloneChild.getSrc().endsWith("largeImage2.jpg"));
+
+cloneChild.setSrc("smallImage2.jpg");
+assertTrue(cloneChild.getSrc().endsWith("smallImage2.jpg"));
+  }
+
+}
===
--- /d

[gwt-contrib] Re: Added the ability to customize the timeout to begin the tests.

[jat]

LGTM

http://gwt-code-reviews.appspot.com/153819

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: when-linker-added

[spoon]

http://gwt-code-reviews.appspot.com/150801/diff/1/5
File dev/core/src/com/google/gwt/dev/cfg/Condition.java (right):

http://gwt-code-reviews.appspot.com/150801/diff/1/5#newcode44
Line 44: public final boolean isTrue(TreeLogger logger, PropertyOracle
propertyOracle,
With pleasure.  Maybe "DeferredBindingQuery" ?

http://gwt-code-reviews.appspot.com/150801/diff/1/14
File dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java (right):

http://gwt-code-reviews.appspot.com/150801/diff/1/14#newcode913
Line 913: protected Schema __when_linker_added_begin(String linkerName)
{
Ah, I missed that class.

http://gwt-code-reviews.appspot.com/150801/diff/1/15
File dev/core/src/com/google/gwt/dev/cfg/Properties.java (right):

http://gwt-code-reviews.appspot.com/150801/diff/1/15#newcode83
Line 83: public int numPermutations(Set activeLinkerNames) {
Will do.

http://gwt-code-reviews.appspot.com/150801

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: when-linker-added

[Bruce Johnson]

Is there some sort of lightweight design doc for this? I'm pretty sure I
remember it being discussed somewhere, but we need a short writeup on the
project wiki to capture the context.

On Wed, Mar 3, 2010 at 12:17 PM,  wrote:

>
> http://gwt-code-reviews.appspot.com/150801/diff/1/5
> File dev/core/src/com/google/gwt/dev/cfg/Condition.java (right):
>
> http://gwt-code-reviews.appspot.com/150801/diff/1/5#newcode44
> Line 44: public final boolean isTrue(TreeLogger logger, PropertyOracle
> propertyOracle,
> With pleasure.  Maybe "DeferredBindingQuery" ?
>
>
> http://gwt-code-reviews.appspot.com/150801/diff/1/14
> File dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java (right):
>
> http://gwt-code-reviews.appspot.com/150801/diff/1/14#newcode913
> Line 913: protected Schema __when_linker_added_begin(String linkerName)
> {
> Ah, I missed that class.
>
>
> http://gwt-code-reviews.appspot.com/150801/diff/1/15
> File dev/core/src/com/google/gwt/dev/cfg/Properties.java (right):
>
> http://gwt-code-reviews.appspot.com/150801/diff/1/15#newcode83
> Line 83: public int numPermutations(Set activeLinkerNames) {
> Will do.
>
>
> http://gwt-code-reviews.appspot.com/150801
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7647 committed - Remove extraneous right-paren when pretty-printing a @noflip CssResour...

[codesite-noreply]

Revision: 7647
Author: gwt.mirror...@gmail.com
Date: Wed Mar  3 06:58:58 2010
Log: Remove extraneous right-paren when pretty-printing a @noflip  
CssResource rule.


http://code.google.com/p/google-web-toolkit/source/detail?r=7647

Modified:
 /trunk/user/src/com/google/gwt/resources/css/CssGenerationVisitor.java

===
--- /trunk/user/src/com/google/gwt/resources/css/CssGenerationVisitor.java	 
Thu Jan 21 09:47:21 2010
+++ /trunk/user/src/com/google/gwt/resources/css/CssGenerationVisitor.java	 
Wed Mar  3 06:58:58 2010

@@ -184,7 +184,7 @@

   @Override
   public boolean visit(CssNoFlip x, Context ctx) {
-out.printOpt("/*...@noflip { */)");
+out.printOpt("/*...@noflip { */");
 out.newlineOpt();
 return true;
   }

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7648 committed - Added the ability to customize the timeout to begin the tests....

[codesite-noreply]

Revision: 7648
Author: gwt.mirror...@gmail.com
Date: Wed Mar  3 10:18:02 2010
Log: Added the ability to customize the timeout to begin the tests.
http://gwt-code-reviews.appspot.com/153819/show

http://code.google.com/p/google-web-toolkit/source/detail?r=7648

Modified:
 /trunk/user/src/com/google/gwt/junit/JUnitShell.java

===
--- /trunk/user/src/com/google/gwt/junit/JUnitShell.java	Thu Feb 25  
06:57:14 2010
+++ /trunk/user/src/com/google/gwt/junit/JUnitShell.java	Wed Mar  3  
10:18:02 2010

@@ -260,6 +260,39 @@
 }
   });

+  registerHandler(new ArgHandlerInt() {
+@Override
+public String[] getDefaultArgs() {
+  return new String[] {getTag(), "1"};
+}
+
+@Override
+public String getPurpose() {
+  return "Set the test begin timeout (time for clients to contact "
+  + "server), in minutes";
+}
+
+@Override
+public String getTag() {
+  return "-testBeginTimeout";
+}
+
+@Override
+public String[] getTagArgs() {
+  return new String[] {"minutes"};
+}
+
+@Override
+public boolean isUndocumented() {
+  return false;
+}
+
+@Override
+public void setInt(int minutes) {
+  baseTestBeginTimeoutMillis = minutes * 60 * 1000;
+}
+  });
+
   registerHandler(new ArgHandlerString() {
 @Override
 public String getPurpose() {
@@ -460,13 +493,6 @@
   });
 }
   }
-
-  /**
-   * The amount of time to wait for all clients to have contacted the  
server and
-   * begin running the test. "Contacted" does not necessarily mean "the  
test has

-   * begun," e.g. for linker errors stopping the test initialization.
-   */
-  static final int TEST_BEGIN_TIMEOUT_MILLIS = 60 * 1000;

   /**
* This is a system property that, when set, emulates command line  
arguments.

@@ -675,6 +701,13 @@
*/
   private long baseTestMethodTimeoutMillis;

+  /**
+   * The amount of time to wait for all clients to have contacted the  
server and
+   * begin running the test. "Contacted" does not necessarily mean "the  
test has

+   * begun," e.g. for linker errors stopping the test initialization.
+   */
+  private long baseTestBeginTimeoutMillis;
+
   /**
* Determines how to batch up tests for execution.
*/
@@ -925,7 +958,7 @@
   double elapsed = (currentTimeMillis - testBeginTime) / 1000.0;
   throw new TimeoutException(
   "The browser did not contact the server within "
-  + TEST_BEGIN_TIMEOUT_MILLIS + "ms.\n"
+  + baseTestBeginTimeoutMillis + "ms.\n"
   + messageQueue.getUnretrievedClients(currentTestInfo)
   + "\n Actual time elapsed: " + elapsed + " seconds.\n");
 }
@@ -1220,7 +1253,7 @@
   // Set a timeout period to automatically fail if the servlet hasn't  
been
   // contacted; something probably went wrong (the module failed to  
load?)

   testBeginTime = System.currentTimeMillis();
-  testBeginTimeout = testBeginTime + TEST_BEGIN_TIMEOUT_MILLIS;
+  testBeginTimeout = testBeginTime + baseTestBeginTimeoutMillis;
   testMethodTimeout = 0; // wait until test execution begins
   while (notDone()) {
 messageQueue.waitForResults(1000);

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix for issue 4596 (broken layout on tab visibility change in IE6). Changes

[jlabanca]

LGTM

http://gwt-code-reviews.appspot.com/153820

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix for issue 4596 (broken layout on tab visibility change in IE6). Changes

[kozura]

(copied conversation I started in the wrong place)

Sure, I understand completely how hard it is to work a coherent layout
system into the hack we call CSS/Html, same reason there's setHeight()
and setCellHeight().  But adding this creates a new non-symmetry, where
a child must be aware of its parent context, which should be considered
with care..  Using setVisible on the child will now work fine in some
contexts, but not in others.  Possibly it may only break in one
particular browser.  So the developer must be aware of this.  If this
could be made an internal function, it would address this concern by
limiting the need to know to LayoutPanel implementers, unfortunately
LayoutPanel is instantiated not inherited so this is not an option.

Another solution is to add a VisiblityHandler to widgets.  A LayoutPanel
would add a handler for this on its children, and do the proper thing.
Seems like overkill for this problem but...

It could also solve the much more general problem that we cannot find
out when a particular widget becomes truly visible on the page, without
knowing its parentage.  If I want to do delayed rendering on a widget, I
can only get that information from, say, a tabSelection handler,
something in the parent that can trigger something in a child.  If I
also instantiate that widget in a StackPanel, I need another mechanism
to tell it when it becomes visible.  So it's difficult to write a
context-free widget that can do delayed rendering of itself.  A
propagated visibility event would decouple the two, allowing parent to
detect when its children change visibility, and any widget to detect
this about itself.  Whether it is really possible to reliably detect
this, and economical code-size and performance-wise to implement it, I
don't know.


Comment 6 by j...@google.com, Today (18 minutes ago)



The code review page would be more appropriate, but I'm fine with

discussing here for the time being.


The reason we have both LayoutPanel.setWidgetVisible() and

Widget.setVisible() is, like so many things, a side-

effect of the mess that is HTML/CSS. The Layout/Layer code *has* to

create container elements to work

around various design flaws in the CSS layout model. But if you just

call Widget.setVisible() on one of the

children, its container element must be hidden as well. But

Widget.setVisible() has no way of doing this

sensibly. I don't particularly like this fact but we're stuck with it

as long as we have to target HTML/CSS.


Also, I have not looked at issue 4694 yet, but will see if there's a

similar issue at fault.



Comment 5  by kozura
Apart from whether this works to solve the issue, I'm always nervous

to see multiple

public methods that to a normal user appear to do the same thing, so

setWidgetVisible

gives me pause.  As a user, why is there this function, and

setVisible?  Are they

just different ways to do the same thing?  If not, which do I call?

Do I need to

call both?  There are already a number of these ambiguous functions

throughout GWT

code (and here too - should I be posting these comments here on the

issue page, or on

the code review page...), so can this be done logically without

having to create a

separate but similar public function?



Also, will this address the slightly different but similar issue I

posted with IE8,

http://code.google.com/p/google-web-toolkit/issues/detail?id=4694 ?

I don't think so

as it is, but maybe if the solution is similar it can be expanded?




http://gwt-code-reviews.appspot.com/153820

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7649 committed - Fix for issue 4596 (broken layout on tab visibility change in IE6). Ch...

[codesite-noreply]

Revision: 7649
Author: j...@google.com
Date: Wed Mar  3 07:46:03 2010
Log: Fix for issue 4596 (broken layout on tab visibility change in IE6).  
Changes

LayoutPanel to provide an explicit setWidgetVisible() method, which ensures
that the layout is properly updated on a visibility change. Also adds a test
to catch this particular flavor of failure on IE6.

Review at http://gwt-code-reviews.appspot.com/153820

http://code.google.com/p/google-web-toolkit/source/detail?r=7649

Modified:
 /trunk/user/src/com/google/gwt/user/client/ui/LayoutPanel.java
 /trunk/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java
 /trunk/user/test/com/google/gwt/user/client/ui/TabLayoutPanelTest.java

===
--- /trunk/user/src/com/google/gwt/user/client/ui/LayoutPanel.java	Tue Dec   
1 15:21:10 2009
+++ /trunk/user/src/com/google/gwt/user/client/ui/LayoutPanel.java	Wed Mar   
3 07:46:03 2010

@@ -332,6 +332,22 @@
 getLayer(child).setChildVerticalPosition(position);
 animate(0);
   }
+
+  /**
+   * Shows or hides the given widget and its layer. This method explicitly
+   * calls {...@link UIObject#setVisible(boolean)} on the child widget and  
ensures

+   * that its associated layer is shown/hidden.
+   *
+   * @param child
+   * @param visible
+   */
+  public void setWidgetVisible(Widget child, boolean visible) {
+assertIsChild(child);
+Element container = getWidgetContainerElement(child);
+setVisible(container, visible);
+child.setVisible(visible);
+animate(0);
+  }

   @Override
   protected void onLoad() {
===
--- /trunk/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java	Mon  
Mar  1 07:55:36 2010
+++ /trunk/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java	Wed  
Mar  3 07:46:03 2010

@@ -386,16 +386,12 @@
 // Update the tabs being selected and unselected.
 if (selectedIndex != -1) {
   Widget child = children.get(selectedIndex);
-  Element container = panel.getWidgetContainerElement(child);
-  container.getStyle().setDisplay(Display.NONE);
-  child.setVisible(false);
+  panel.setWidgetVisible(child, false);
   tabs.get(selectedIndex).setSelected(false);
 }

 Widget child = children.get(index);
-Element container = panel.getWidgetContainerElement(child);
-container.getStyle().clearDisplay();
-child.setVisible(true);
+panel.setWidgetVisible(child, true);
 tabs.get(index).setSelected(true);
 selectedIndex = index;

===
--- /trunk/user/test/com/google/gwt/user/client/ui/TabLayoutPanelTest.java	 
Mon Mar  1 07:55:36 2010
+++ /trunk/user/test/com/google/gwt/user/client/ui/TabLayoutPanelTest.java	 
Wed Mar  3 07:46:03 2010

@@ -23,6 +23,8 @@
 import com.google.gwt.junit.DoNotRunWith;
 import com.google.gwt.junit.Platform;
 import com.google.gwt.junit.client.GWTTestCase;
+import com.google.gwt.user.client.Command;
+import com.google.gwt.user.client.DeferredCommand;

 import java.util.Iterator;

@@ -58,6 +60,39 @@
   public void testAttachDetachOrder() {
 HasWidgetsTester.testAll(new TabLayoutPanel(1, Unit.EM), new Adder(),  
true);

   }
+
+  /**
+   * Ensures that hidden children are layed out properly when their tabs  
are

+   * selected. This has been a problem on IE6 (see issue 4596).
+   */
+  @DoNotRunWith({Platform.HtmlUnitBug})
+  public void testHiddenChildLayout() {
+final TabLayoutPanel p = new TabLayoutPanel(32, Unit.PX);
+p.setSize("128px", "128px");
+RootPanel.get().add(p);
+
+final Label foo = new Label("foo");
+final Label bar = new Label("bar");
+p.add(foo, new Label("foo"));
+p.add(bar, new Label("bar"));
+
+delayTestFinish(2000);
+DeferredCommand.addCommand(new Command() {
+  public void execute() {
+assertEquals(128, foo.getOffsetWidth());
+assertEquals(128 - 32, foo.getOffsetHeight());
+
+p.selectTab(1);
+DeferredCommand.addCommand(new Command() {
+  public void execute() {
+assertEquals(128, bar.getOffsetWidth());
+assertEquals(128 - 32, bar.getOffsetHeight());
+finishTest();
+  }
+});
+  }
+});
+  }

   public void testInsertBeforeSelected() {
 TabLayoutPanel p = new TabLayoutPanel(2, Unit.EM);

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Including a CSS resource into another one

[BobV]

> 

The @Source annotation, and presumably the src attribute of ui:style,
accepts multiple css files.

-- 
Bob Vawter
Google Web Toolkit Team

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix for issue 4596 (broken layout on tab visibility change in IE6). Changes

[jgw]

On 2010/03/03 18:32:18, kozura wrote:

Sure, I understand completely how hard it is to work a coherent layout

system

into the hack we call CSS/Html, same reason there's setHeight() and
setCellHeight().  But adding this creates a new non-symmetry, where a

child must

be aware of its parent context, which should be considered with care..

 Using

setVisible on the child will now work fine in some contexts, but not

in others.

Possibly it may only break in one particular browser.  So the

developer must be

aware of this.  If this could be made an internal function, it would

address

this concern by limiting the need to know to LayoutPanel implementers,
unfortunately LayoutPanel is instantiated not inherited so this is not

an

option.



Another solution is to add a VisiblityHandler to widgets.  A

LayoutPanel would

add a handler for this on its children, and do the proper thing.

Seems like

overkill for this problem but...



It could also solve the much more general problem that we cannot find

out when a

particular widget becomes truly visible on the page, without knowing

its

parentage.  If I want to do delayed rendering on a widget, I can only

get that

information from, say, a tabSelection handler, something in the parent

that can

trigger something in a child.  If I also instantiate that widget in a
StackPanel, I need another mechanism to tell it when it becomes

visible.  So

it's difficult to write a context-free widget that can do delayed

rendering of

itself.  A propagated visibility event would decouple the two,

allowing parent

to detect when its children change visibility, and any widget to

detect this

about itself.  Whether it is really possible to reliably detect this,

and

economical code-size and performance-wise to implement it, I don't

know.

Trust me, I'm all for finding a better general solution to the problem
of finding out when widget's become shown and/or hidden (and resized,
for that matter). My experience so far tells me that this is impossible
to do in an even remotely efficient way, though I would *love* to be
proven wrong on that subject.

The problem with determining when an element (and consequently its
widget) becomes shown/hidden is that it can happen in so many different
ways. It is primarily affected by the display: and visibility: CSS
properties, both of which apply hierarchically, and the latter of which
can be *unapplied* to a child via CSS. These can be affected by any
arbitrary CSS selector, which means that we'd have to recalculate
visibility on any change to any parent's style object, class name, etc.
-- which of course can happen via Javascript, user style sheets, and so
forth. Those cases are a bit obscure, but even capturing changes made
only through Java code looks impossible to implement efficiently.

That said, if you have any ideas on how to deal with this, please let me
know -- it would allow us to clean up a *lot* of nasty bits in the code.

http://gwt-code-reviews.appspot.com/153820

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix for issue 4596 (broken layout on tab visibility change in IE6). Changes

[jgw]

Committed at r7649.

http://gwt-code-reviews.appspot.com/153820

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix for issue 4596 (broken layout on tab visibility change in IE6). Changes

[kozura]

Well, I've seen your arguments on resize/visibility events in other
forums, and must defer to your judgment on what is possible in the
various browsers and GWT infrastructure!  Just annoying to have to add
another nasty bit, especially one that creates new confusing user
visible API.

My parting thought is, how bad performance-wise was something like the
resize setup that was done in the incubator awhile back, that used
timers and a list of widgets of interest?  Something like that could
instead work through the event handler - when you add a handler for
resize/visibility to a widget, it's added to the watched list and
checked every so often.  My application is completely dynamic, with lots
of computations being done to update all of it, and performs smoothly;
this would just be a simple check on all the elements in a list.  Not
perfect, but it bypasses all the various ways things can be
visible/resized at the expense of a bit of polling - and if any browsers
like Chrome do ever implement these events, using those would be
transparent to the user.  Would that expense be worth getting rid of all
the internal and user-visible pains?


http://gwt-code-reviews.appspot.com/153820

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] NoDeployTest timeout is too short

[jlabanca]

Reviewers: jat,

Description:
The RPC timeout in NoDeployTest is too short, which makes the test
flaky.  This patch increases the timeout to 5000ms.

Please review this at http://gwt-code-reviews.appspot.com/157802

Affected files:
  user/test/com/google/gwt/module/client/NoDeployTest.java


Index: user/test/com/google/gwt/module/client/NoDeployTest.java
===
--- user/test/com/google/gwt/module/client/NoDeployTest.java(revision 7645)
+++ user/test/com/google/gwt/module/client/NoDeployTest.java(working copy)
@@ -42,7 +42,7 @@
   /**
* The maximum amount of time to wait for an RPC response in  
milliseconds.

*/
-  private static final int RESPONSE_DELAY = 1500;
+  private static final int RESPONSE_DELAY = 5000;

   @Override
   public String getModuleName() {


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: NoDeployTest timeout is too short

[jat]

LGTM


http://gwt-code-reviews.appspot.com/157802

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7651 committed - Created wiki page through web user interface. (Formatting in progress....

[codesite-noreply]

Revision: 7651
Author: rj...@google.com
Date: Wed Mar  3 15:01:26 2010
Log: Created wiki page through web user interface. (Formatting in progress.)
http://code.google.com/p/google-web-toolkit/source/detail?r=7651

Added:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /dev/null
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:01:26 2010
@@ -0,0 +1,165 @@
+#summary The third iteration of the RequestFactory design.
+
+= Introduction =
+
+This not-quite-a-design-document sketches an approach to both data binding  
dealing with server side business objects from a GWT client. It builds on  
the discussion at ValueStoreAndRequestFactory and RequestFactorySketch2,  
and like them is too cryptic but better than nothing. For the first time, I  
think I have a complete proposal here, at least behind my eyeballs.

+
+Work is underway to build a prototype illustrating this scheme, which  
sooner will find its way into the  
[http://code.google.com/p/google-web-toolkit/source/browse/trunk/bikeshed/README  
bikeshed].

+
+This was originally posted as a  
[https://wave.google.com/wave/#restored:wave:googlewave.com!w%252BKEONTvE6C  
wave], and some discussion may be happening there.

+
+rjrjr
+
+= Details =
+
+I've backed away from the souped up EventBus approach posted last week and  
am back to data being pushed directly from the ValueStore to HasValue and  
HasValueList subscribers. The new piece of the puzzle is Path objects,  
which accompany request objects to the server and tell it just which data  
we actually want returned.

+
+Still unaddressed is how plain old client side Beans / model objects can  
take advantage of the data binding here without drowning them in  
boilerplate, but I take it as a given that we can and should make that  
work. It also seems likely that a lot of the builder style runtime  
construction that's happening here could (should) be happening at compile  
time instead. TBD.

+
+So: imagine a bit of UI that wants to display data for an employee. You  
might make that happen with code a bit like this:

+
+{{{
+ExpensesRequestFactory requests = ...;
+Employee e = ...; // from previous request
+HasValue myName = new TextField();
+
+requests.values.subscribe(
+  requests.employees().findEmployee(e.getId())
+.newPathThrough(Employee.DISPLAY_NAME)
+.to(myName));
+}}}
+
+Here's what's going on. {{{ ExpensesRequestFactory }}} is an interface  
generated by a JPA-aware tool that trawled through the server side domain  
classes. The user then GWT.create()s an instance of it. A request factory  
provides builders that can create request objects corresponding to every  
service method on the server side domain layer.

+
+(The intention is that we provide the tool. Presumably we could provide  
similar tools for other persistence frameworks. JPA just happens to be a  
good choice for both Roo and GAE.)

+
+In this example, {{{ employees().findEmployee(e.getId()) }}} is creating  
an instance of a request object. That's important: findEmployee() isn't an  
rpc call, it's a factory call to create an instance of something like  
FindEmployeeRequest. Later on that will go over the wire to be interpreted  
by the server, probably as part of a batch at the end of the current  
eventloop.

+
+{{{ Employee }}} is another product of our tool, and embodies the id and  
properties of a server side entity class, e.g. Employee.DISPLAY_NAME.  See  
a full fledged example of it in the blip below.

+
+requests.values.subscribe() is a call to ValueStore#subscribe(Path), which  
does the following:

+
+It establishes a subscription keyed from the last entity + property of the  
path to an appropriate HasValue. In this case, myName is subscribed to  
Employee e's DISPLAY_NAME.
+It fires off the request that anchors the path (findEmployee()) to ensure  
the necessary property value is available, perhaps short circuiting if such  
a call is already cached.

+Once we have the DISPLAY_NAME value, it is pushed to myName.setValue().
+Whenever e's DISPLAY_NAME is updated it is pushed again, until the  
subscription is dropped.

+
+If we can assume that every entity class has an appropriate findFoo()  
method, this can be simpler:

+
+requests.values.subscribe(e
+.newPathThrough(Employee.DISPLAY_NAME)
+.to(myName));
+
+It's not hard to imagine an annotation that would cause the above to be  
generated. (Pretend GWT.create() has actually been made useful and now  
accepts helper arguments.)

+
+class EmployeeDisplay extends Composite implements HasValue {
+private static final UiBinder UI_BINDER =
+GWT.create(UiBinder.class, EmployeeDisplay.class);
+private static final HasValueSupport DATA_BINDER =
+GWT.create(HasValueSupport.class, EmployeeDisplay.class);
+
+// works w/data binder b/c field name matches property
+// If it didn't match, could add @Path("displayName")
+...@uifield HasValuedisplayName;
+
+private ValueStore values;
+
+public void setValueStore(ValueStore values) { t

[gwt-contrib] [google-web-toolkit] r7652 committed - Edited wiki page through web user interface.

[codesite-noreply]

Revision: 7652
Author: rj...@google.com
Date: Wed Mar  3 15:11:02 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7652

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:01:26 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:11:02 2010
@@ -35,131 +35,128 @@

 In this example, {{{ employees().findEmployee(e.getId()) }}} is creating  
an instance of a request object. That's important: findEmployee() isn't an  
rpc call, it's a factory call to create an instance of something like  
FindEmployeeRequest. Later on that will go over the wire to be interpreted  
by the server, probably as part of a batch at the end of the current  
eventloop.


-{{{ Employee }}} is another product of our tool, and embodies the id and  
properties of a server side entity class, e.g. Employee.DISPLAY_NAME.  See  
a full fledged example of it in the blip below.

-
-requests.values.subscribe() is a call to ValueStore#subscribe(Path), which  
does the following:

-
-It establishes a subscription keyed from the last entity + property of the  
path to an appropriate HasValue. In this case, myName is subscribed to  
Employee e's DISPLAY_NAME.
-It fires off the request that anchors the path (findEmployee()) to ensure  
the necessary property value is available, perhaps short circuiting if such  
a call is already cached.

-Once we have the DISPLAY_NAME value, it is pushed to myName.setValue().
-Whenever e's DISPLAY_NAME is updated it is pushed again, until the  
subscription is dropped.
+{{{ Employee }}} is another product of our tool, and embodies the id and  
properties of a server side entity class, e.g. {{{ Employee.DISPLAY_NAME  
}}}.  See a full fledged example of it in the blip below.

+
+{{{ requests.values.subscribe() }}} is a call to {{{  
ValueStore#subscribe(Path) }}}, which does the following:

+
+   * It establishes a subscription keyed from the last entity + property  
of the path to an appropriate HasValue. In this case, myName is subscribed  
to Employee e's DISPLAY_NAME.
+   * It fires off the request that anchors the path (findEmployee()) to  
ensure the necessary property value is available, perhaps short circuiting  
if such a call is already cached.
+   * Once we have the DISPLAY_NAME value, it is pushed to  
myName.setValue().
+   * Whenever e's DISPLAY_NAME is updated it is pushed again, until the  
subscription is dropped.


 If we can assume that every entity class has an appropriate findFoo()  
method, this can be simpler:


+{{{
 requests.values.subscribe(e
-.newPathThrough(Employee.DISPLAY_NAME)
-.to(myName));
+  .newPathThrough(Employee.DISPLAY_NAME)
+  .to(myName));
+}}}

 It's not hard to imagine an annotation that would cause the above to be  
generated. (Pretend GWT.create() has actually been made useful and now  
accepts helper arguments.)


+{{{
+
 class EmployeeDisplay extends Composite implements HasValue {
-private static final UiBinder UI_BINDER =
-GWT.create(UiBinder.class, EmployeeDisplay.class);
-private static final HasValueSupport DATA_BINDER =
-GWT.create(HasValueSupport.class, EmployeeDisplay.class);
-
-// works w/data binder b/c field name matches property
-// If it didn't match, could add @Path("displayName")
-...@uifield HasValuedisplayName;
-
-private ValueStore values;
-
-public void setValueStore(ValueStore values) { this.values = values; }
-public void setValue(Employee value) {
-DATA_BINDER.setValue(this, values, value);
-}
+  private static final UiBinder UI_BINDER =
+GWT.create(UiBinder.class, EmployeeDisplay.class);
+  private static final HasValueSupport DATA_BINDER =
+GWT.create(HasValueSupport.class, EmployeeDisplay.class);
+
+  // works w/data binder b/c field name matches property
+  // If it didn't match, could add @Path("displayName")
+  @UiField HasValuedisplayName;
+
+  private ValueStore values;
+
+  public void setValueStore(ValueStore values) { this.values = values; }
+  public void setValue(Employee value) {
+DATA_BINDER.setValue(this, values, value);
+  }
 }

-Here's a more interesting path:
+}}}
+
+Here's a more interesting path, to show someone's boss's name. Note that  
the subscription will keyed directly to the boss entity, not to the  
e.MANAGER.DISPLAY_NAME path.

+
+{{{

 HasValue bossName = new TextField();

 requests.values.subscribe(e
-.newPathThrough(Employee.MANAGER)
-.through(Employee.DISPLAY_NAME)
-.to(bossName));
+  .newPathThrough(Employee.MANAGER)
+  .through(Employee.DISPLAY_NAME)
+  .to(bossName));
+
+}}}

 For list values, we assume a HasValueList interface, which looks a lot  
like John L's ListHandler.  (I'm cheating a bit, would really need both  
display name and id in the ListBox for this to be useful, but just to get  
the idea across):


+{{{
+
 HasValueList employeeList = new ListBox();

 requests.values.subscribe(
-requests.employees().findAllEmployees()
-.forPr

[gwt-contrib] RR: RequestFactory, third time's the charm

[Ray Ryan]

More musings on ORM and databinding. I think we're going to build this one,
or at least prototype it.

http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryPlusPaths

or

https://wave.google.com/wave/#restored:wave:googlewave.com!w%252BKEONTvE6C

-- 
I wish this were a Wave

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7653 committed - Edited wiki page through web user interface.

[codesite-noreply]

Revision: 7653
Author: rj...@google.com
Date: Wed Mar  3 15:13:21 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7653

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:11:02 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:13:21 2010
@@ -4,7 +4,7 @@

 This not-quite-a-design-document sketches an approach to both data binding  
dealing with server side business objects from a GWT client. It builds on  
the discussion at ValueStoreAndRequestFactory and RequestFactorySketch2,  
and like them is too cryptic but better than nothing. For the first time, I  
think I have a complete proposal here, at least behind my eyeballs.


-Work is underway to build a prototype illustrating this scheme, which  
sooner will find its way into the  
[http://code.google.com/p/google-web-toolkit/source/browse/trunk/bikeshed/README  
bikeshed].
+Work is underway to build a prototype illustrating this scheme, which soon  
will find its way into the  
[http://code.google.com/p/google-web-toolkit/source/browse/trunk/bikeshed/README  
bikeshed].


 This was originally posted as a  
[https://wave.google.com/wave/#restored:wave:googlewave.com!w%252BKEONTvE6C  
wave], and some discussion may be happening there.


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7654 committed - Added Values interface

[codesite-noreply]

Revision: 7654
Author: rj...@google.com
Date: Wed Mar  3 15:29:14 2010
Log: Added Values interface
http://code.google.com/p/google-web-toolkit/source/detail?r=7654

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:13:21 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:29:14 2010
@@ -29,15 +29,15 @@
 .to(myName));
 }}}

-Here's what's going on. {{{ ExpensesRequestFactory }}} is an interface  
generated by a JPA-aware tool that trawled through the server side domain  
classes. The user then GWT.create()s an instance of it. A request factory  
provides builders that can create request objects corresponding to every  
service method on the server side domain layer.
+Here's what's going on. {{{ExpensesRequestFactory}}} is an interface  
generated by a JPA-aware tool that trawled through the server side domain  
classes. The user then GWT.create()s an instance of it. A request factory  
provides builders that can create request objects corresponding to every  
service method on the server side domain layer.


 (The intention is that we provide the tool. Presumably we could provide  
similar tools for other persistence frameworks. JPA just happens to be a  
good choice for both Roo and GAE.)


-In this example, {{{ employees().findEmployee(e.getId()) }}} is creating  
an instance of a request object. That's important: findEmployee() isn't an  
rpc call, it's a factory call to create an instance of something like  
FindEmployeeRequest. Later on that will go over the wire to be interpreted  
by the server, probably as part of a batch at the end of the current  
eventloop.

-
-{{{ Employee }}} is another product of our tool, and embodies the id and  
properties of a server side entity class, e.g. {{{ Employee.DISPLAY_NAME  
}}}.  See a full fledged example of it in the blip below.

-
-{{{ requests.values.subscribe() }}} is a call to {{{  
ValueStore#subscribe(Path) }}}, which does the following:
+In this example, {{{employees().findEmployee(e.getId())}}} is creating an  
instance of a request object. That's important: findEmployee() isn't an rpc  
call, it's a factory call to create an instance of something like  
FindEmployeeRequest. Later on that will go over the wire to be interpreted  
by the server, probably as part of a batch at the end of the current  
eventloop.

+
+{{{Employee}}} is another product of our tool, and embodies the id and  
properties of a server side entity class, e.g.  
{{{Employee.DISPLAY_NAME}}}.  See a full fledged example of it in the blip  
below.

+
+{{{requests.values.subscribe()}}} is a call to  
{{{ValueStore#subscribe(Path)}}}, which does the following:


* It establishes a subscription keyed from the last entity + property  
of the path to an appropriate HasValue. In this case, myName is subscribed  
to Employee e's DISPLAY_NAME.
* It fires off the request that anchors the path (findEmployee()) to  
ensure the necessary property value is available, perhaps short circuiting  
if such a call is already cached.

@@ -55,7 +55,6 @@
 It's not hard to imagine an annotation that would cause the above to be  
generated. (Pretend GWT.create() has actually been made useful and now  
accepts helper arguments.)


 {{{
-
 class EmployeeDisplay extends Composite implements HasValue {
   private static final UiBinder UI_BINDER =
 GWT.create(UiBinder.class, EmployeeDisplay.class);
@@ -73,34 +72,41 @@
 DATA_BINDER.setValue(this, values, value);
   }
 }
-
 }}}

 Here's a more interesting path, to show someone's boss's name. Note that  
the subscription will keyed directly to the boss entity, not to the  
e.MANAGER.DISPLAY_NAME path.


 {{{
-
 HasValue bossName = new TextField();

 requests.values.subscribe(e
   .newPathThrough(Employee.MANAGER)
   .through(Employee.DISPLAY_NAME)
   .to(bossName));
-
 }}}

 For list values, we assume a HasValueList interface, which looks a lot  
like John L's ListHandler.  (I'm cheating a bit, would really need both  
display name and id in the ListBox for this to be useful, but just to get  
the idea across):


 {{{
-
 HasValueList employeeList = new ListBox();

 requests.values.subscribe(
   requests.employees().findAllEmployees()
 .forProperty(Employee.DISPLAY_NAME)
 .newPathTo(employeeList));
-
 }}}
+
+When you need more than just one field for an object (or object list), the  
Values interface comes into play. It's basically a dedicated getter than  
can wrap any object managed by the value store:

+
+{{{
+HasValueList> employeeTable = new MyTableModel();
+
+requests.values.subscribe(
+  requests.employees().findAllEmployees()
+.forProperty(Employee.DISPLAY_NAME)
+.forProperty(Employee.USER_NAME)
+.newPathTo(employeeTable));
+ }}}

 = Employee.java =

@@ -136,7 +142,6 @@
 return version;
   }
 }
-
 }}}

 = Entity.java =
@@ -160,3 +165,12 @@
 }
 }}}

+= Values.java =
+
+{{{
+public interface Values {
+  E getEntity();
+

[gwt-contrib] [google-web-toolkit] r7655 committed - Edited wiki page through web user interface.

[codesite-noreply]

Revision: 7655
Author: rj...@google.com
Date: Wed Mar  3 15:29:49 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7655

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:29:14 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:29:49 2010
@@ -96,7 +96,7 @@
 .newPathTo(employeeList));
 }}}

-When you need more than just one field for an object (or object list), the  
Values interface comes into play. It's basically a dedicated getter than  
can wrap any object managed by the value store:
+When you need more than just one field for an object (or object list), the  
Values interface comes into play. It's basically a dedicated getter  
than can wrap any object managed by the value store:


 {{{
 HasValueList> employeeTable = new MyTableModel();

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: when-linker-added

[Lex Spoon]

On Wed, Mar 3, 2010 at 12:25 PM, Bruce Johnson  wrote:

> Is there some sort of lightweight design doc for this? I'm pretty sure I
> remember it being discussed somewhere, but we need a short writeup on the
> project wiki to capture the context.
>

Sure, will do.  The discussions preceding this patch are in several
different places.  I can summarize them on the wiki.

FWIW, the original discussion thread is here:

http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/ebca7dc3b6171ea9/0b7c699b5775c046?lnk=raot


The initial patch coming out of that discussion is here:

http://gwt-code-reviews.appspot.com/143811/show


Seeing the actual patch seems to have gotten people to really think about
the compatibility breakage involved in changing the primary linker
selection, as discussed here:

https://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/bd7936cd2f323484/87009f6a5c5b6606?lnk=raot&pli=1

Everyone then very quickly agreed to go back to when-linker-added, which is
this patch.  This one is a lot simpler and is better about compatibility.

Lex

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7656 committed - Edited wiki page through web user interface.

[codesite-noreply]

Revision: 7656
Author: rj...@google.com
Date: Wed Mar  3 15:30:21 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7656

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:29:49 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:30:21 2010
@@ -96,7 +96,7 @@
 .newPathTo(employeeList));
 }}}

-When you need more than just one field for an object (or object list), the  
Values interface comes into play. It's basically a dedicated getter  
than can wrap any object managed by the value store:
+When you need more than just one field for an object (or object list), the  
{{{Values}}} interface comes into play. It's basically a dedicated  
getter than can wrap any object managed by the value store:


 {{{
 HasValueList> employeeTable = new MyTableModel();

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7657 committed - Edited wiki page through web user interface.

[codesite-noreply]

Revision: 7657
Author: rj...@google.com
Date: Wed Mar  3 15:32:57 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7657

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:30:21 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:32:57 2010
@@ -153,7 +153,7 @@
 }
 }}}

-= HasValueList.java =
+= !HasValueList.java =

 {{{
 public interface HasValueList {

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7658 committed - Edited wiki page through web user interface.

[codesite-noreply]

Revision: 7658
Author: rj...@google.com
Date: Wed Mar  3 15:34:30 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7658

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:32:57 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:34:30 2010
@@ -74,7 +74,7 @@
 }
 }}}

-Here's a more interesting path, to show someone's boss's name. Note that  
the subscription will keyed directly to the boss entity, not to the  
e.MANAGER.DISPLAY_NAME path.
+Here's a more interesting path, to show someone's boss's name. Note that  
the subscription will be keyed directly to the boss entity, not to the  
e.MANAGER.DISPLAY_NAME path.


 {{{
 HasValue bossName = new TextField();

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7659 committed - Edited wiki page through web user interface.

[codesite-noreply]

Revision: 7659
Author: rj...@google.com
Date: Wed Mar  3 15:35:10 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7659

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:34:30 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:35:10 2010
@@ -2,7 +2,7 @@

 = Introduction =

-This not-quite-a-design-document sketches an approach to both data binding  
dealing with server side business objects from a GWT client. It builds on  
the discussion at ValueStoreAndRequestFactory and RequestFactorySketch2,  
and like them is too cryptic but better than nothing. For the first time, I  
think I have a complete proposal here, at least behind my eyeballs.
+This not-quite-a-design-document sketches an approach to both data binding  
and dealing with server side business objects from a GWT client. It builds  
on the discussion at ValueStoreAndRequestFactory and RequestFactorySketch2,  
and like them is too cryptic but better than nothing. For the first time, I  
think I have a complete proposal here, at least behind my eyeballs.


 Work is underway to build a prototype illustrating this scheme, which soon  
will find its way into the  
[http://code.google.com/p/google-web-toolkit/source/browse/trunk/bikeshed/README  
bikeshed].


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7660 committed - Edited wiki page through web user interface.

[codesite-noreply]

Revision: 7660
Author: rj...@google.com
Date: Wed Mar  3 15:36:27 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7660

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:35:10 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:36:27 2010
@@ -31,7 +31,7 @@

 Here's what's going on. {{{ExpensesRequestFactory}}} is an interface  
generated by a JPA-aware tool that trawled through the server side domain  
classes. The user then GWT.create()s an instance of it. A request factory  
provides builders that can create request objects corresponding to every  
service method on the server side domain layer.


-(The intention is that we provide the tool. Presumably we could provide  
similar tools for other persistence frameworks. JPA just happens to be a  
good choice for both Roo and GAE.)
+(The intention is that we provide the tool. Presumably we could provide  
similar tools for other persistence frameworks. JPA just happens to be a  
good choice for GAE.)


 In this example, {{{employees().findEmployee(e.getId())}}} is creating an  
instance of a request object. That's important: findEmployee() isn't an rpc  
call, it's a factory call to create an instance of something like  
FindEmployeeRequest. Later on that will go over the wire to be interpreted  
by the server, probably as part of a batch at the end of the current  
eventloop.


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7661 committed - Edited wiki page through web user interface.

[codesite-noreply]

Revision: 7661
Author: rj...@google.com
Date: Wed Mar  3 15:37:27 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7661

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:36:27 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:37:27 2010
@@ -12,7 +12,7 @@

 = Details =

-I've backed away from the souped up EventBus approach posted last week and  
am back to data being pushed directly from the ValueStore to HasValue and  
HasValueList subscribers. The new piece of the puzzle is Path objects,  
which accompany request objects to the server and tell it just which data  
we actually want returned.
+I've backed away from the souped up EventBus approach posted  
[RequestFactorySketch2 last week] and am back to data being pushed directly  
from the ValueStore to HasValue and HasValueList subscribers. The new piece  
of the puzzle is Path objects, which accompany request objects to the  
server and tell it just which data we actually want returned.


 Still unaddressed is how plain old client side Beans / model objects can  
take advantage of the data binding here without drowning them in  
boilerplate, but I take it as a given that we can and should make that  
work. It also seems likely that a lot of the builder style runtime  
construction that's happening here could (should) be happening at compile  
time instead. TBD.


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7662 committed - Edited wiki page through web user interface.

[codesite-noreply]

Revision: 7662
Author: rj...@google.com
Date: Wed Mar  3 15:37:51 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7662

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:37:27 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:37:51 2010
@@ -12,7 +12,7 @@

 = Details =

-I've backed away from the souped up EventBus approach posted  
[RequestFactorySketch2 last week] and am back to data being pushed directly  
from the ValueStore to HasValue and HasValueList subscribers. The new piece  
of the puzzle is Path objects, which accompany request objects to the  
server and tell it just which data we actually want returned.
+I've backed away from the [RequestFactorySketch2 souped up EventBus]  
approach posted last week and am back to data being pushed directly from  
the ValueStore to HasValue and HasValueList subscribers. The new piece of  
the puzzle is Path objects, which accompany request objects to the server  
and tell it just which data we actually want returned.


 Still unaddressed is how plain old client side Beans / model objects can  
take advantage of the data binding here without drowning them in  
boilerplate, but I take it as a given that we can and should make that  
work. It also seems likely that a lot of the builder style runtime  
construction that's happening here could (should) be happening at compile  
time instead. TBD.


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] [google-web-toolkit] r7663 committed - Edited wiki page through web user interface.

[codesite-noreply]

Revision: 7663
Author: rj...@google.com
Date: Wed Mar  3 15:39:01 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7663

Modified:
 /wiki/RequestFactoryPlusPaths.wiki

===
--- /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:37:51 2010
+++ /wiki/RequestFactoryPlusPaths.wiki  Wed Mar  3 15:39:01 2010
@@ -12,7 +12,7 @@

 = Details =

-I've backed away from the [RequestFactorySketch2 souped up EventBus]  
approach posted last week and am back to data being pushed directly from  
the ValueStore to HasValue and HasValueList subscribers. The new piece of  
the puzzle is Path objects, which accompany request objects to the server  
and tell it just which data we actually want returned.
+I've backed away from the [RequestFactorySketch2 souped up EventBus  
approach] posted last week and am back to data being pushed directly from  
the ValueStore to HasValue and HasValueList subscribers. The new piece of  
the puzzle is Path objects, which accompany request objects to the server  
and tell it just which data we actually want returned.


 Still unaddressed is how plain old client side Beans / model objects can  
take advantage of the data binding here without drowning them in  
boilerplate, but I take it as a given that we can and should make that  
work. It also seems likely that a lot of the builder style runtime  
construction that's happening here could (should) be happening at compile  
time instead. TBD.


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Comment on RequestFactoryPlusPaths in google-web-toolkit

[codesite-noreply]

Comment by cromwell...@google.com:

Two Questions: 1) Would Open Graph Native Language help? (OGNL). If we have  
enhanced GWT.create() with @GwtCreate, you could write through("ognl  
expression") which would invoke a generator to parse the OGNL expression  
and replace it with Java code.


2) Those Property objects or Employee, could we somehow leave the  
initialization of them out (just declare them) and have some other class do  
the "new Property" injection?




For more information:
http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryPlusPaths

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit

[codesite-noreply]

Comment by rj...@google.com:

These sound like questions I would ask you.

OGNL is kind of heavy, I think. It wants to be able to execute methods with  
arguments and all kinds of things. But yeah, moving this away from runtime  
and to compile time sounds great. But my brain is full.





For more information:
http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryPlusPaths

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit

[codesite-noreply]

Comment by rj...@google.com:

Hmmm. On the other hand, so far paths seem to be entirely for server side  
consumption. Client side you subscribe to the entity field at the last hop  
on the path, I hope.


So you declare me.boss.displayName on the client. That goes to the server  
and comes back as, effectively, Employee{id: bossId, version: bossVersion}.  
The subscriber is tied to bossId+DISPLAY_NAME, not me.boss.displayName.  
Later when someone else in the app updates the employee with id=bossId,  
I'll hear about it because that's the key to my subscription. I *think*  
that could still work with the ognl-on-the-server approach?


The usual complaint about OGNL is that it throws type safety out the  
window, but that needn't be true for us, presuming the code generator has  
access to server types. If we're willing to fail on polymorphism.


Or, perhaps value store subscriptions *are* keyed by path. But then I think  
we'll wind up with redundant values. How can I tell that  
findAllEmployees()[25] is the same as Employee{id: bossId}? I'm counting on  
being able to use the ValueStore as a cache, and avoid emitting redundant  
rpc calls. Can that work in this more webwork-like world we're describing?



For more information:
http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryPlusPaths

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors