Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1

2010-12-17 Thread Thomas Broyer

On Wednesday, December 8, 2010 9:16:16 PM UTC+1, PhilBeaudoin wrote:

 Just ran into an interesting little hack today. Basically, the interface 
 includes a method: 

public void __do_not_implement_this_interface_extend_FooImpl_instead(); 

I'm far from convinced I like it, but it sure is right in your face in case 
 you don't read javadocs! ;)


interestingly, that's exactly what Hamcrest (used in many testing tools: 
JUnit, Mockito, etc.) does:
http://code.google.com/p/hamcrest/source/browse/trunk/hamcrest-java/hamcrest-core/src/main/java/org/hamcrest/Matcher.java?r=645
 

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

[gwt-contrib] Re: Experimental framework for generator result caching in dev mode. (issue1227801)

2010-12-17 Thread jbrosenberg

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

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


Re: [gwt-contrib] Re: Experimental framework for generator result caching in dev mode. (issue1227801)

2010-12-17 Thread Chris Conroy
Just a general comment: We should take care to make sure that anything
that's cached across a refresh doesn't pin the TypeOracle or
CompilingClassLoader (any reference to a type, for example, will do that).

On Fri, Dec 17, 2010 at 9:16 AM, jbrosenb...@google.com wrote:

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

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


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

Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1

2010-12-17 Thread Philippe Beaudoin
Exactly, this is where I ran into this.

On Fri, Dec 17, 2010 at 3:36 AM, Thomas Broyer t.bro...@gmail.com wrote:

 On Wednesday, December 8, 2010 9:16:16 PM UTC+1, PhilBeaudoin wrote:

 Just ran into an interesting little hack today. Basically, the interface
 includes a method:

 public void __do_not_implement_this_interface_extend_FooImpl_instead();

 I'm far from convinced I like it, but it sure is right in your face in
 case you don't read javadocs! ;)

 interestingly, that's exactly what Hamcrest (used in many testing tools:
 JUnit, Mockito, etc.) does:
 http://code.google.com/p/hamcrest/source/browse/trunk/hamcrest-java/hamcrest-core/src/main/java/org/hamcrest/Matcher.java?r=645

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

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


[gwt-contrib] Why does OptionalFieldEditor implements LeafValueEditor?

2010-12-17 Thread Thomas Broyer
Hi,

We're experimenting with editors (actually, way more than that, with more 
than 80 reusable editors and 60 views that are editors themselves and make 
use of an editor driver) and we have an issue with OptionalFieldEditor: the 
wrapped editor isn't populated.

I can't for the life me find a significant difference between our use of 
OptionalFieldEditor and the DynaTableRf sample. The one big difference is 
that we use it in a decorator class (similar to ValueEditorDecorator, the 
child editor is then automatically wrapped in an OptionalFieldEditor 
within the @UiChild method) that happens to be parameterized:
  public class OptionalEntityEditorT extends AbstractEntity, E extends 
AbstractEntityEditorT extends Composite
implements IsEditorOptionalFieldEditorT, E {

   ...

   private OptionalFieldEditorT, E optionalEditor;

   public OptionalFieldEditorT, E asEditor() { return optionalEditor; }

@UiChild(limit=1, tagname=editor)
public void setEditor(E editor) {
   // add the editor to a container, then:
   this.optionalEditor = OptionalFieldEditor.of(editor);
}
  }

It is then used in an editor as:
  @UiField
  OptionalEntityEditorMyEntity, MyEntityEditor foo;

What's weird: I saw that OptionalFieldEditor implements LeafValueEditor so I 
though it might be the reason. We copied the class and removed that 
inheritance, and now it works.

Can you shed some light on this?

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

[gwt-contrib] Re: Handle composite constraints. (issue1231801)

2010-12-17 Thread rchandia

Compiling the validation sample (with ant) produces the following
warning (is that intended?):

 [java]   [WARN] No ConstraintValidator of
ConstraintDescriptorImpl{annotation=com.google.gwt.sample.validation.shared.Zip,
payloads=[], hasComposingConstraints=false,
isReportAsSingleInvalidConstraint=false, elementType=FIELD,
definedOn=DEFINED_LOCALLY, groups=[interface
javax.validation.groups.Default], attributes={message=Wrong zipcode,
payload=[Ljava.lang.Class;@10bc5c9, groups=[Ljava.lang.Class;@1e64d34}}
for zip of type class java.lang.String

I assume that you are planning to update the validation app frontend to
show Address and Zip fields, right?

On 2010/12/17 07:09:22, Nick Chalko wrote:




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

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


[gwt-contrib] Re: Handle composite constraints. (issue1231801)

2010-12-17 Thread Nick Chalko
On Fri, Dec 17, 2010 at 8:52 AM, rchan...@google.com wrote:

 Compiling the validation sample (with ant) produces the following
 warning (is that intended?):

 [java]   [WARN] No ConstraintValidator of

 ConstraintDescriptorImpl{annotation=com.google.gwt.sample.validation.shared.Zip,
 payloads=[], hasComposingConstraints=false,
 isReportAsSingleInvalidConstraint=false, elementType=FIELD,
 definedOn=DEFINED_LOCALLY, groups=[interface
 javax.validation.groups.Default], attributes={message=Wrong zipcode,
 payload=[Ljava.lang.Class;@10bc5c9, groups=[Ljava.lang.Class;@1e64d34}}
 for zip of type class java.lang.String

 I assume that you are planning to update the validation app frontend to

show Address and Zip fields, right?


Yes the sample needs to be improved,  for now I have just been using it as a
way to generate condition I am working on, but testing in the TCK.

The warning is cause because Zip it self doesn't specify which constraint
validator to use.  It is a composite constraint and I believe that is legal.

However I have not worked out exactly what the spec says to do.  There
should be a TODO in the code to fix this.





 On 2010/12/17 07:09:22, Nick Chalko wrote:




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




-- 
Generate your java flags for easier testing.
go/java_flags https://goto.google.com/java_flags
 https://goto.google.com/java_flags

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

[gwt-contrib] Re: Make the logging framework provide a default uncaught exception handler. (issue1223802)

2010-12-17 Thread unnurg

LGTM

On 2010/12/17 02:11:10, rjrjr wrote:




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

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


[gwt-contrib] Re: Make the logging framework provide a default uncaught exception handler. (issue1223802)

2010-12-17 Thread unnurg

Unfortunately not

On 2010/12/17 20:33:56, unnurg wrote:

LGTM



On 2010/12/17 02:11:10, rjrjr wrote:





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

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


[gwt-contrib] child entities modifications still not accessible in 2.1.1

2010-12-17 Thread Patrick Julien
Originally from

http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/1b67cfebede416b7/e958579badd4613a?lnk=gstq=pjulien+dvsDataMap#e958579badd4613a

and other posts.  I've now reported

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

and included a sample.  The sample is concise and direct and shows off
an assertion failure.

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


[gwt-contrib] Re: Handle composite constraints. (issue1231801)

2010-12-17 Thread rchandia

LGTM
On 2010/12/17 19:43:44, Nick Chalko wrote:

On Fri, Dec 17, 2010 at 8:52 AM, mailto:rchan...@google.com wrote:



 Compiling the validation sample (with ant) produces the following
 warning (is that intended?):

 [java]   [WARN] No ConstraintValidator of




ConstraintDescriptorImpl{annotation=com.google.gwt.sample.validation.shared.Zip,

 payloads=[], hasComposingConstraints=false,
 isReportAsSingleInvalidConstraint=false, elementType=FIELD,
 definedOn=DEFINED_LOCALLY, groups=[interface
 javax.validation.groups.Default], attributes={message=Wrong zipcode,
 payload=[Ljava.lang.Class;@10bc5c9,

groups=[Ljava.lang.Class;@1e64d34}}

 for zip of type class java.lang.String

 I assume that you are planning to update the validation app frontend

to


show Address and Zip fields, right?




Yes the sample needs to be improved,  for now I have just been using

it as a

way to generate condition I am working on, but testing in the TCK.



The warning is cause because Zip it self doesn't specify which

constraint

validator to use.  It is a composite constraint and I believe that is

legal.


However I have not worked out exactly what the spec says to do.  There
should be a TODO in the code to fix this.







 On 2010/12/17 07:09:22, Nick Chalko wrote:




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






--
Generate your java flags for easier testing.
go/java_flags https://goto.google.com/java_flags
  https://goto.google.com/java_flags





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

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


[gwt-contrib] Base Framework for Generator Result Caching (issue1232801)

2010-12-17 Thread jbrosenberg

Reviewers: tobyr, zundel,

Description:
Base Framework for Generator Result Caching


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

Affected files:
  A dev/core/src/com/google/gwt/core/ext/GeneratorContextExt.java
  A dev/core/src/com/google/gwt/core/ext/GeneratorExt.java
  M dev/core/src/com/google/gwt/dev/DevModeBase.java
  M dev/core/src/com/google/gwt/dev/Precompile.java
  M dev/core/src/com/google/gwt/dev/cfg/ModuleDef.java
  M dev/core/src/com/google/gwt/dev/cfg/Rule.java
  M dev/core/src/com/google/gwt/dev/cfg/RuleFail.java
  M dev/core/src/com/google/gwt/dev/cfg/RuleGenerateWith.java
  M dev/core/src/com/google/gwt/dev/cfg/RuleReplaceWith.java
  M dev/core/src/com/google/gwt/dev/javac/StandardGeneratorContext.java
  A  
dev/core/src/com/google/gwt/dev/javac/rebind/CachedPropertyInformation.java

  A dev/core/src/com/google/gwt/dev/javac/rebind/CachedRebindResult.java
  A dev/core/src/com/google/gwt/dev/javac/rebind/RebindCache.java
  A dev/core/src/com/google/gwt/dev/javac/rebind/RebindResult.java
  A dev/core/src/com/google/gwt/dev/javac/rebind/RebindStatus.java
  M dev/core/src/com/google/gwt/dev/jjs/JJSOptions.java
  M dev/core/src/com/google/gwt/dev/jjs/JJSOptionsImpl.java
  M dev/core/src/com/google/gwt/dev/shell/ShellModuleSpaceHost.java
  M dev/core/src/com/google/gwt/dev/shell/StandardRebindOracle.java
  A  
dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerEnableGeneratorResultCaching.java
  A  
dev/core/src/com/google/gwt/dev/util/arg/OptionEnableGeneratorResultCaching.java

  M user/src/com/google/gwt/junit/JUnitShell.java


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


[gwt-contrib] Re: Basic MessageIntrpolation. (issue1230801)

2010-12-17 Thread nchalko

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

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