[gwt-contrib] Re: RR: visibility logic management

[Ian Petersen]

On Thu, Oct 9, 2008 at 2:04 PM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
> I really like your suggestions for the way the panel and layout rules
> should work. I'm not really sure about creating a new widget
> hierarchy, though. My initial goal was to allow developers to use any
> widget they like and not use some new widget hierarchy. Getting data
> out of the widgets can either be handled through the HasValue
> interface or using DataManagers as a stop gap for GWT core widgets.
> Otherwise, I would hope it could work with any widget type.

+1 to not creating a new widget hierarchy.  It _might_ make sense to
add a new (hierarchy of) interface(s), and maybe some kind of wrapper
widget type that can map arbitrary widgets into the interface
hierarchy, but, on the face of it, I don't think a CheckBoxQuestion
provides much value.

Ian

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

[gwt-contrib] Re: [google-web-toolkit commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl

[Scott Blum]

LGTM.

Minor: In Pruner, it strikes me that you shouldn't have to do this.  Perhaps
most of the code in visit(JMethodCall) should be moved into visit(JMethod)

BTW: your patch name is teh lolz. :)

Scott

On Thu, Oct 9, 2008 at 6:25 PM, Lex Spoon <[EMAIL PROTECTED]> wrote:

> Thanks, Scott.
> The patch should apply to trunk.  Would you mind it going into trunk if it
> looks good?  I'll merge it over to the runAsync branch the next time I sync
> it with trunk.
>
> The linear search you point at does not look so good on closer inspection.
>  For each method in the program, there is a linear search through all the
> *entry* methods of the program. That's okay right now, but if there are ever
> a lot of entry methods, it could get expensive.
>
> Attached is an update that is just like the previous one, but it replaces
> the linear scan by a lookup in an IdentityHashMap.
>
> -Lex
>
>

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

[gwt-contrib] code review requested for 1.5 branch, FF3 getAbsoluteTop/Left

[John Tamplin]

On FF3, these routines can return a non-integer, which can result in
warnings in hosted mode (seen with OOPHM) and potential errors in web mode
as the function is declared to return an int.  The fix is to coerce the
value to int in the FF3 code-path.  This may also be related to issue
2891
.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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

Index: user/src/com/google/gwt/dom/client/DOMImplMozilla.java
===
--- user/src/com/google/gwt/dom/client/DOMImplMozilla.java	(revision 3731)
+++ user/src/com/google/gwt/dom/client/DOMImplMozilla.java	(working copy)
@@ -27,8 +27,8 @@
 // supported on older versions). If changing this code, make sure to check
 // the museum entry for issue 1932.
 if (Element.prototype.getBoundingClientRect) {
-  return elem.getBoundingClientRect().left +
-@com.google.gwt.user.client.impl.DocumentRootImpl::documentRoot.scrollLeft;
+  return (elem.getBoundingClientRect().left +
+@com.google.gwt.user.client.impl.DocumentRootImpl::documentRoot.scrollLeft) | 0;
 } else {
   // We cannot use DOMImpl here because offsetLeft/Top return erroneous
   // values when overflow is not visible.  We have to difference screenX
@@ -47,8 +47,8 @@
 // supported on older versions). If changing this code, make sure to check
 // the museum entry for issue 1932.
 if (Element.prototype.getBoundingClientRect) {
-  return elem.getBoundingClientRect().top +
-@com.google.gwt.user.client.impl.DocumentRootImpl::documentRoot.scrollTop;
+  return (elem.getBoundingClientRect().top +
+@com.google.gwt.user.client.impl.DocumentRootImpl::documentRoot.scrollTop) | 0;
 } else {
   // We cannot use DOMImpl here because offsetLeft/Top return erroneous
   // values when overflow is not visible.  We have to difference screenX

[gwt-contrib] code review requested for 1.5 branch, RPC quoting, issues 1137, 1906, and more

[John Tamplin]

The attached patch, relative to releases/1.5 r3731, fixes a number of RPC
quoting issues and adds more robust tests.  In addition to the listed
issues, this fixes problems with RPC working at all in the Android WebKit
browser, or for sending serialized responses via IE form post (which mangles
the U+ separator character).  Also, some plugins for OOPHM run into
problems using the U+ character.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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

Index: user/test/com/google/gwt/user/server/rpc/UnicodeEscapingServiceImpl.java
===
--- user/test/com/google/gwt/user/server/rpc/UnicodeEscapingServiceImpl.java	(revision 3731)
+++ user/test/com/google/gwt/user/server/rpc/UnicodeEscapingServiceImpl.java	(working copy)
@@ -16,6 +16,7 @@
 package com.google.gwt.user.server.rpc;
 
 import com.google.gwt.user.client.rpc.UnicodeEscapingService;
+import com.google.gwt.user.client.rpc.UnicodeEscapingTest;
 
 /**
  * Implementation of the [EMAIL PROTECTED] UnicodeEscapingService} interface. 
@@ -24,18 +25,18 @@
 UnicodeEscapingService {
 
   /**
-   * @see com.google.gwt.user.client.rpc.UnicodeEscapingService#getStringContainingCharacterRange(int,
-   *  int)
+   * @see UnicodeEscapingService#getStringContainingCharacterRange(int, int)
*/
   public String getStringContainingCharacterRange(int start, int end) {
-int nChars = end - start;
-  
-char[] chars = new char[nChars];
-for (int i = 0; i < nChars; ++i) {
-  char ch = (char) (start + i);
-  chars[i] = ch;
-}
+return UnicodeEscapingTest.getStringContainingCharacterRange(start, end);
+  }
 
-return new String(chars);
+  /**
+   * @see UnicodeEscapingService#verifyStringContainingCharacterRange(int, int, String)
+   */
+  public boolean verifyStringContainingCharacterRange(int start, int end,
+  String str) throws InvalidCharacterException {
+UnicodeEscapingTest.verifyStringContainingCharacterRange(start, end, str);
+return true;
   }
 }
Index: user/test/com/google/gwt/user/server/rpc/RPCTest.java
===
--- user/test/com/google/gwt/user/server/rpc/RPCTest.java	(revision 3731)
+++ user/test/com/google/gwt/user/server/rpc/RPCTest.java	(working copy)
@@ -15,10 +15,14 @@
  */
 package com.google.gwt.user.server.rpc;
 
+import static com.google.gwt.user.client.rpc.impl.AbstractSerializationStream.RPC_SEPARATOR_CHAR;
+
 import com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException;
 import com.google.gwt.user.client.rpc.RemoteService;
 import com.google.gwt.user.client.rpc.SerializableException;
 import com.google.gwt.user.client.rpc.SerializationException;
+import com.google.gwt.user.client.rpc.impl.AbstractSerializationStream;
+import com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader;
 
 import junit.framework.TestCase;
 
@@ -27,6 +31,7 @@
 /**
  * Tests for the [EMAIL PROTECTED] com.google.gwt.user.server.rpc.RPC RPC} class.
  */
[EMAIL PROTECTED]("deprecation")
 public class RPCTest extends TestCase {
 
   private static interface A extends RemoteService {
@@ -41,60 +46,97 @@
 void method1();
   }
 
-  private static final String VALID_ENCODED_REQUEST = "4\u" + // version
-  "0\u" + // flags
-  "4\u" + // string table entry count
-  A.class.getName() + "\u" + // string table entry #0
-  "method2" + "\u" + // string table entry #1
-  "moduleBaseURL" + "\u" + // string table entry #2
-  "whitelistHashcode" + "\u" + // string table entry #4
-  "3\u" + // module base URL
-  "4\u" + // whitelist hashcode
-  "1\u" + // interface name
-  "2\u" + // method name
-  "0\u"; // param count
+  private static final String VALID_ENCODED_REQUEST = "" +
+  AbstractSerializationStream.SERIALIZATION_STREAM_VERSION +
+  RPC_SEPARATOR_CHAR + // version
+  "0" + RPC_SEPARATOR_CHAR + // flags
+  "4" + RPC_SEPARATOR_CHAR + // string table entry count
+  A.class.getName() + RPC_SEPARATOR_CHAR + // string table entry #1
+  "method2" + RPC_SEPARATOR_CHAR + // string table entry #2
+  "moduleBaseURL" + RPC_SEPARATOR_CHAR + // string table entry #3
+  "whitelistHashcode" + RPC_SEPARATOR_CHAR + // string table entry #4
+  "3" + RPC_SEPARATOR_CHAR + // module base URL
+  "4" + RPC_SEPARATOR_CHAR + // whitelist hashcode
+  "1" + RPC_SEPARATOR_CHAR + // interface name
+  "2" + RPC_SEPARATOR_CHAR + // method name
+  "0" + RPC_SEPARATOR_CHAR; // param count
 
-  private static final String INVALID_METHOD_REQUEST = "4\u" + // version
+  private static final String INVALID_METHOD_REQUEST = "" +
+  AbstractSerializationStream.SERIALIZATION_STREAM_VERSION +
+  RPC_SEP

[gwt-contrib] Re: [google-web-toolkit commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl

[Lex Spoon]

Thanks, Scott.
The patch should apply to trunk.  Would you mind it going into trunk if it
looks good?  I'll merge it over to the runAsync branch the next time I sync
it with trunk.

The linear search you point at does not look so good on closer inspection.
 For each method in the program, there is a linear search through all the
*entry* methods of the program. That's okay right now, but if there are ever
a lot of entry methods, it could get expensive.

Attached is an update that is just like the previous one, but it replaces
the linear scan by a lookup in an IdentityHashMap.

-Lex

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



allMethodsHaveClass2-r3732.patch
Description: Binary data

[gwt-contrib] [google-web-toolkit commit] r3733 - releases/1.6

[codesite-noreply]

Author: [EMAIL PROTECTED]
Date: Thu Oct  9 14:59:31 2008
New Revision: 3733

Added:
releases/1.6/branch-info.txt   (contents, props changed)

Log:
Creating branch info for releases/1.6.

Added: releases/1.6/branch-info.txt
==
--- (empty file)
+++ releases/1.6/branch-info.txtThu Oct  9 14:59:31 2008
@@ -0,0 +1,9 @@
+branch-info.txt for GWT 1.6 release:
+Tracks interactions between this branch and other branches.
+See: http://code.google.com/p/google-web-toolkit/wiki/ManagingMerges
+
+Copies:
+/releases/1.6/ was created (r3732) as a straight copy from /trunk/@r3683
+
+Merges:
+---> The next merge into trunk is not yet determined, we will need to skip  
a few revisions to first back-port changes from trunk.

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

[gwt-contrib] Re: Flurry of Data binding threads

[Isaac Truett]

Absolutely. I think we may be vehemently agreeing with each other here.

On Thu, Oct 9, 2008 at 5:45 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:

> That is true, as the answer "never" is certainly too simplistic.
>
> The  point is that the primary use case of HasValue is not to bind data
> objects to widgets, but to allow widgets to provide an easy to use interface
> for other systems.  As the data binder should not have to care what the
> physical widget type is as long as it knows what type of value the widget
> can set and get.
>
>
>
>
>
>
> On Thu, Oct 9, 2008 at 5:32 PM, Ray Cromwell <[EMAIL PROTECTED]>wrote:
>
>>
>> There may be cases where this is permissible. For example, a MapWidget
>> might return LatLng objects, rather than having a Long and Lat field
>> which are separately bound.  In the context of OpenSocial or GData, I
>> could see a common reusable widget for picking from your network that
>> would naturally return something like a Person. The reason it might do
>> this, is because the binding itself might be overly complex. The
>> widget might present friends in a tree of groups, allow search, pull
>> from multiple networks. In general, the internal state of the widget
>> might be too complex to expose for binding to via getter methods.
>>
>> -Ray
>>
>>
>> On Thu, Oct 9, 2008 at 2:23 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>> > Would you normally have a UI widget as specific as a person picker?
>>  That
>> > seems like the model (a person) and the widget displaying the person
>> might
>> > be a bit too closely bound, and we'd rather that binding took place
>> using
>> > some sort of data binding solution.
>> >
>> > The reason for this distinction is to make it clear that the HasValue
>> > interface is not designed to be a data-binding solution, it is designed
>> to
>> > enable other people to create data binding solutions.
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Oct 9, 2008 at 4:55 PM, Isaac Truett <[EMAIL PROTECTED]> wrote:
>> >>
>> >> [+gwt-c]
>> >>
>> >> -- Forwarded message --
>> >>
>> >> > Accordingly, HasValue should only ever be used for simple leaf types
>> on
>> >> > leaf widgets.
>> >>
>> >> I think I object to issue with this statement, but first I'd like to
>> see a
>> >> definition of "leaf" types and widgets. By leaf type, I assume you mean
>> >> primitive wrapper classes and String, but why is Date thrown in there?
>> Why
>> >> would DatePicker implements HasValue be acceptable but not
>> >> PersonPicker implements HasValue? What's to be gained by
>> >> discouraging HasValue for complex data types?
>> >>
>> >>
>> >>
>> >> On Thu, Oct 9, 2008 at 4:15 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>> >>>
>> >>> To give you an idea of where I am coming from, here is my
>> understanding
>> >>> of the world:
>> >>>
>> >>> Metadata Systems, comprising Models and Controllers
>> >>> xforms, Ian's databinding system, Arthur's validation system, gwt
>> team's
>> >>> upcoming proposal for data management:
>> >>>
>> >>> All part of the larger metadata, binding, code generation class of
>> >>> systems. Hopefully all of these can eventually use the same basic
>> concepts
>> >>> and it going to be a huge undertaking to get it right. In fact, so
>> huge of
>> >>> one that the gwt team has decided to duck for now and are trying very
>> hard
>> >>> not to get involved in these discusions at the current time.
>> >>>
>> >>>
>> >>> Widget bridge classes, part of the application's view.
>> >>> Classes used to expose the application's view to the meta data
>> systems.
>> >>>
>> >>> HasValue:  Provides the bridge between the metadata model and the
>> world
>> >>> of widgets. From the meta data system's point of view it has some way
>> of
>> >>> creating/linking with instances of HasValue,
>> HasValue,
>> >>> HasValue, etc..
>> >>>
>> >>> From the widgets point of view, we have a whole bunch of text boxes,
>> text
>> >>> areas, date pickers, etc. on the page.
>> >>>
>> >>> Accordingly, HasValue should only ever be used for simple leaf types
>> on
>> >>> leaf widgets.
>> >>>
>> >>> EventHandlers: Provides a way for the meta data system controllers to
>> add
>> >>> callbacks to react to widget changes.
>> >>>
>> >>>
>> 
>>  -Ray
>> 
>> 
>> 
>>  On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
>>  > We all seem to be talking about data binding and validation a lot,
>> and
>>  > some
>>  > of us are even implementing code about it. We on the GWT team hear
>> the
>>  > need
>>  > and feel it ourselves.
>>  >
>>  > We have some notions of how we'd like to tackle this in a way that
>>  > blends
>>  > seamlessly with the rest of GWT, and are looking to start design
>> and
>>  > implementation in earnest before the year is out. This makes it
>>  > unlikely
>>  > that we'll accept core or incubator patches that implement such a
>>  > system.
>>  > That said, we don't want to shoot down the e

[gwt-contrib] [google-web-toolkit commit] r3732 - releases/1.6

[codesite-noreply]

Author: [EMAIL PROTECTED]
Date: Thu Oct  9 14:46:38 2008
New Revision: 3732

Added:
releases/1.6/
   - copied from r3683, /trunk/

Log:
Creating 1.6 release branch based on [EMAIL PROTECTED]



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

[gwt-contrib] Re: Flurry of Data binding threads

[Emily Crutcher]

That is true, as the answer "never" is certainly too simplistic.

The  point is that the primary use case of HasValue is not to bind data
objects to widgets, but to allow widgets to provide an easy to use interface
for other systems.  As the data binder should not have to care what the
physical widget type is as long as it knows what type of value the widget
can set and get.





On Thu, Oct 9, 2008 at 5:32 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:

>
> There may be cases where this is permissible. For example, a MapWidget
> might return LatLng objects, rather than having a Long and Lat field
> which are separately bound.  In the context of OpenSocial or GData, I
> could see a common reusable widget for picking from your network that
> would naturally return something like a Person. The reason it might do
> this, is because the binding itself might be overly complex. The
> widget might present friends in a tree of groups, allow search, pull
> from multiple networks. In general, the internal state of the widget
> might be too complex to expose for binding to via getter methods.
>
> -Ray
>
>
> On Thu, Oct 9, 2008 at 2:23 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> > Would you normally have a UI widget as specific as a person picker?  That
> > seems like the model (a person) and the widget displaying the person
> might
> > be a bit too closely bound, and we'd rather that binding took place using
> > some sort of data binding solution.
> >
> > The reason for this distinction is to make it clear that the HasValue
> > interface is not designed to be a data-binding solution, it is designed
> to
> > enable other people to create data binding solutions.
> >
> >
> >
> >
> >
> > On Thu, Oct 9, 2008 at 4:55 PM, Isaac Truett <[EMAIL PROTECTED]> wrote:
> >>
> >> [+gwt-c]
> >>
> >> -- Forwarded message --
> >>
> >> > Accordingly, HasValue should only ever be used for simple leaf types
> on
> >> > leaf widgets.
> >>
> >> I think I object to issue with this statement, but first I'd like to see
> a
> >> definition of "leaf" types and widgets. By leaf type, I assume you mean
> >> primitive wrapper classes and String, but why is Date thrown in there?
> Why
> >> would DatePicker implements HasValue be acceptable but not
> >> PersonPicker implements HasValue? What's to be gained by
> >> discouraging HasValue for complex data types?
> >>
> >>
> >>
> >> On Thu, Oct 9, 2008 at 4:15 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> >>>
> >>> To give you an idea of where I am coming from, here is my understanding
> >>> of the world:
> >>>
> >>> Metadata Systems, comprising Models and Controllers
> >>> xforms, Ian's databinding system, Arthur's validation system, gwt
> team's
> >>> upcoming proposal for data management:
> >>>
> >>> All part of the larger metadata, binding, code generation class of
> >>> systems. Hopefully all of these can eventually use the same basic
> concepts
> >>> and it going to be a huge undertaking to get it right. In fact, so huge
> of
> >>> one that the gwt team has decided to duck for now and are trying very
> hard
> >>> not to get involved in these discusions at the current time.
> >>>
> >>>
> >>> Widget bridge classes, part of the application's view.
> >>> Classes used to expose the application's view to the meta data systems.
> >>>
> >>> HasValue:  Provides the bridge between the metadata model and the world
> >>> of widgets. From the meta data system's point of view it has some way
> of
> >>> creating/linking with instances of HasValue, HasValue,
> >>> HasValue, etc..
> >>>
> >>> From the widgets point of view, we have a whole bunch of text boxes,
> text
> >>> areas, date pickers, etc. on the page.
> >>>
> >>> Accordingly, HasValue should only ever be used for simple leaf types on
> >>> leaf widgets.
> >>>
> >>> EventHandlers: Provides a way for the meta data system controllers to
> add
> >>> callbacks to react to widget changes.
> >>>
> >>>
> 
>  -Ray
> 
> 
> 
>  On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
>  > We all seem to be talking about data binding and validation a lot,
> and
>  > some
>  > of us are even implementing code about it. We on the GWT team hear
> the
>  > need
>  > and feel it ourselves.
>  >
>  > We have some notions of how we'd like to tackle this in a way that
>  > blends
>  > seamlessly with the rest of GWT, and are looking to start design and
>  > implementation in earnest before the year is out. This makes it
>  > unlikely
>  > that we'll accept core or incubator patches that implement such a
>  > system.
>  > That said, we don't want to shoot down the excellent work that's
> being
>  > done!
>  > If you have a system that's shaping up to meet your needs and that
> you
>  > want
>  > to share with the GWT community, please do!  Set up a Google Code
>  > project,
>  > announce it here, embarrass us by shipping first and attracting a

[gwt-contrib] Re: [google-web-toolkit commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl

[Scott Blum]

Looking at the patch file, looks good, though I didn't patch it into a copy
of your branch.
One thing: are you doing a linear search GenerateJavaAST multiplied by the
number of functions in the program?

On Tue, Oct 7, 2008 at 2:26 PM, Scott Blum <[EMAIL PROTECTED]> wrote:

> Will review.
>
>
> On Tue, Oct 7, 2008 at 12:22 PM, Lex Spoon <[EMAIL PROTECTED]> wrote:
>
>> Okay, here is a patch that gives the bootstrap entry method an
>> enclosing class.  It went together simply; I simply updated all
>> references to JProgram.entryMethods.  The one non-trivial part was
>> GenerateJavaScriptAST, which used to pick up entry methods by looking
>> at the first (or last?) thing that a JProgram visits.  Now the entry
>> methods get seen at difficult to predict times during the traversal of
>> the JProgram, so GenerateJavaScriptAST has an array to record them as
>> they come by.  It turns out this is the only method I could find that
>> does not have an enclosing class, so the patch includes an assert.
>>
>> I ended up not adding a single entry class, because it would cause
>> awkwardness for the runAsync entry methods.  Each runAsync call
>> generates a class with multiple methods, and one of those methods is
>> an entry method.  To have a single entry class, that method would have
>> to be moved over to the entry class, and so the standard generator
>> framework wouldn't work out of the box.  So, I left it be for now.
>>
>> Can you review it, Scott, or pass it to someone?
>>
>>
>> -Lex
>>
>
>

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

[gwt-contrib] Re: Flurry of Data binding threads

[Ray Cromwell]

There may be cases where this is permissible. For example, a MapWidget
might return LatLng objects, rather than having a Long and Lat field
which are separately bound.  In the context of OpenSocial or GData, I
could see a common reusable widget for picking from your network that
would naturally return something like a Person. The reason it might do
this, is because the binding itself might be overly complex. The
widget might present friends in a tree of groups, allow search, pull
from multiple networks. In general, the internal state of the widget
might be too complex to expose for binding to via getter methods.

-Ray


On Thu, Oct 9, 2008 at 2:23 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> Would you normally have a UI widget as specific as a person picker?  That
> seems like the model (a person) and the widget displaying the person might
> be a bit too closely bound, and we'd rather that binding took place using
> some sort of data binding solution.
>
> The reason for this distinction is to make it clear that the HasValue
> interface is not designed to be a data-binding solution, it is designed to
> enable other people to create data binding solutions.
>
>
>
>
>
> On Thu, Oct 9, 2008 at 4:55 PM, Isaac Truett <[EMAIL PROTECTED]> wrote:
>>
>> [+gwt-c]
>>
>> -- Forwarded message --
>>
>> > Accordingly, HasValue should only ever be used for simple leaf types on
>> > leaf widgets.
>>
>> I think I object to issue with this statement, but first I'd like to see a
>> definition of "leaf" types and widgets. By leaf type, I assume you mean
>> primitive wrapper classes and String, but why is Date thrown in there? Why
>> would DatePicker implements HasValue be acceptable but not
>> PersonPicker implements HasValue? What's to be gained by
>> discouraging HasValue for complex data types?
>>
>>
>>
>> On Thu, Oct 9, 2008 at 4:15 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>>>
>>> To give you an idea of where I am coming from, here is my understanding
>>> of the world:
>>>
>>> Metadata Systems, comprising Models and Controllers
>>> xforms, Ian's databinding system, Arthur's validation system, gwt team's
>>> upcoming proposal for data management:
>>>
>>> All part of the larger metadata, binding, code generation class of
>>> systems. Hopefully all of these can eventually use the same basic concepts
>>> and it going to be a huge undertaking to get it right. In fact, so huge of
>>> one that the gwt team has decided to duck for now and are trying very hard
>>> not to get involved in these discusions at the current time.
>>>
>>>
>>> Widget bridge classes, part of the application's view.
>>> Classes used to expose the application's view to the meta data systems.
>>>
>>> HasValue:  Provides the bridge between the metadata model and the world
>>> of widgets. From the meta data system's point of view it has some way of
>>> creating/linking with instances of HasValue, HasValue,
>>> HasValue, etc..
>>>
>>> From the widgets point of view, we have a whole bunch of text boxes, text
>>> areas, date pickers, etc. on the page.
>>>
>>> Accordingly, HasValue should only ever be used for simple leaf types on
>>> leaf widgets.
>>>
>>> EventHandlers: Provides a way for the meta data system controllers to add
>>> callbacks to react to widget changes.
>>>
>>>

 -Ray



 On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
 > We all seem to be talking about data binding and validation a lot, and
 > some
 > of us are even implementing code about it. We on the GWT team hear the
 > need
 > and feel it ourselves.
 >
 > We have some notions of how we'd like to tackle this in a way that
 > blends
 > seamlessly with the rest of GWT, and are looking to start design and
 > implementation in earnest before the year is out. This makes it
 > unlikely
 > that we'll accept core or incubator patches that implement such a
 > system.
 > That said, we don't want to shoot down the excellent work that's being
 > done!
 > If you have a system that's shaping up to meet your needs and that you
 > want
 > to share with the GWT community, please do!  Set up a Google Code
 > project,
 > announce it here, embarrass us by shipping first and attracting a user
 > base. We'll probably steal from you shamelessly and ask for your help
 > as our
 > own system takes shape.
 > I hope this doesn't ruffle any feathers, and that you'll understand
 > why we
 > haven't been as responsive on some of these threads as we should have
 > been.
 > Thanks,
 > rjrjr
 >
 >
 > >
 >


>>>
>>>
>>>
>>> --
>>> "There are only 10 types of people in the world: Those who understand
>>> binary, and those who don't"
>>
>>
>>
>>
>
>
>
> --
> "There are only 10 types of people in the world: Those who understand
> binary, and those who don't"
>
> >
>

--~--~-~--~~~---~--~~
http://

[gwt-contrib] Re: Flurry of Data binding threads

[Emily Crutcher]

Would you normally have a UI widget as specific as a person picker?  That
seems like the model (a person) and the widget displaying the person might
be a bit too closely bound, and we'd rather that binding took place using
some sort of data binding solution.

The reason for this distinction is to make it clear that the HasValue
interface is not designed to be a data-binding solution, it is designed to
enable* other* people to create data binding solutions.





On Thu, Oct 9, 2008 at 4:55 PM, Isaac Truett <[EMAIL PROTECTED]> wrote:

> [+gwt-c]
>
> -- Forwarded message --
>
> > Accordingly, HasValue should only ever be used for simple leaf types on
> leaf widgets.
>
> I think I object to issue with this statement, but first I'd like to see a
> definition of "leaf" types and widgets. By leaf type, I assume you mean
> primitive wrapper classes and String, but why is Date thrown in there? Why
> would DatePicker implements HasValue be acceptable but not
> PersonPicker implements HasValue? What's to be gained by
> discouraging HasValue for complex data types?
>
>
>
>
> On Thu, Oct 9, 2008 at 4:15 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> To give you an idea of where I am coming from, here is my understanding of
>> the world:
>>
>> *Metadata Systems, comprising Models and Controllers*
>> xforms, Ian's databinding system, Arthur's validation system, gwt team's
>> upcoming proposal for data management:
>>
>> All part of the larger metadata, binding, code generation class of
>> systems. Hopefully all of these can eventually use the same basic concepts
>> and it going to be a huge undertaking to get it right. In fact, so huge of
>> one that the gwt team has decided to duck for now and are trying very hard
>> not to get involved in these discusions at the current time.
>>
>>
>> *Widget bridge classes, part of the application's view.*
>> Classes used to expose the application's view to the meta data systems.
>>
>> *HasValue*:  Provides the bridge between the metadata model and the world
>> of widgets. From the meta data system's point of view it has some way of
>> creating/linking with instances of HasValue, HasValue,
>> HasValue, etc..
>>
>> From the widgets point of view, we have a whole bunch of text boxes, text
>> areas, date pickers, etc. on the page.
>>
>> Accordingly, HasValue should only ever be used for simple leaf types on
>> leaf widgets.
>>
>> *EventHandlers*: Provides a way for the meta data system controllers to
>> add callbacks to react to widget changes.
>>
>>
>>
>>>
>>> -Ray
>>>
>>>
>>>
>>> On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
>>> > We all seem to be talking about data binding and validation a lot, and
>>> some
>>> > of us are even implementing code about it. We on the GWT team hear the
>>> need
>>> > and feel it ourselves.
>>> >
>>> > We have some notions of how we'd like to tackle this in a way that
>>> blends
>>> > seamlessly with the rest of GWT, and are looking to start design and
>>> > implementation in earnest before the year is out. This makes it
>>> unlikely
>>> > that we'll accept core or incubator patches that implement such a
>>> system.
>>> > That said, we don't want to shoot down the excellent work that's being
>>> done!
>>> > If you have a system that's shaping up to meet your needs and that you
>>> want
>>> > to share with the GWT community, please do!  Set up a Google Code
>>> project,
>>> > announce it here, embarrass us by shipping first and attracting a user
>>> > base. We'll probably steal from you shamelessly and ask for your help
>>> as our
>>> > own system takes shape.
>>> > I hope this doesn't ruffle any feathers, and that you'll understand why
>>> we
>>> > haven't been as responsive on some of these threads as we should have
>>> been.
>>> > Thanks,
>>> > rjrjr
>>> >
>>> >
>>> > >
>>> >
>>>
>>>
>>>
>>
>>
>> --
>> "There are only 10 types of people in the world: Those who understand
>> binary, and those who don't"
>>
>
>
>
> >
>


-- 
"There are only 10 types of people in the world: Those who understand
binary, and those who don't"

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

[gwt-contrib] Flurry of Data binding threads

[Isaac Truett]

[+gwt-c]

-- Forwarded message --

> Accordingly, HasValue should only ever be used for simple leaf types on
leaf widgets.

I think I object to issue with this statement, but first I'd like to see a
definition of "leaf" types and widgets. By leaf type, I assume you mean
primitive wrapper classes and String, but why is Date thrown in there? Why
would DatePicker implements HasValue be acceptable but not
PersonPicker implements HasValue? What's to be gained by
discouraging HasValue for complex data types?




On Thu, Oct 9, 2008 at 4:15 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:

> To give you an idea of where I am coming from, here is my understanding of
> the world:
>
> *Metadata Systems, comprising Models and Controllers*
> xforms, Ian's databinding system, Arthur's validation system, gwt team's
> upcoming proposal for data management:
>
> All part of the larger metadata, binding, code generation class of systems.
> Hopefully all of these can eventually use the same basic concepts and it
> going to be a huge undertaking to get it right. In fact, so huge of one that
> the gwt team has decided to duck for now and are trying very hard not to get
> involved in these discusions at the current time.
>
>
> *Widget bridge classes, part of the application's view.*
> Classes used to expose the application's view to the meta data systems.
>
> *HasValue*:  Provides the bridge between the metadata model and the world
> of widgets. From the meta data system's point of view it has some way of
> creating/linking with instances of HasValue, HasValue,
> HasValue, etc..
>
> From the widgets point of view, we have a whole bunch of text boxes, text
> areas, date pickers, etc. on the page.
>
> Accordingly, HasValue should only ever be used for simple leaf types on
> leaf widgets.
>
> *EventHandlers*: Provides a way for the meta data system controllers to
> add callbacks to react to widget changes.
>
>
>
>>
>> -Ray
>>
>>
>>
>> On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
>> > We all seem to be talking about data binding and validation a lot, and
>> some
>> > of us are even implementing code about it. We on the GWT team hear the
>> need
>> > and feel it ourselves.
>> >
>> > We have some notions of how we'd like to tackle this in a way that
>> blends
>> > seamlessly with the rest of GWT, and are looking to start design and
>> > implementation in earnest before the year is out. This makes it unlikely
>> > that we'll accept core or incubator patches that implement such a
>> system.
>> > That said, we don't want to shoot down the excellent work that's being
>> done!
>> > If you have a system that's shaping up to meet your needs and that you
>> want
>> > to share with the GWT community, please do!  Set up a Google Code
>> project,
>> > announce it here, embarrass us by shipping first and attracting a user
>> > base. We'll probably steal from you shamelessly and ask for your help as
>> our
>> > own system takes shape.
>> > I hope this doesn't ruffle any feathers, and that you'll understand why
>> we
>> > haven't been as responsive on some of these threads as we should have
>> been.
>> > Thanks,
>> > rjrjr
>> >
>> >
>> > >
>> >
>>
>> >>
>>
>
>
> --
> "There are only 10 types of people in the world: Those who understand
> binary, and those who don't"
>

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

[gwt-contrib] Re: Flurry of Data binding threads

[chris.ruffalo]

Going to stick my nose in here a bit:

I certainly believe that this is all one ball of wax.  I /know/ that
the system that I've been working on can be used to modify the data.
I know it breaks the JSR-303 paradigm so I've left it alone.  The
fundamental difference is that I'm expecting some output from the
process.  A lack of output signifies that everything worked.  Also I'm
not sure how much other metadata frameworks are putting in to pure JVM
mode operation.

I'm currently investigating mechanisms for cutting down on code
overhead because creating a validator for each class has proven to be
large.  Maybe what I need to do (and will investigate) is creating a
gimpy version of the annotations and other metadata on each method and
then packaging that to be consumed by a validator.  Or maybe not,
still working on that.

In any case I'd desperately like to merge functionality with someone
else and build a larger user base and feature set.  I'm not married to
the JSR-303 or anything but it seemed like a good place to start.

I agree with Emily's view of the world and I agree mostly with Ray.
I'm a little fuzzy on the work being done on UI templates and I'm not
sure about the compile-time emphasis.  As I've mentioned before I need
things to work on both sides of the "divide".  I'd love to see some
work put in to code templates that work through dynamic generation at
compile time and at run time.  I'm sure that most people don't want me
relying on constant introspection to get the job done just for
performance reasons.

Also the HasValue (or HasData) is a must.  I thought I came up with
that in the shower this morning.  I must have read it somewhere here
first right?  Anyway  I'm looking forward to what is coming in the
days ahead.

Shameless plug:  http://code.google.com/p/gwt-validation/

Chris Ruffalo

On Oct 9, 4:15 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> To give you an idea of where I am coming from, here is my understanding of
> the world:
>
> *Metadata Systems, comprising Models and Controllers*
> xforms, Ian's databinding system, Arthur's validation system, gwt team's
> upcoming proposal for data management:
>
> All part of the larger metadata, binding, code generation class of systems.
> Hopefully all of these can eventually use the same basic concepts and it
> going to be a huge undertaking to get it right. In fact, so huge of one that
> the gwt team has decided to duck for now and are trying very hard not to get
> involved in these discusions at the current time.
>
> *Widget bridge classes, part of the application's view.*
> Classes used to expose the application's view to the meta data systems.
>
> *HasValue*:  Provides the bridge between the metadata model and the world of
> widgets. From the meta data system's point of view it has some way of
> creating/linking with instances of HasValue, HasValue,
> HasValue, etc..
>
> From the widgets point of view, we have a whole bunch of text boxes, text
> areas, date pickers, etc. on the page.
>
> Accordingly, HasValue should only ever be used for simple leaf types on leaf
> widgets.
>
> *EventHandlers*: Provides a way for the meta data system controllers to add
> callbacks to react to widget changes.
>
>
>
>
>
> > -Ray
>
> > On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> > > We all seem to be talking about data binding and validation a lot, and
> > some
> > > of us are even implementing code about it. We on the GWT team hear the
> > need
> > > and feel it ourselves.
>
> > > We have some notions of how we'd like to tackle this in a way that blends
> > > seamlessly with the rest of GWT, and are looking to start design and
> > > implementation in earnest before the year is out. This makes it unlikely
> > > that we'll accept core or incubator patches that implement such a system.
> > > That said, we don't want to shoot down the excellent work that's being
> > done!
> > > If you have a system that's shaping up to meet your needs and that you
> > want
> > > to share with the GWT community, please do!  Set up a Google Code
> > project,
> > > announce it here, embarrass us by shipping first and attracting a user
> > > base. We'll probably steal from you shamelessly and ask for your help as
> > our
> > > own system takes shape.
> > > I hope this doesn't ruffle any feathers, and that you'll understand why
> > we
> > > haven't been as responsive on some of these threads as we should have
> > been.
> > > Thanks,
> > > rjrjr
>
> --
> "There are only 10 types of people in the world: Those who understand
> binary, and those who don't"
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Flurry of Data binding threads

[Emily Crutcher]

To give you an idea of where I am coming from, here is my understanding of
the world:

*Metadata Systems, comprising Models and Controllers*
xforms, Ian's databinding system, Arthur's validation system, gwt team's
upcoming proposal for data management:

All part of the larger metadata, binding, code generation class of systems.
Hopefully all of these can eventually use the same basic concepts and it
going to be a huge undertaking to get it right. In fact, so huge of one that
the gwt team has decided to duck for now and are trying very hard not to get
involved in these discusions at the current time.


*Widget bridge classes, part of the application's view.*
Classes used to expose the application's view to the meta data systems.

*HasValue*:  Provides the bridge between the metadata model and the world of
widgets. From the meta data system's point of view it has some way of
creating/linking with instances of HasValue, HasValue,
HasValue, etc..

>From the widgets point of view, we have a whole bunch of text boxes, text
areas, date pickers, etc. on the page.

Accordingly, HasValue should only ever be used for simple leaf types on leaf
widgets.

*EventHandlers*: Provides a way for the meta data system controllers to add
callbacks to react to widget changes.



>
> -Ray
>
>
>
> On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> > We all seem to be talking about data binding and validation a lot, and
> some
> > of us are even implementing code about it. We on the GWT team hear the
> need
> > and feel it ourselves.
> >
> > We have some notions of how we'd like to tackle this in a way that blends
> > seamlessly with the rest of GWT, and are looking to start design and
> > implementation in earnest before the year is out. This makes it unlikely
> > that we'll accept core or incubator patches that implement such a system.
> > That said, we don't want to shoot down the excellent work that's being
> done!
> > If you have a system that's shaping up to meet your needs and that you
> want
> > to share with the GWT community, please do!  Set up a Google Code
> project,
> > announce it here, embarrass us by shipping first and attracting a user
> > base. We'll probably steal from you shamelessly and ask for your help as
> our
> > own system takes shape.
> > I hope this doesn't ruffle any feathers, and that you'll understand why
> we
> > haven't been as responsive on some of these threads as we should have
> been.
> > Thanks,
> > rjrjr
> >
> >
> > >
> >
>
> >
>


-- 
"There are only 10 types of people in the world: Those who understand
binary, and those who don't"

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

[gwt-contrib] Code Review: gwt-google-apis gears

[Eric Ayers]

Hello Miguel,

This patch pretties up the sample for ManagedResourceStore in a
similar way to the previous patch for the ResourceStoreDemo.

- Add a margin.
- Add some spacing between the buttons.
- Toggle the enabled state of the buttons.

M  
samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/client/ManagedResourceStoreDemoNoGears.java
M  
samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/client/ManagedResourceStoreDemo.java
M  
samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/public/ManagedResourceStoreDemo.html
M  
samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/public/ManagedResourceStoreDemo_offline.html


-- 
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/

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

<>M  samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/client/ManagedResourceStoreDemoNoGears.java
M  samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/client/ManagedResourceStoreDemo.java
M  samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/public/ManagedResourceStoreDemo.html
M  samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/public/ManagedResourceStoreDemo_offline.html

Index: samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/client/ManagedResourceStoreDemoNoGears.java
===
--- samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/client/ManagedResourceStoreDemoNoGears.java	(revision 873)
+++ samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/client/ManagedResourceStoreDemoNoGears.java	(working copy)
@@ -25,8 +25,7 @@
  */
 public class ManagedResourceStoreDemoNoGears implements EntryPoint {
   public void onModuleLoad() {
-RootPanel rootPanel = RootPanel.get();
-rootPanel.add(new HTML(
+RootPanel.get("demo").add(new HTML(
 "ERROR: This browser does not support Google Gears.  Please install Gears and reload the application.  Note that GWT Gears applications can only be debugged in hosted mode on Windows."));
   }
 }
Index: samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/client/ManagedResourceStoreDemo.java
===
--- samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/client/ManagedResourceStoreDemo.java	(revision 873)
+++ samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/client/ManagedResourceStoreDemo.java	(working copy)
@@ -46,7 +46,8 @@
 
   public void onModuleLoad() {
 HorizontalPanel hpanel = new HorizontalPanel();
-RootPanel.get().add(hpanel);
+hpanel.setSpacing(10);
+RootPanel.get("demo").add(hpanel);
 
 hpanel.add(createManagedResourceStoreButton);
 
@@ -78,7 +79,9 @@
   LocalServer server = Factory.getInstance().createLocalServer();
   ManagedResourceStore store = Offline.getManagedResourceStore();
   server.removeManagedStore(store.getName());
-  statusLabel.setText("Removed ManagedResourceStore");
+  statusLabel.setText("Removed ManagedResourceStore.  Press Refresh to see Online version.");
+  createManagedResourceStoreButton.setEnabled(false);
+  removeManagedResourceStoreButton.setEnabled(false);
 } catch (GearsException e) {
   statusLabel.setText(e.getMessage());
 }
@@ -105,6 +108,7 @@
 statusLabel.setText("Update to "
 + managedResourceStore.getCurrentVersion()
 + " was completed.  Please refresh the page to see the changes.");
+createManagedResourceStoreButton.setEnabled(false);
   }
   break;
 case ManagedResourceStore.UPDATE_CHECKING:
Index: samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/public/ManagedResourceStoreDemo.html
===
--- samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/public/ManagedResourceStoreDemo.html	(revision 873)
+++ samples/managedresourcestore/src/com/google/gwt/gears/sample/managedresourcestore/public/ManagedResourceStoreDemo.html	(working copy)
@@ -1,24 +1,31 @@
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
 http://www.w3.org/1999/xhtml";>
-
-
-
-
-
+
+
+