Re: [gwt-contrib] Re: typo in documentation?

[Arthur Kalmenson]

Good catch Thomas, didn't see the "a".. but yeah, it isn't very clear.

--
Arthur Kalmenson



On Fri, Jan 14, 2011 at 3:42 AM, Thomas Broyer  wrote:
> I guess that's why it says "*a* BasicPlace" rather than just "BasicPlace".
> Yes, it's up to you to define such a class. David Chandler (or was it Chris
> Ramsdale?) once answered about this paragraph and acknowledged it wasn't
> very clear…
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

[gwt-contrib] typo in documentation?

[Arthur Kalmenson]

Hey everyone,

Just a quick question, I was looking through the MVP docs:
http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html#Places
and in the Place section there is a paragraph that eludes to a
BasicPlace class. It says:

"Many Places in your app might not save any state to the URL, so they
could just extend a BasicPlace which declares a PlaceTokenizer that
returns a null token."

But BasicPlace doesn't seem to exist. Is this a typo? I guess we can
just declare our own BasicPlace?

All the best,
--
Arthur Kalmenson

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

Re: [gwt-contrib] Public: GWT version of the JSR 303 Bean Validation TCK (issue1085801)

[Arthur Kalmenson]

I'm wondering if the TestNG stuff
(http://gwt-code-reviews.appspot.com/1085801/patch/60001/61019) is
just for this validation piece or if this is the beginning of an
update to support TestNG for client side GWTTestCases?

All the best,
--
Arthur Kalmenson



On Sat, Nov 6, 2010 at 4:54 PM,   wrote:
> Reviewers: bobv,
>
> Description:
> Public: GWT version of the JSR 303 Bean Validation TCK
>
> So far only one test is wrapped, One test passses and one fails,
> but this shows the patern to use to get the tests going.
>
> The test failure is expected, and represent code that needs to be
> implemeted.
>
>
> Please review this at http://gwt-code-reviews.appspot.com/1085801/show
>
> Affected files:
>  M samples/build.xml
>  M samples/common.ant.xml
>  A samples/validationtck/build.xml
>  A samples/validationtck/src/com/google/gwt/sample/validationtck/Tck.java
>  A
> samples/validationtck/src/com/google/gwt/sample/validationtck/TckTestValidator.java
>  A
> samples/validationtck/src/com/google/gwt/sample/validationtck/TckValidator.java
>  A
> samples/validationtck/src/com/google/gwt/sample/validationtck/ValidationTck.gwt.xml
>  A samples/validationtck/src/org/hibernate/jsr303/tck/Jsr303Tck.gwt.xml
>  A
> samples/validationtck/src/org/hibernate/jsr303/tck/super/org/hibernate/jsr303/tck/util/TestUtil.java
>  A samples/validationtck/src/org/jboss/test/audit/JbossTestAudit.gwt.xml
>  A samples/validationtck/src/org/jboss/testharness/JbossTestHarness.gwt.xml
>  A
> samples/validationtck/src/org/jboss/testharness/super/org/jboss/testharness/AbstractTest.java
>  A
> samples/validationtck/src/org/jboss/testharness/super/org/jboss/testharness/api/Configuration.java
>  A
> samples/validationtck/src/org/jboss/testharness/super/org/jboss/testharness/api/ResourceDescriptor.java
>  A
> samples/validationtck/src/org/jboss/testharness/super/org/jboss/testharness/impl/packaging/TCKArtifact.java
>  A
> samples/validationtck/src/org/jboss/testharness/super/org/jboss/testharness/spi/Containers.java
>  A
> samples/validationtck/src/org/jboss/testharness/super/org/jboss/testharness/spi/StandaloneContainers.java
>  A samples/validationtck/src/org/testng/TestNg.gwt.xml
>  A samples/validationtck/src/org/testng/super/org/testng/Assert.java
>  A samples/validationtck/src/org/testng/super/org/testng/IClass.java
>  A samples/validationtck/src/org/testng/super/org/testng/ITestNGMethod.java
>  A
> samples/validationtck/src/org/testng/super/org/testng/collections/Maps.java
>  A
> samples/validationtck/test/com/google/gwt/sample/validationtck/TckGwtSuite.java
>  A
> samples/validationtck/test/com/google/gwt/sample/validationtck/ValidationTckTest.gwt.xml
>  A
> samples/validationtck/test/com/google/gwt/sample/validationtck/constraints/application/ValidationRequirementTest.java
>  M user/src/com/google/gwt/validation/rebind/BeanHelper.java
>  M
> user/src/com/google/gwt/validation/rebind/GwtSpecificValidatorCreator.java
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Re: Update the npapi plugin to support OSX. (issue1036801)

[Arthur Kalmenson]

Is this coming with GWT 2.1? I'm guessing this is a Chrome Extension
for Mac OS X

--
Arthur Kalmenson



On Wed, Oct 20, 2010 at 3:10 PM,   wrote:
> LGTM2
>
> On 2010/10/20 18:54:20, jat wrote:
>>
>> Ok.
>
>> Be sure and check in the compiled libraries in prebuilt and an updated
>
> CRX at
>>
>> the same time.
>
>
>
> http://gwt-code-reviews.appspot.com/1036801/show
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Add Support for server side script selection in linker (issue941802)

[Arthur Kalmenson]

Hello Unnur,

That's a very good point, but I guess either inlining manually for a
production deploy or making a linker for my specific case works fine.
If I get a chance, I'll try and experiment with the server side
selector to see if I can get it to work. Thanks again for all the
info!

--
Arthur Kalmenson



On Wed, Oct 13, 2010 at 3:08 PM, Unnur Gretarsdottir  wrote:
> Hi Arthur -
>  Yes - we probably could build it, but then you wouldn't be able to
> customize any of the aspects of that HTML page. Most people want
> something else on that page other than just the GWT module include
> (even if it's something as simple as setting the  tag in the
> head to something specific).  In general, we sort of count on people
> who are trying to do semi-advanced optimizations to be able to do some
> work, like adding the contents of the nocache.js file to the initial
> html file themselves.  Alternatively - you could subclass the linker
> and have it do what you want for your specific project since you would
> know exactly what other stuff you might want in your particular html
> file.
>
>  I also just wanted to reiterate one more time that support for server
> side selection is not coming soon.  We are (experimentally) adding the
> ability for people do server side selection, assuming that they do
> some configuration themselves.  Specifically, you'll have to subclass
> the linker to turn on some of the options.  More significantly, you'll
> need parse the configuration-mappings.txt file to determine the
> correct md5 file and dynamically generate your HTML with a script tag
> pointing to that md5 file. Doing this is harder than inlining the
> selection script, so if your primary interest is in cutting out one of
> the round trips, I'd recommend that you go ahead with getting that
> working first.  Although we may add it eventually, there is no current
> plan to make server side selection available "out of the box".
>
> - Unnur
>
>
>
> On Wed, Oct 13, 2010 at 9:28 AM, Arthur Kalmenson  
> wrote:
>> Hey Unnur,
>>
>> You're right, gwt doesn't have access to the initial HTML page, but I
>> wonder if it'd be possible to build a linker to make that dynamically
>> generated page. Doesn't the linker have access to what gets generated
>> in the nocache.js? Theoretically you could just output a simple HTML
>> page that includes its contents.
>>
>> Then again, if this server side selection is coming soon (gwt 2.2?),
>> building this linker won't make much sense. Thanks again for all the
>> info!
>>
>> All the best,
>> --
>> Arthur Kalmenson
>>
>>
>>
>> On Mon, Oct 11, 2010 at 1:03 PM, Unnur Gretarsdottir  
>> wrote:
>>> Hi Arthur -
>>>  Are you asking if there's an existing linker for the inlining of
>>> your selection script? If so, no - the linker has no access to the
>>> contents of your initital html page.  What you need to do is, rather
>>> than serve a static html page, your server will have to dynamically
>>> generate it, by reading the content of the nocache.js file and putting
>>> it directly in the html which is served on the initial request.  In
>>> theory, if you rarely release your code, you could do this manually -
>>> basically, every time you do a gwt compile, manually copy the contents
>>> of nocahce.js into the initial html page.
>>>
>>> - Unnur
>>>
>>>
>>> On Fri, Oct 8, 2010 at 12:41 PM, Arthur Kalmenson  
>>> wrote:
>>>> That's a great idea Unnur. Is there an existing linker for this or
>>>> would I have to build it (it seems like something the linker would do,
>>>> if I understood them correctly)?
>>>>
>>>> --
>>>> Arthur Kalmenson
>>>>
>>>>
>>>>
>>>> On Fri, Oct 8, 2010 at 1:57 PM, Unnur Gretarsdottir  
>>>> wrote:
>>>>> Hi Arthur -
>>>>>  This is, and will probably remain for some time, experimental.  In
>>>>> order to use this, you'll need to extend the linker and change the
>>>>> variable - also, you'll need to write your own server code to parse
>>>>> the compilation mappings text file and decide which permutation you
>>>>> want to use.  Sorry not to have a better answer - we did want to make
>>>>> sure that this new linker is set up to support this sort of linking,
>>>>> but it is not currently a feature that we are officially releasing.
>>>>> FYI - if your primary c

Re: [gwt-contrib] Re: expense isn't getting GWT RC1 release

[Arthur Kalmenson]

Great, thanks. Would a patch be helpful or will you be using some
other Maven repository?

--
Arthur Kalmenson



On Wed, Oct 13, 2010 at 5:22 PM, John LaBanca  wrote:
> I created an issue so we can fix this for the final GWT 2.1 release:
> http://code.google.com/p/google-web-toolkit/issues/detail?id=5418
>
> Thanks,
> John LaBanca
> jlaba...@google.com
>
>
> On Wed, Oct 13, 2010 at 5:18 PM, Arthur Kalmenson 
> wrote:
>>
>> Just to confirm, changing the repository definition to:
>>
>>        
>>            gwt-repo
>>
>>  https://oss.sonatype.org/content/repositories/google-snapshots
>>            Google Web Toolkit Repository
>>        
>>
>> Removes the compile errors from the expense report (I also had to
>> remove the .m2/repository/com/google/gwt folder to force Maven to
>> redownload 2.1-SNAPSHOT).
>>
>> --
>> Arthur Kalmenson
>>
>>
>>
>> On Wed, Oct 13, 2010 at 5:12 PM, Arthur Kalmenson 
>> wrote:
>> > Hello everyone,
>> >
>> > I'm trying to build the expense report app, and it looks like the
>> > source has been refactored to remove the "app" part from the packages
>> > for place, requestfactory, etc. Unfortunately, the expense report POM
>> > hasn't been updated to grab GWT RC 1. The repository definition looks
>> > like this:
>> >
>> >    
>> >            gwt-repo
>> >
>> >  http://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven
>> >            Google Web Toolkit Repository
>> >        
>> >
>> > While the
>> > "http://google-web-toolkit.googlecode.com/svn/2.1.0.RC1/gwt/maven/";
>> > repository doesn't have a GWT release. Will you be putting the new
>> > release in the 2.1.0.M3/gwt/maven repository or the
>> > 2.1.0.RC1/gwt/maven one? Because all the downloads of GWT RC 1 will
>> > have a broken expense report
>> >
>> > In the mean time, the snapshot repository linked from the blog post
>> > (https://oss.sonatype.org/content/repositories/google-snapshots) seems
>> > to contain the correct SNAPSHOT. I'll try to use that. Thank you.
>> >
>> > --
>> > Arthur Kalmenson
>> >
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

[gwt-contrib] Re: expense isn't getting GWT RC1 release

[Arthur Kalmenson]

Just to confirm, changing the repository definition to:


gwt-repo

https://oss.sonatype.org/content/repositories/google-snapshots
Google Web Toolkit Repository


Removes the compile errors from the expense report (I also had to
remove the .m2/repository/com/google/gwt folder to force Maven to
redownload 2.1-SNAPSHOT).

--
Arthur Kalmenson



On Wed, Oct 13, 2010 at 5:12 PM, Arthur Kalmenson  wrote:
> Hello everyone,
>
> I'm trying to build the expense report app, and it looks like the
> source has been refactored to remove the "app" part from the packages
> for place, requestfactory, etc. Unfortunately, the expense report POM
> hasn't been updated to grab GWT RC 1. The repository definition looks
> like this:
>
>    
>            gwt-repo
>            
> http://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven
>            Google Web Toolkit Repository
>        
>
> While the "http://google-web-toolkit.googlecode.com/svn/2.1.0.RC1/gwt/maven/";
> repository doesn't have a GWT release. Will you be putting the new
> release in the 2.1.0.M3/gwt/maven repository or the
> 2.1.0.RC1/gwt/maven one? Because all the downloads of GWT RC 1 will
> have a broken expense report
>
> In the mean time, the snapshot repository linked from the blog post
> (https://oss.sonatype.org/content/repositories/google-snapshots) seems
> to contain the correct SNAPSHOT. I'll try to use that. Thank you.
>
> --
> Arthur Kalmenson
>

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

[gwt-contrib] expense isn't getting GWT RC1 release

[Arthur Kalmenson]

Hello everyone,

I'm trying to build the expense report app, and it looks like the
source has been refactored to remove the "app" part from the packages
for place, requestfactory, etc. Unfortunately, the expense report POM
hasn't been updated to grab GWT RC 1. The repository definition looks
like this:


gwt-repo

http://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven
Google Web Toolkit Repository


While the "http://google-web-toolkit.googlecode.com/svn/2.1.0.RC1/gwt/maven/";
repository doesn't have a GWT release. Will you be putting the new
release in the 2.1.0.M3/gwt/maven repository or the
2.1.0.RC1/gwt/maven one? Because all the downloads of GWT RC 1 will
have a broken expense report

In the mean time, the snapshot repository linked from the blog post
(https://oss.sonatype.org/content/repositories/google-snapshots) seems
to contain the correct SNAPSHOT. I'll try to use that. Thank you.

--
Arthur Kalmenson

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

Re: [gwt-contrib] Add Support for server side script selection in linker (issue941802)

[Arthur Kalmenson]

Hey Unnur,

You're right, gwt doesn't have access to the initial HTML page, but I
wonder if it'd be possible to build a linker to make that dynamically
generated page. Doesn't the linker have access to what gets generated
in the nocache.js? Theoretically you could just output a simple HTML
page that includes its contents.

Then again, if this server side selection is coming soon (gwt 2.2?),
building this linker won't make much sense. Thanks again for all the
info!

All the best,
--
Arthur Kalmenson



On Mon, Oct 11, 2010 at 1:03 PM, Unnur Gretarsdottir  wrote:
> Hi Arthur -
>  Are you asking if there's an existing linker for the inlining of
> your selection script? If so, no - the linker has no access to the
> contents of your initital html page.  What you need to do is, rather
> than serve a static html page, your server will have to dynamically
> generate it, by reading the content of the nocache.js file and putting
> it directly in the html which is served on the initial request.  In
> theory, if you rarely release your code, you could do this manually -
> basically, every time you do a gwt compile, manually copy the contents
> of nocahce.js into the initial html page.
>
> - Unnur
>
>
> On Fri, Oct 8, 2010 at 12:41 PM, Arthur Kalmenson  
> wrote:
>> That's a great idea Unnur. Is there an existing linker for this or
>> would I have to build it (it seems like something the linker would do,
>> if I understood them correctly)?
>>
>> --
>> Arthur Kalmenson
>>
>>
>>
>> On Fri, Oct 8, 2010 at 1:57 PM, Unnur Gretarsdottir  
>> wrote:
>>> Hi Arthur -
>>>  This is, and will probably remain for some time, experimental.  In
>>> order to use this, you'll need to extend the linker and change the
>>> variable - also, you'll need to write your own server code to parse
>>> the compilation mappings text file and decide which permutation you
>>> want to use.  Sorry not to have a better answer - we did want to make
>>> sure that this new linker is set up to support this sort of linking,
>>> but it is not currently a feature that we are officially releasing.
>>> FYI - if your primary concern is the double round trips, as opposed to
>>> the size of the permutation selection JS, then an easy solution for
>>> you is to simply inline the foo.nocache.js script into your page
>>> rather than requesting it using a script tag
>>>
>>> - Unnur
>>>
>>> On Mon, Oct 4, 2010 at 2:06 PM, Arthur Kalmenson  
>>> wrote:
>>>> Wow, this is great! I'm guessing this means we can cut the startup
>>>> round trips to one? Is this going into GWT 2.1?
>>>>
>>>> Exciting stuff.
>>>> --
>>>> Arthur Kalmenson
>>>>
>>>>
>>>>
>>>> On Fri, Oct 1, 2010 at 6:09 PM,   wrote:
>>>>> Reviewers: jgw,
>>>>>
>>>>> Description:
>>>>> Add Support for server side script selection in linker
>>>>>
>>>>>
>>>>> Please review this at http://gwt-code-reviews.appspot.com/941802/show
>>>>>
>>>>> Affected files:
>>>>>  A dev/core/src/com/google/gwt/core/ext/linker/impl/PermutationsUtil.java
>>>>>  A
>>>>> dev/core/src/com/google/gwt/core/ext/linker/impl/PropertiesMappingArtifact.java
>>>>>  A
>>>>> dev/core/src/com/google/gwt/core/ext/linker/impl/ResourceInjectionUtil.java
>>>>>  M
>>>>> dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
>>>>>  M dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js
>>>>>  M 
>>>>> dev/core/src/com/google/gwt/core/ext/linker/impl/installLocationIframe.js
>>>>>  A dev/core/src/com/google/gwt/core/ext/linker/impl/installScriptCommon.js
>>>>>  A dev/core/src/com/google/gwt/core/ext/linker/impl/installScriptDirect.js
>>>>>  A
>>>>> dev/core/src/com/google/gwt/core/ext/linker/impl/installScriptEarlyDownload.js
>>>>>  M dev/core/src/com/google/gwt/core/ext/linker/impl/permutations.js
>>>>>  M dev/core/src/com/google/gwt/core/ext/linker/impl/processMetas.js
>>>>>  M dev/core/src/com/google/gwt/core/ext/linker/impl/waitForBodyLoaded.js
>>>>>  M dev/core/src/com/google/gwt/core/linker/CrossSiteIframeLinker.java
>>>>>  M dev/core/src/com/google/gwt/core/linker/CrossSiteIframeTemplate.js
>>>>>  M dev/core/src/com/google/gwt/core/linker/SingleScriptLinker.java
>>>>>
>>>>>
>>>>> --
>>>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>>
>>>> --
>>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>>
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Add Support for server side script selection in linker (issue941802)

[Arthur Kalmenson]

That's a great idea Unnur. Is there an existing linker for this or
would I have to build it (it seems like something the linker would do,
if I understood them correctly)?

--
Arthur Kalmenson



On Fri, Oct 8, 2010 at 1:57 PM, Unnur Gretarsdottir  wrote:
> Hi Arthur -
>  This is, and will probably remain for some time, experimental.  In
> order to use this, you'll need to extend the linker and change the
> variable - also, you'll need to write your own server code to parse
> the compilation mappings text file and decide which permutation you
> want to use.  Sorry not to have a better answer - we did want to make
> sure that this new linker is set up to support this sort of linking,
> but it is not currently a feature that we are officially releasing.
> FYI - if your primary concern is the double round trips, as opposed to
> the size of the permutation selection JS, then an easy solution for
> you is to simply inline the foo.nocache.js script into your page
> rather than requesting it using a script tag
>
> - Unnur
>
> On Mon, Oct 4, 2010 at 2:06 PM, Arthur Kalmenson  
> wrote:
>> Wow, this is great! I'm guessing this means we can cut the startup
>> round trips to one? Is this going into GWT 2.1?
>>
>> Exciting stuff.
>> --
>> Arthur Kalmenson
>>
>>
>>
>> On Fri, Oct 1, 2010 at 6:09 PM,   wrote:
>>> Reviewers: jgw,
>>>
>>> Description:
>>> Add Support for server side script selection in linker
>>>
>>>
>>> Please review this at http://gwt-code-reviews.appspot.com/941802/show
>>>
>>> Affected files:
>>>  A dev/core/src/com/google/gwt/core/ext/linker/impl/PermutationsUtil.java
>>>  A
>>> dev/core/src/com/google/gwt/core/ext/linker/impl/PropertiesMappingArtifact.java
>>>  A
>>> dev/core/src/com/google/gwt/core/ext/linker/impl/ResourceInjectionUtil.java
>>>  M
>>> dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
>>>  M dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js
>>>  M dev/core/src/com/google/gwt/core/ext/linker/impl/installLocationIframe.js
>>>  A dev/core/src/com/google/gwt/core/ext/linker/impl/installScriptCommon.js
>>>  A dev/core/src/com/google/gwt/core/ext/linker/impl/installScriptDirect.js
>>>  A
>>> dev/core/src/com/google/gwt/core/ext/linker/impl/installScriptEarlyDownload.js
>>>  M dev/core/src/com/google/gwt/core/ext/linker/impl/permutations.js
>>>  M dev/core/src/com/google/gwt/core/ext/linker/impl/processMetas.js
>>>  M dev/core/src/com/google/gwt/core/ext/linker/impl/waitForBodyLoaded.js
>>>  M dev/core/src/com/google/gwt/core/linker/CrossSiteIframeLinker.java
>>>  M dev/core/src/com/google/gwt/core/linker/CrossSiteIframeTemplate.js
>>>  M dev/core/src/com/google/gwt/core/linker/SingleScriptLinker.java
>>>
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Add Support for server side script selection in linker (issue941802)

[Arthur Kalmenson]

Wow, this is great! I'm guessing this means we can cut the startup
round trips to one? Is this going into GWT 2.1?

Exciting stuff.
--
Arthur Kalmenson



On Fri, Oct 1, 2010 at 6:09 PM,   wrote:
> Reviewers: jgw,
>
> Description:
> Add Support for server side script selection in linker
>
>
> Please review this at http://gwt-code-reviews.appspot.com/941802/show
>
> Affected files:
>  A dev/core/src/com/google/gwt/core/ext/linker/impl/PermutationsUtil.java
>  A
> dev/core/src/com/google/gwt/core/ext/linker/impl/PropertiesMappingArtifact.java
>  A
> dev/core/src/com/google/gwt/core/ext/linker/impl/ResourceInjectionUtil.java
>  M
> dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
>  M dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js
>  M dev/core/src/com/google/gwt/core/ext/linker/impl/installLocationIframe.js
>  A dev/core/src/com/google/gwt/core/ext/linker/impl/installScriptCommon.js
>  A dev/core/src/com/google/gwt/core/ext/linker/impl/installScriptDirect.js
>  A
> dev/core/src/com/google/gwt/core/ext/linker/impl/installScriptEarlyDownload.js
>  M dev/core/src/com/google/gwt/core/ext/linker/impl/permutations.js
>  M dev/core/src/com/google/gwt/core/ext/linker/impl/processMetas.js
>  M dev/core/src/com/google/gwt/core/ext/linker/impl/waitForBodyLoaded.js
>  M dev/core/src/com/google/gwt/core/linker/CrossSiteIframeLinker.java
>  M dev/core/src/com/google/gwt/core/linker/CrossSiteIframeTemplate.js
>  M dev/core/src/com/google/gwt/core/linker/SingleScriptLinker.java
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Re: Added all safehtml packages. (issue771801)

[Arthur Kalmenson]

I'm just wondering, the idea of this is to display potentially unsafe
HTML we got from the server, right? Is there a way to discourage using
this to sanitizing HTML on the client before sending it to the server?
I can definitely see newer programmers assuming that doing this
sanitization on the client side is safe enough, when it's clearly not.
I guess some documentation to that effect would be enough.

--
Arthur Kalmenson



On Wed, Aug 18, 2010 at 10:11 AM, Christoph Kern  wrote:
>
>
> On Wed, Aug 18, 2010 at 01:44,  wrote:
>>
>> On 2010/08/17 23:23:39, xtof wrote:
>>>
>>> On 2010/08/17 23:05:06, tbroyer wrote:
>>> >
>>> > Looking at the code more closely it would merely "fail" by overly
>>> > rejecting tags that are whitelisted: i.e. "should be
>>> > bold" would be sanitized to "<b foo=should be bold" and the
>>> > end part would be italicized instead of bold.
>>
>>> And that is exactly correct behavior for this class as document. It
>>> only claims to accept HTML with attribute-free tags within the
>>> whitelist. It doesn't claim to do anything particularly sensible
>>> with input that doesn't fit this constraint; it does however claim
>>> that whatever it outputs is safe (will not result in XSS/script
>>> execution).
>>
>> Oops, yes, sorry, I can't tell how it happened but I misread the
>> "whitelisting" code (matches the whole thing between '<' and '>', so any
>> attribute, or even whitespace, as in "bold", would make it fail
>> and thus be escaped).
>> It's fine then. Sorry again for the noise.
>
> No prob, always better to err on the side of caution!
>
>>
>> Still, there's a small issue with the fact that
>> SafeHtmlTemplatesGenerator doesn't use the HTML5 serialization algorithm
>> (or any similar one): @Template("") will result in ""
>> which is interpreted by browsers as "" [1], which makes it
>> impossible to generate a single "line break" in a SafeHtmlTemplates.
>>
>> [1] http://www.w3.org/TR/html5/tokenization.html#parsing-main-inbody
>> (search for « An end tag whose tag name is "br" », it's there for
>> "compat with the Web")
>
> Agreed.  Another potential problem with this parser is that it's too strict
> -- it insists on well-formed XHTML, but that's a much stronger constraint
> than needed to ensure the SafeHtml type contract.
> For example,
> �...@template("")
>   SafeHtml openATag(String href);
> is perfectly safe, and might be useful in something where one needs to
> conditionally assemble various pieces of HTML markup,  like,
>   SafeHtmlBuilder shb;
>   //...
>   shb.append(openATag(someUrl));
>   if (...) {
>     shb.append(someThing)
>   } else {
>    shb.append(someThingElse);
>   }
> To ensure the SafeHtml type contract, the parser need only record the
> HTML-context ("inner text", "url-valued attribute", "style", etc) of the
> positional parameters, and require that the template ends in "inner text"
> context (to ensure that SafeHtmls are safely appendable to each other).
> Note that a bug in code like the above could result in non-well-formed HTML
> (like unbalanced tags), but not unsafe HTML that might cause XSS (that is of
> course absent bugs in the SafeHtml generators themselves).
> As I'd mentioned, I'm proposing to replace the current XML based parser with
> the java streamhtmlparser, which has this property.
> I'd be fine with removing the templating code from this change and land it
> separately along with the new parser.
> cheers,
> --xtof
>
>
>>
>>
>> http://gwt-code-reviews.appspot.com/771801/show
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Public: Start of a sample application showing GWT validation. (issue760802)

[Arthur Kalmenson]

But this is looking to be a really great release for enterprise app
building! I can just imagine how many days and weeks of work this
release would have saved me :D

--
Arthur Kalmenson



On Tue, Aug 17, 2010 at 2:12 PM, Arthur Kalmenson  wrote:
> Ah, sorry about that.
>
> --
> Arthur Kalmenson
>
>
>
> On Tue, Aug 17, 2010 at 2:04 PM, Ray Ryan  wrote:
>> This patch is focused on the validation plumbing. The UI is throw away.
>>
>> On Tue, Aug 17, 2010 at 11:02 AM, Arthur Kalmenson 
>> wrote:
>>>
>>> I'm really excited for this validation component, you guys/gals are
>>> doing a great job! But it looks like Validation is using
>>> VerticalPanel, but from my understand we're trying to discourage the
>>> use of table based widgets where possible. Could this be done with
>>> UiBinder and divs instead?
>>>
>>> --
>>> Arthur Kalmenson
>>>
>>>
>>>
>>> On Tue, Aug 17, 2010 at 10:35 AM,   wrote:
>>> > Reviewers: robertvater_google.com,
>>> >
>>> > Description:
>>> > Public: Start of a sample application showing GWT validation.
>>> >
>>> >
>>> > Please review this at http://gwt-code-reviews.appspot.com/760802/show
>>> >
>>> > Affected files:
>>> >  A eclipse/samples/Validation/.checkstyle
>>> >  A eclipse/samples/Validation/.classpath
>>> >  A eclipse/samples/Validation/.project
>>> >  A eclipse/samples/Validation/Validation-gwtc.launch
>>> >  A eclipse/samples/Validation/Validation.launch
>>> >  M eclipse/user/.classpath
>>> >  M samples/build.xml
>>> >  A samples/validation/build.xml
>>> >  A samples/validation/src/com/google/gwt/sample/validation/COPYING
>>> >  A
>>> >
>>> > samples/validation/src/com/google/gwt/sample/validation/Validation.gwt.xml
>>> >  A
>>> >
>>> > samples/validation/src/com/google/gwt/sample/validation/client/GreetingService.java
>>> >  A
>>> >
>>> > samples/validation/src/com/google/gwt/sample/validation/client/GreetingServiceAsync.java
>>> >  A
>>> >
>>> > samples/validation/src/com/google/gwt/sample/validation/client/Validation.java
>>> >  A
>>> >
>>> > samples/validation/src/com/google/gwt/sample/validation/server/GreetingServiceImpl.java
>>> >  A
>>> >
>>> > samples/validation/src/com/google/gwt/sample/validation/shared/Person.java
>>> >  A samples/validation/war/Validation.css
>>> >  A samples/validation/war/Validation.html
>>> >  A samples/validation/war/WEB-INF/classes/marker
>>> >  A samples/validation/war/WEB-INF/web.xml
>>> >
>>> >
>>> > --
>>> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] Public: Start of a sample application showing GWT validation. (issue760802)

[Arthur Kalmenson]

Ah, sorry about that.

--
Arthur Kalmenson



On Tue, Aug 17, 2010 at 2:04 PM, Ray Ryan  wrote:
> This patch is focused on the validation plumbing. The UI is throw away.
>
> On Tue, Aug 17, 2010 at 11:02 AM, Arthur Kalmenson 
> wrote:
>>
>> I'm really excited for this validation component, you guys/gals are
>> doing a great job! But it looks like Validation is using
>> VerticalPanel, but from my understand we're trying to discourage the
>> use of table based widgets where possible. Could this be done with
>> UiBinder and divs instead?
>>
>> --
>> Arthur Kalmenson
>>
>>
>>
>> On Tue, Aug 17, 2010 at 10:35 AM,   wrote:
>> > Reviewers: robertvater_google.com,
>> >
>> > Description:
>> > Public: Start of a sample application showing GWT validation.
>> >
>> >
>> > Please review this at http://gwt-code-reviews.appspot.com/760802/show
>> >
>> > Affected files:
>> >  A eclipse/samples/Validation/.checkstyle
>> >  A eclipse/samples/Validation/.classpath
>> >  A eclipse/samples/Validation/.project
>> >  A eclipse/samples/Validation/Validation-gwtc.launch
>> >  A eclipse/samples/Validation/Validation.launch
>> >  M eclipse/user/.classpath
>> >  M samples/build.xml
>> >  A samples/validation/build.xml
>> >  A samples/validation/src/com/google/gwt/sample/validation/COPYING
>> >  A
>> >
>> > samples/validation/src/com/google/gwt/sample/validation/Validation.gwt.xml
>> >  A
>> >
>> > samples/validation/src/com/google/gwt/sample/validation/client/GreetingService.java
>> >  A
>> >
>> > samples/validation/src/com/google/gwt/sample/validation/client/GreetingServiceAsync.java
>> >  A
>> >
>> > samples/validation/src/com/google/gwt/sample/validation/client/Validation.java
>> >  A
>> >
>> > samples/validation/src/com/google/gwt/sample/validation/server/GreetingServiceImpl.java
>> >  A
>> >
>> > samples/validation/src/com/google/gwt/sample/validation/shared/Person.java
>> >  A samples/validation/war/Validation.css
>> >  A samples/validation/war/Validation.html
>> >  A samples/validation/war/WEB-INF/classes/marker
>> >  A samples/validation/war/WEB-INF/web.xml
>> >
>> >
>> > --
>> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Public: Start of a sample application showing GWT validation. (issue760802)

[Arthur Kalmenson]

I'm really excited for this validation component, you guys/gals are
doing a great job! But it looks like Validation is using
VerticalPanel, but from my understand we're trying to discourage the
use of table based widgets where possible. Could this be done with
UiBinder and divs instead?

--
Arthur Kalmenson



On Tue, Aug 17, 2010 at 10:35 AM,   wrote:
> Reviewers: robertvater_google.com,
>
> Description:
> Public: Start of a sample application showing GWT validation.
>
>
> Please review this at http://gwt-code-reviews.appspot.com/760802/show
>
> Affected files:
>  A eclipse/samples/Validation/.checkstyle
>  A eclipse/samples/Validation/.classpath
>  A eclipse/samples/Validation/.project
>  A eclipse/samples/Validation/Validation-gwtc.launch
>  A eclipse/samples/Validation/Validation.launch
>  M eclipse/user/.classpath
>  M samples/build.xml
>  A samples/validation/build.xml
>  A samples/validation/src/com/google/gwt/sample/validation/COPYING
>  A
> samples/validation/src/com/google/gwt/sample/validation/Validation.gwt.xml
>  A
> samples/validation/src/com/google/gwt/sample/validation/client/GreetingService.java
>  A
> samples/validation/src/com/google/gwt/sample/validation/client/GreetingServiceAsync.java
>  A
> samples/validation/src/com/google/gwt/sample/validation/client/Validation.java
>  A
> samples/validation/src/com/google/gwt/sample/validation/server/GreetingServiceImpl.java
>  A
> samples/validation/src/com/google/gwt/sample/validation/shared/Person.java
>  A samples/validation/war/Validation.css
>  A samples/validation/war/Validation.html
>  A samples/validation/war/WEB-INF/classes/marker
>  A samples/validation/war/WEB-INF/web.xml
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?

[Arthur Kalmenson]

> If you inject your ginjector somewhere in its own dependency tree, it will
> inject itself, i.e. it is automatically bound as a singleton.

Does this work if you have multiple Ginjectors? What I've done before
was to have a hierarchy of Ginjectors and the top level one would be
what gets instantiated. If you inject one of these Ginjectors lower in
the hierarchy, would the instances still be the same?

And sorry for my inaccurate info, my GWT is getting rusty :(.

--
Arthur Kalmenson



On Tue, Aug 10, 2010 at 12:04 PM, Peter Schmitt  wrote:
> Hi all,
> this topic comes up so often that we should really find a solution. :) The
> short story is that we might need to fix this issue but could potentially
> work without it: http://code.google.com/p/google-gin/issues/detail?id=95
> (Allow classes created by a Generator to participate in dependency
> injection)
> Long story:
>
>>
>> When you start creating multiple Ginjectors, instances of classes don't
>> stay the
>>
>> same. For example, a Singleton EventBus in two Ginjectors are
>> different instance types.
>
> If you inject your ginjector somewhere in its own dependency tree, it will
> inject itself, i.e. it is automatically bound as a singleton.
>
>>
>> Also, I'm pretty sure you can't put an @Inject on an interface method,
>> but I haven't tried.
>
> Yes, you can - this is explicitly allowed in Gin for use with Generators.
>>
>> > Would something like the following improve life for GIN users enough to
>> > be
>> > worth doing? Or is it just a hack?
>> > [...]
>
> I think this is perfectly viable - but we're running into the generator
> interaction issue here. Right now, Gin cannot use generated code as input
> and therefore will not be able to inspect the generated implementation of
> MyUiBinder. This could be fine if we were specifying exactly what we want to
> be injected into the factory. But as far as I can see, you're injecting the
> ginjector and then using it in generated code. How do you know how to
> retrieve objects from the Ginjector? In difference to Guice, there is no
> getInstance(..) method on a Ginjector.
> I think what we want is a class generated by UiBinder that has @Inject
> annotated constructor/fields/methods for its required children and is then
> used as input by the Gin generator to wire the injection up. But to
> accomplish that, we'll need to fix the issue mentioned above.
> How does this sound?
> Peter
>
>
>>
>> > public interface UiBinderWithFactory extends UiBinder {
>> >   /**
>> >    * Sets a factory to use when instantiating objects that are not
>> >    * provided via @UiFactory methods or @UiField(provided = true)
>> > fields.
>> >    * 
>> >    * When an instance is needed, a zero args method with an appropriate
>> > return type
>> >    * will be sought on the factory to provide it. If none is found
>> > GWT.create()
>> >    * will be used instead.
>> >    * 
>> >    * It is a compile time error for the factory to provide ambiguous
>> > methods.
>> >    */
>> >   setFactory(F factory);
>> > }
>> >
>> > You might wind up with code like…
>> >
>> > @Inject
>> > public MyWidget(MyUiBinder binder) extends Composite {
>> >
>> >   public interface MyUiBinder extends UiBinderWithFactory> > MyWidget,
>> > MyGinjector> {
>> >    �...@inject setfactory(MyGinjector factory);
>> > }
>> >
>> > …and a few extra getters on your Ginjector.
>> >
>> > Now injecting an injector is generally a terrible idea, but it's
>> > something
>> > at least. (Does that even work in Gin? And can you put @Inject on an
>> > interface method?)
>> > What do you think?
>> > rjrjr
>> >
>> > --
>> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "google-gin" group.
>> To post to this group, send email to google-...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-gin+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-gin?hl=en.
>>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] RR: What if UiBinder could take a factory?

[Arthur Kalmenson]

Hey Ray,

Thanks for trying to make GIN user's lives easier when using UiBinder.
However, injecting an injector wouldn't really work. Most GIN
applications will end up having one top level Ginjector that would
have a getter for some top level application widget. When you start
creating multiple Ginjectors, instances of classes don't stay the
same. For example, a Singleton EventBus in two Ginjectors are
different instance types.

Also, I'm pretty sure you can't put an @Inject on an interface method,
but I haven't tried.
--
Arthur Kalmenson



On Mon, Aug 9, 2010 at 10:29 PM, Ray Ryan  wrote:
> If you don't use GIN (you know, that really should be GIn), the rest of this
> note probably won't interest you.
> Would something like the following improve life for GIN users enough to be
> worth doing? Or is it just a hack?
>
> public interface UiBinderWithFactory extends UiBinder {
>   /**
>    * Sets a factory to use when instantiating objects that are not
>    * provided via @UiFactory methods or @UiField(provided = true) fields.
>    * 
>    * When an instance is needed, a zero args method with an appropriate
> return type
>    * will be sought on the factory to provide it. If none is found
> GWT.create()
>    * will be used instead.
>    * 
>    * It is a compile time error for the factory to provide ambiguous
> methods.
>    */
>   setFactory(F factory);
> }
>
> You might wind up with code like…
>
> @Inject
> public MyWidget(MyUiBinder binder) extends Composite {
>
>   public interface MyUiBinder extends UiBinderWithFactory MyGinjector> {
>    �...@inject setfactory(MyGinjector factory);
> }
>
> …and a few extra getters on your Ginjector.
>
> Now injecting an injector is generally a terrible idea, but it's something
> at least. (Does that even work in Gin? And can you put @Inject on an
> interface method?)
> What do you think?
> rjrjr
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget

[Arthur Kalmenson]

But what if you have the case where you're setting the HandlerManager
specifically because you want to stop listening to all the events from
the previous HandlerManager. The idea of a stack of HandlerManagers
makes some sense if you want to have different HandlerManagers
handling events for different parts of a system.

I understand the idea of making your own HandlerManager, but from a
design perspective, doesn't it make sense to just have a singleton
HandlerManager? Are there performance implications of having
everything go through one HandlerManager?

All the best,
--
Arthur Kalmenson



On Wed, Feb 10, 2010 at 11:34 AM, Isaac Truett  wrote:
> The argument seems to revolve around changing HandlerManagers
> resulting in the loss of registered handlers. Is it possible that the
> HandlerManager and the set of registered handlers aren't really the
> same thing and need to be separated? Would everyone be happy if you
> could call setHandlerManager() and the new manager would still service
> the same set of handlers that existed previously?
>
>
> On Wed, Feb 10, 2010 at 10:59 AM, Ray Ryan  wrote:
>> I forgot about that nuance of your proposal. I like.
>> @jat: the stack idea is nifty, but expanding the scope of the patch even
>> worse than I am. And JL's proposal would let one implement that.
>>
>> On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca  wrote:
>>>
>>> I still think my proposal solves this for both cases.  We add a protected
>>> createHandlerManager, which is more restrictive because it is only called
>>> once per widget.
>>> We also make getHandlerManager() protected, which allows users to replace
>>> the HandlerManager if they really want to by overriding getHandlerManager to
>>> return one of many.  It would be up to the developer to add a
>>> setHandlerManager() method in their own widgets that would change the return
>>> value of getHandlerManager(), so its intentionally more difficult and
>>> therefore forces the developer to think about it a little more.
>>> Thanks,
>>> John LaBanca
>>> jlaba...@google.com
>>>
>>>
>>> On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken
>>>  wrote:
>>>>
>>>>
>>>> On 10 Feb., 16:28, Ray Ryan  wrote:
>>>> > Sven, you're arguing both sides here. You want things to be more
>>>> > customizable in general, but with your specific patch you're trying to
>>>> > be as
>>>> > restrictive as you can to achieve your personal goal.
>>>>
>>>> Both patches have the same restriction, once a handlermanager is set
>>>> or the default one created, there is no way back to change it. I am
>>>> also ok with a setHandlerManager without restrictions. But than people
>>>> will have the problem that they will loose handlerregistrations, if
>>>> they dont know what they are doing (and yes, there are these people).
>>>> I wanted to make this patch as much fool proof as possible. It should
>>>> be customaziable, but in a way, that you cannot brake it.
>>>>
>>>> I dont think that you really need to change the handlermanager during
>>>> runtime after you set the first one. You also cannot change the
>>>> element of a widget once you set the first one.
>>>>
>>>> >
>>>> > I'm assuming that if we provide an unrestricted setHandlerManager we
>>>> > would
>>>> > also provide a getHandlerManager. It doesn't seem like rocket science
>>>> > to
>>>> > expect someone to check for an existing one if before clobbering it.
>>>> > I'm
>>>> > also assuming that these methods are protected, not part of every
>>>> > widget's
>>>> > public api.
>>>> Yes sure, protected. They should not be public.
>>>>
>>>> >
>>>> > I also would argue against providing both createHM and setHM. Redundant
>>>> > API
>>>> > is confusing API, another unfortunate trait of our widget set. Lazy
>>>> > creation
>>>> > can happen in the default implementation of getHM. A custom widget
>>>> > author
>>>> > could override that method to maintain laziness, or call setHM from
>>>> > their
>>>> > constructor to keep ours from ever seeing the light of day.
>>>>
>>>> I dont want to add boths. There is no need for it. One approach is
>>>> more than sufficient. With both ways you would 

Re: [gwt-contrib] Announcing GWT 2.0.1

[Arthur Kalmenson]

Great job! Some nice bug squishing.

--
Arthur Kalmenson



2010/2/2 Miguel Méndez :
> The GWT 2.0.1 point release is now available for download. It contains fixes
> for bugs found in the 2.0.0 release.
>
> Potentially breaking changes and fixes
>
> Fixed a bug in how code generators collect method arguments from generated
> source, which impacted the Messages interfaces generated for UiBinder
> template files. In GWT 2.0, such argument names were incorrectly changed to
> ARGn. Most GWT applications will be unaffected, but external systems relying
> on these names may need to be updated.
> The development mode server will, by default, only bind to localhost which
> will break cross-machine debugging. You can get the old behavior by
> specifying -bindAddress 0.0.0.0. Please see issue (#4322) for more details.
> For webAppCreator-generated ant files, you can pass this with ant
> -Dgwt.args="-bindAddress 0.0.0.0" devmode.
> The CurrencyList/CurrencyData APIs are now public - if you were relying upon
> these classes in their non-public location, you should only need to update
> your imports.
>
> Noteworthy Fixed Issues
>
> UiBinder Image class with resource attribute, removes styles on that image
> (#4415)
> Widgets lose focus if its placed on FocusPanel (Opera, Safari) (#1471)
> Standard.css missing new layout styles (#4429)
> Remove method in SplitLayoutPanel is broken (#4217)
> Splitter constructor hard codes the background color of the splitter to
> white (#4335)
> Image should provide method to set alternative text (#4335)
> CssResource cannot parse unescaped '-', '_' in class selectors and unknown
> at-rules (#3946)
> Focusable implementation breaks ScrollPanels in Safari (#1313)
> RequestBuilder restricted to GET and POST (#3388)
> HTMLTable.Cell.getElement() calls getCellFormatter().getElement() with row
> and column swapped RequestBuilder restricted to GET and POST (#3757)
> MenuBar steals focus when hovered (#3884)
> TabLayoutPanel tabs don't line up properly on IE (#4447)
> webAppCreator produces ant build files which support the gwt.args property
> for passing additional flags to the gwtc and devmode rules, such as ant
> -Dgwt.args="-style PRETTY" gwtc.
>
> See the GWT issue tracker for the complete list of bug fixes and
> enhancements in this release.
>
> --
>
> Miguel on behalf of the GWT Team
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Re: r7517 committed - Adding RegExp to public GWT (native version, pure Java version, tests)

[Arthur Kalmenson]

Seems like we need a bot to publish Waves as Google Code wikis :)

--
Arthur Kalmenson



On Tue, Feb 2, 2010 at 11:47 AM, Ray Ryan  wrote:
> Well, not nothing — it'd be pretty easy for a bot to be written to publish
> static views of waves. But without that…
>
> On Tue, Feb 2, 2010 at 8:47 AM, Ray Ryan  wrote:
>>
>> That's a very good point. I'm confident we could get anyone invited who
>> wants to participate, but there's nothing we could do yet to make such waves
>> visible to non-members, and that would be really bad.
>>
>> On Tue, Feb 2, 2010 at 8:43 AM, Paul Robinson  wrote:
>>>
>>> I'd hate to see even more discussions moving away from here (because I,
>>> and maybe quite a few others here, don't have access to Wave).
>>>
>>> Paul
>>>
>>> Ray Ryan wrote:
>>> >
>>> > We can use the public Wave instance with alternate addresses.
>>> > Inconvenient, but it's not that big a deal.
>>> >
>>> > <http://groups.google.com/group/Google-Web-Toolkit-Contributors>
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>>
>>
>> --
>> I wish this were a Wave
>
>
>
> --
> I wish this were a Wave
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] GWT RPC Response Content-Type is application/json ??

[Arthur Kalmenson]

Well, AFAIK, the response is in fact JSON, it's compact JSON but still
JSON. GWT-RPC requests are of type "text/x-gwt-rpc", but the response
is "application/json".

--
Arthur Kalmenson



On Sat, Jan 30, 2010 at 2:12 PM, jarrod  wrote:
> Is there anything in GWT's RPC code on the server side that would be
> setting the response's Content-Type header to be "application/json"??
> I cannot figure out where in my J2EE application this is getting set.
> Here's a sample set of response headers:
>
> HTTP/1.1 200 OK
> Server: Apache-Coyote/1.1
> Content-Encoding: gzip
> Content-Disposition: attachment
> Content-Type: application/json;charset=utf-8
> Content-Length: 1158
> Date: Sat, 30 Jan 2010 18:52:06 GMT
>
>
> I thought it might be something I was doing, but when I created a new
> GWT project using the Google Eclipse Plugin and ran the new project
> unmodified, I got the same result.
>
> Is that the way it's supposed to be? Obviously the response isn't
> really JSON...
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Re: GWT Incubator Status Update and Schedule

[Arthur Kalmenson]

Hmm, a nightly build sounds like a cool idea, I wouldn't mind seeing that as
well.

--
Arthur Kalmenson


On Thu, Jan 21, 2010 at 3:28 AM, David  wrote:

> Hi,
>
> It would be nice that the GWT team would release some development
> builds once in a while. That would be very usefull at the point where
> new things are added to the trunk. This way you can get a lot more
> input from the community, since it makes it much easier to use a more
> experimental version of GWT. Compiling from the sources means that we
> need direct access to the internet, but not all companies allow that.
>
> As long as we have some indication of what is mostly stable and what
> not, we can choose at what point we whish to start using a development
> build.
>
> David
>
> On Wed, Jan 20, 2010 at 6:19 PM, monkeyboy 
> wrote:
> > Thank you John for your explanation. Now I understand the reason why
> > you are shutting down the incubator. What I am suggesting is that
> > developers should have a place where they can see what new features
> > (libraries,...) are being developed and not to stumble upon this new
> > features by chance (like I stumbled upon the doc for
> > DataBackedWidgetsDesign for example). You mentioned that you send
> > emails when you start a new project. What do I need to do to receive
> > such an email?
> > I think you guys at Google develop great libraries that are perhaps
> > underused because they are hard to find. Let's take Gin for example
> > (http://code.google.com/p/google-gin/). I think that more people would
> > use it if you had a link to Gin from the GWT Tools and Libraries page.
> >
> > Regards.
> >
> > On Jan 20, 5:29 pm, John LaBanca  wrote:
> >> Libraries and widgets that we want to incubate will be moved into
> separate
> >> projects.  Instead of downloading one incubator jar, you'll be able to
> (have
> >> to) download each project individually.  Like Ray said, we're going to
> >> commit most new features directly to trunk, but we may still want to
> >> incubate some features if they are highly experimental.  We often setup
> a
> >> design doc and send out an email when we start a new project, such as
> the
> >> data backed widgets, so the community can be involved.  I'm sure we'll
> keep
> >> doing that.
> >>
> >> The advantage of separate projects is that each project can move along
> at
> >> its own pace.  The incubator currently has some very stable features,
> some
> >> highly experimental ones, and some deprecated code, and it isn't obvious
> >> which is which (well, except the deprecated stuff).  With individual
> >> projects, it should be more obvious what the state of the project is.
> >>
> >> Thanks,
> >> John LaBanca
> >> jlaba...@google.com
> >>
> >> On Wed, Jan 20, 2010 at 10:57 AM, monkeyboy  >wrote:
> >>
> >> > Then, how about a list of new features in the trunk since the last
> >> > release. That way developers would know if they should become involved
> >> > in the nontrivial (but not too hard) task of compiling GWT from
> >> > source. I take the last comment back if such a list exists. I could
> >> > not find it.
> >>
> >> > Regards.
> >>
> >> > On Jan 20, 4:26 pm, Ray Ryan  wrote:
> >> > > On Wed, Jan 20, 2010 at 6:52 AM, monkeyboy <
> dilbert.elbo...@gmail.com
> >> > >wrote:
> >>
> >> > > > Hello John.
> >>
> >> > > > I'm glad to see that PagingScrollTable will make it to the GWT
> trunk.
> >> > > > Even now it is a useful widget but I can't wait to see the final
> >> > > > version. I would like to ask a few questions. I am sorry to hear
> that
> >> > > > the incubator will be shut down. I was wandering what (if
> anything)
> >> > > > will replace it. With the incubator I as a developer had access to
> >> > > > some tools and widgets that had a great chance to end up in the
> GWT
> >> > > > trunk so I knew that they had a bigger chance to be supported and
> I
> >> > > > dared to include them in my projects (eg. PagingScrollTable). I
> was
> >> > > > burnt a few times with third party gwt libraries found on Google
> code
> >> > > > for which the developer lost interest after a few months and I was
> >> > > > left with a buggy library without support.
> >>
> >> >

Re: [gwt-contrib] GWT Incubator Status Update and Schedule

[Arthur Kalmenson]

Hello John,

This is really great news.

>  We will build upon the lessons learned with these incubator widgets, but the 
> API for the new data backed widgets will evolve significantly from the 
> current APIs.

Is this essentially data binding? Since you've put Form Validation at
GWT 2.2, I guess you'd have to have data binding implemented before
then?

> SliderBar and ProgressBar
> Both of these widgets currently require the use of a global timer, which has
> performance implications. If we can implement these without a resize timer,
> we will include them in GWT 2.2. If we cannot, we will discontinue
> development on them.

If the performance issues are not sorted out, would it be possible to
just spit it off into a different project instead of discontinuing it?
Some people may be willing to accept a performance penalty to use
these widgets.

> Graphics
> The graphics library provides a single, platform independent API that works
> on top of Canvas and VML. The library is not ready for GWT trunk, but this
> project is worth pursuing.

Will you be building on what was done in Speed Tracer for Canvas integration?

Thanks again for the update.

All the best,
--
Arthur Kalmenson



On Tue, Jan 12, 2010 at 1:04 PM, John LaBanca  wrote:
> Incubator Users -
>
> The Google Web Toolkit Incubator project began as a proving grounds for new
> widgets to be vetted before joining the ranks of the GWT trunk. We've seen
> some success stories over the last year with EventHandlers, ClientBundle,
> and DatePicker, but for many of the widgets and libraries, Incubator has
> become an elephant graveyard.
>
> In order to address this issue, we will start graduating some of the
> libraries to GWT trunk, move some into separate projects, and discontinue
> development on others. Ultimately, we will wind down the incubator project
> completely.
>
> The schedule below shows the fate of each subproject in incubator. It's a
> tentative schedule, meaning that it could change as priorities shift.
>
> GWT 2.1
>
> PagingScrollTable and FastTree
> We are working on a new set of data backed widgets for GWT 2.1 that will
> include APIs for trees and tables. We will build upon the lessons learned
> with these incubator widgets, but the API for the new data backed widgets
> will evolve significantly from the current APIs. When the data backed
> widgets are added to GWT trunk, we will stop development on
> the PagingScrollTable and FastTree.
>
> Locale Selection
> Selecting the locale on the server requires one less round trip to the
> server on startup and is needed for effective use of
> runtime locales selection.  This library will be included in GWT 2.1.
>
> GWT 2.2
>
> CollapsiblePanel
> This widget will probably become a subclass of DockingLayoutPanel, similar
> to SplitLayoutPanel.
>
> SliderBar and ProgressBar
> Both of these widgets currently require the use of a global timer, which has
> performance implications. If we can implement these without a resize timer,
> we will include them in GWT 2.2. If we cannot, we will discontinue
> development on them.
>
> Logging
> The logging API may make it into GWT 2.1 if time permits.
>
> Form Validation
> We will take a closer look at the form validation API in GWT 2.2..
>
> Separate Project:
>
> SoundResource
> SoundResource is a promising API for including sound in an application, but
> it makes sense to wait for HTML 5 features to become widely adopted before
> including it. We would like to move SoundResource into the gwt-voices
> project: http://code.google.com/p/gwt-voices/.
>
> Graphics
> The graphics library provides a single, platform independent API that works
> on top of Canvas and VML. The library is not ready for GWT trunk, but this
> project is worth pursuing.
>
> HtmlDecorators
> We will continue to work on this project to arbitrarily add decorations to
> widgets.
>
> As always, please feel free to reply with comments or suggestions.
> Thanks,
> John LaBanca
> on behalf of the GWT team
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: now.. afetr GWT 2.0?

[Arthur Kalmenson]

Hey Brad,

Sorry about that, I've just seen a number of people in the IRC channel
asking about why DevMode was so slow and it turned out they had been
closing it after each check. I just wanted to throw that comment up
there for those that didn't know. I guess our apps haven't got to that
size yet

All the best,
--
Arthur Kalmenson



On Fri, Dec 18, 2009 at 9:50 AM, Brad Leupen  wrote:
> Arthur,
>
> No, we are not closing DevMode. Our client app is not small.
> Refreshing DevMode in 2.0 takes 20-30 seconds on a decent multi-core
> workstation. Often, we are only able to refresh a handful of times
> before we start running into out-of-memory exceptions and browser
> crashes (FF 3.5.6). I don't want to sound unappreciative - DevMode in
> 2.0 is MUCH MUCH faster than before. We are very excited about this.
> However, I rarely need to use the debugger in the actual client. Most
> of the time I just want to refresh the layout or test the usability of
> a widget. For this, DevMode is overkill and, in fact, useless for
> testing real world UI latency.
>
> Draft Compile is a wonderful idea but even it takes over a minute to
> compile a single permutation of our app.
>
> At the end of the day, all i want to do is make a small change to a
> widget and refresh my browser to test the layout, look and feel, and
> usability. over and over and over. Sometimes i might need to debug my
> ui logic but not most of the time.
>
> Brad
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Re: now.. afetr GWT 2.0?

[Arthur Kalmenson]

A lot of people are asking for a faster DevMode, is that because you
are closing DevMode after every change? You don't have to do that, you
can leave DevMode running for the entire day and just refresh the
browser itself (while coding in whichever IDE you wish, as long as
it's compiling the classes into the correct directory). If you make
server side changes, you can just click the "Restart Server" button
under the Jetty tab.

Furthermore, GWT 2.0 adds the "-draftCompile" flag which, according to
the GWT Blog 
http://googlewebtoolkit.blogspot.com/2009/12/introducing-google-web-toolkit-20-now.html

"If you do need to compile to JavaScript often — though hopefully
development mode will dramatically reduce your need to do so — you can
use the GWT compiler's new -draftCompile flag, which speeds up
compiles by skipping optimizations. To be clear, you definitely
shouldn't deploy JavaScript compiled that way, but it can be a time
saver during non-production continuous builds."

-draftCompile in addition to restrictions to the user agent you
compile to (if you can afford to do that during development), should
make your compiles a lot faster.

Hope that helps!

All the best,
--
Arthur Kalmenson



On Thu, Dec 17, 2009 at 3:08 PM, Konstantin.Scheglov
 wrote:
>
>
>>
>> What do folks here think is important?
>
>  +1 for faster DevMode startup.
>  I don't understand why it recompiles all Java classes again and
> again, when Eclipse already has classes in "output" folder.
>  Plus performing JSNI code parsing and applying ASM converters
>  Would be great to cache all these things on disk and start... hm...
> 10 times faster. ;-)
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] uibinder and bnudled CSS

[Arthur Kalmenson]

Hey Nicolas,

> I'm migrating some nice HTML-fragment to GWT. Thanks to UiBinder this
> is really easy and I get a nice result in few hours.
>
> I notice the uiBinder seems to rewrite the CSS rules according to
> browser support (I may be wrong) : my CSS uses CSS3 box-shadow :
>
>box-shadow: 2px 2px 5px #000;
>-moz-box-shadow: 2px 2px 5px #000;
>-webkit-box-shadow: 2px 2px 5px #000;
>
> This works fine on my Chrome browser, but when I use the uibinder
> version I dont' have shadows anymore. The CSS rule filter should not
> remove any -webkit* rule when targeting a webkit based browser,
> sould'it ? Also the box-shadow is supported by recent webkit browsers
> (it is on chrome 4, but this is in the dev channel)

You should probably use the conditional CSS properties to target
specific browsers:
http://code.google.com/p/google-web-toolkit/wiki/CssResource#Conditional_CSS

> 2nd question : If my CSS uses background-image: url(...), can I
> include those images in my ClientBundle and still make references to
> them in my CSS fragement ?

Yep, that's possible with image sprits:
http://code.google.com/p/google-web-toolkit/wiki/CssResource#Image_Sprites

All the best,
--
Arthur Kalmenson



On Thu, Dec 17, 2009 at 7:03 AM, nicolas.deloof
 wrote:
> Hi
>
> I'm migrating some nice HTML-fragment to GWT. Thanks to UiBinder this
> is really easy and I get a nice result in few hours.
>
> I notice the uiBinder seems to rewrite the CSS rules according to
> browser support (I may be wrong) : my CSS uses CSS3 box-shadow :
>
>        box-shadow: 2px 2px 5px #000;
>        -moz-box-shadow: 2px 2px 5px #000;
>        -webkit-box-shadow: 2px 2px 5px #000;
>
> This works fine on my Chrome browser, but when I use the uibinder
> version I dont' have shadows anymore. The CSS rule filter should not
> remove any -webkit* rule when targeting a webkit based browser,
> sould'it ? Also the box-shadow is supported by recent webkit browsers
> (it is on chrome 4, but this is in the dev channel)
>
> 2nd question : If my CSS uses background-image: url(...), can I
> include those images in my ClientBundle and still make references to
> them in my CSS fragement ?
>
> Cheers,
> Nicolas
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

[gwt-contrib] wrong DTD generated for modules in GEP

[Arthur Kalmenson]

Hey everyone,

I just noticed that the DTD used in the GWT modules generated by the
GEP is incorrect. It points to
http://google-web-toolkit.googlecode.com/svn/tags/2.0.0/distro-source/core/src/gwt-module.dtd
which doesn't exist. Looks like the fix would be pretty easy though,
just create a 2.0.0 tag in the repo, because
http://google-web-toolkit.googlecode.com/svn/tags/2.0.0-rc1/distro-source/core/src/gwt-module.dtd
works.

All the best,
--
Arthur Kalmenson

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

Re: [gwt-contrib] now.. afetr GWT 2.0?

[Arthur Kalmenson]

> Working on a draft one.
> What do folks here think is important?

- data binding and validation frameworks, which would remove a _lot_
of boiler plate code and greatly increase productivity.
- incubator clean up and perhaps splitting it into multiple projects?

GWT 2.0 release is awesome, thanks for all the great work!

--
Arthur Kalmenson



On Wed, Dec 16, 2009 at 12:01 PM, Bruce Johnson  wrote:
> Working on a draft one.
> What do folks here think is important?
>
> On Wed, Dec 16, 2009 at 7:42 AM, tfreitas  wrote:
>>
>> What about roadmap?
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Re: Problems with UiBinder Internals

[Arthur Kalmenson]

Sorry to jump in here, but that looks almost like data bindings Ray. I
missed that feature of uibinder too. I tried it out and you're able to
bind from a POJO during initialization, I wonder if that could be used
as a starting point to do data bindings on set and get. Thanks!

--
Arthur Kalmenson



On Tue, Dec 15, 2009 at 1:08 AM, Ray Ryan  wrote:
> It's already there. Do something like:
> class ParamValuesPojo {
>   private final String uri;
>   private final String token;
>   ParamValuesPojo(String uri, String token) {
>     this.uri = uri;
>     this.token = token;
>   }
> public class UploaderWidgetImplIE extends UploaderWidgetImpl {
>    final @UiField(provided=true) ParamValuesPojo paramValues;
>    UploaderWidgetImplIE(ParamValuesPojo values) {
>        this.paramValues = values;
>        setElement(binder.createAndBindUi(this));
>    }
> }
> 
>   
>    
>                            name="Uploader" width="100%" height="350"
>                codebase="http://java.sun.com/update/1.6.0/jinstall-6u16-
> windows-i586.cab#Version=6,0,0,1">
>                 value="org.jets3t.apps.uploader.Uploader.class" />
>                
>                                    value="uploader-0.7.1-signed.jar,jets3t-0.7.1-
> signed.jar,jets3t-gui-0.7.1-signed.jar,commons-codec-1.3-
> signed.jar,commons-httpclient-3.1-signed.jar,commons-logging-1.1.1-
> signed.jar" />
>                
>                
>                
>                
>                
>                No Java Support.
>            
>    
> 
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

[gwt-contrib] UiBinder first impressions

[Arthur Kalmenson]

Hello everyone,

We've been playing with UiBinder and I thought it'd be a good idea to
share what we've seen so far (and ask some questions).

Some of the apps we write are used by more then one hospital and this
requires a tailored UI depending on the user's preferences and to
store additional information that a particular hospital needs to keep
track of. At the moment, writing UI in a swing style, we program to
interfaces and use GIN to bind everything together. Using different
AbstractGinModules and Ginjectors, we can tie the application together
in different ways using different UI implementations. What would be
the way to do this with UiBinder? From what we could tell, one would
use UiTemplate, but there doesn't seem to be a way to configure the
String in UiTemplate easily through a GIN module. Are there
alternatives?

Following the programming to interfaces theme, we've been doing that
with UiBinder, but have run into an issue when trying to build a
larger UI page out of smaller ui.xml classes. It seems that referring
to interfaces in ui.xml doesn't work, so you need to work with direct
concrete classes. But this would force you to use a particular
implementation when we'd like to keep it generic.

Lastly, I guess this is something just for consideration for the
future, but having the GEP work with UiBinder would make using it a
lot easier. For example, having code completion, refactoring support
and error messages right in Eclipse. This would be something like the
Spring IDE plugin that one you configure Spring XML files with all the
above features.

Thanks again for the UiBinder, we'll definitely have to spend more time with it.

Best regards,
--
Arthur Kalmenson

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

[gwt-contrib] Re: Inlining nocache.js

[Arthur Kalmenson]

> Are you counting fetching the host HTML page?  With this approach, the
> selection script is done away with but you still have a fetch for the
> compiled script so that it can remain permanently cacheable.  You could
> theoretically inline it into the host page, but since none of that is
> cacheable that would only make sense for very tiny compiled outputs.

I don't think firebug counts the initial request to fetch the host
page, so two requests. One for the nocache.js and another for the
cachable HTML. With the inlining of the nocache.js file, you could get
it down to 0 requests if the retrieved page is cached forever.

Are you saying to inline the generated JS in the host page too? How
could you do that? Don't you need the selector script to pick the
correct compiled version? Maybe I'm just not understanding what you
mean.

> 2 requests is very impressive, Arthur! This is the sort of conscientiousness
> (i.e. for optimizing user experience) I hope all GWT developers would strive
> for. Nice work.
> And yes, we'd like to help you get that down to 1, too.

Thanks Bruce! But it's really all thanks to Bob's ClientBundle :)

--
Arthur Kalmenson



On Fri, Aug 7, 2009 at 9:57 AM, John Tamplin wrote:
> On Fri, Aug 7, 2009 at 9:43 AM, Arthur Kalmenson 
> wrote:
>>
>> I'd love to see this in the trunk too. We have only 2 round trips on
>> start up now, thanks to ClientBundle. Getting it down to one will be
>> very slick!
>
> Are you counting fetching the host HTML page?  With this approach, the
> selection script is done away with but you still have a fetch for the
> compiled script so that it can remain permanently cacheable.  You could
> theoretically inline it into the host page, but since none of that is
> cacheable that would only make sense for very tiny compiled outputs.
>
> Note that there is a cost, as your host HTML page now can't be cached (since
> the selection script essentially runs in the server).  If your host page is
> complex, this may be a net loss.  You could try leaving it cacheable but
> setting Vary headers for the pieces that you use to make the decision, but
> my understanding is that many caches do not handle this properly.
>
> Also, you cannot use any deferred binding properties that can't be
> determined by the HTTP fetch of your host page.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: Inlining nocache.js

[Arthur Kalmenson]

I'd love to see this in the trunk too. We have only 2 round trips on
start up now, thanks to ClientBundle. Getting it down to one will be
very slick!

--
Arthur Kalmenson



On Fri, Aug 7, 2009 at 8:41 AM, Cameron Braid wrote:
> I'd be keen to see this land in trunk !
>
> Cam
>
> 2009/8/7 John Tamplin 
>>
>> On Fri, Aug 7, 2009 at 3:51 AM, George Georgovassilis
>>  wrote:
>>>
>>> I'd like to save first time visitors that roundtrip to fetch
>>> nocache.js. Instead I've declared the module HTML page as non-
>>> cacheable (works nice thanks to E-Tag) and moved images and GWT-
>>> compiler output to a fully cacheable directory.
>>>
>>> After inlining nocache.js into the module HTML I had to change the
>>> paths to the XYZ.cache.html permutations, but couldn't get RPC to work
>>> reliably across all browsers.
>>>
>>> Is there a way to do this cleanly?
>>
>> There is a Google-internal linker that does this, and will be cleaned up
>> and moved to GWT itself in the near future.  I don't know an exact timeframe
>> for this however.
>>
>> --
>> John A. Tamplin
>> Software Engineer (GWT), Google
>>
>>
>
>
> >
>

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

[gwt-contrib] Re: [INFO] A new version of GWT (1.7.0) is available

[Arthur Kalmenson]

Eric, are you using Maven? It might be the GWT Maven Plugin doing
that, not GWT itself.

--
Arthur Kalmenson



On Sat, Aug 1, 2009 at 9:06 PM, Eric B. Ridge wrote:
>
> I'm a random lurker who recently started using GWT 1.6.  Since 1.7 was
> released (to which I have not yet upgraded), I now see this in the
> hosted mode log window:
>
>    [INFO] A new version of GWT (1.7.0) is available
>
> Without trying to be argumentative, is it really necessary for a
> supporting application of a web development framework to phone home
> every it is started?
>
> If the answer is yes, could a command-line option be provided to
> disable this?
>
> Thanks for your time and consideration.
>
> eric
>
> ps, GWT is basically the greatest thing ever.  I'm not yet sure if
> it's better than sex, but it is better than most US domestic beers.
> Additionally, if I ever meet a GWT developer on the street, I might
> want to hug.
>
> >
>

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

[gwt-contrib] Re: UIBinder

[Arthur Kalmenson]

Today sounds like it'll be the day we switch to trunk ;)

--
Arthur Kalmenson



On Tue, Aug 4, 2009 at 9:42 AM, Ray Ryan wrote:
>
> How does today strike you? It's headed into gwt trunk, and will be
> part of the 2.0 release.
>
> On Tuesday, August 4, 2009, brett.wooldridge  
> wrote:
>>
>> Ping.  This not "this month" any more, it's "early next".  Got a
>> revised (rough) ETA for UIBinder in SVN?  I would even love to hear
>> "definitely this month, but we don't know when".
>>
>> -Brett
>>
>> On Jul 15, 1:25 am, Ray Ryan  wrote:
>>> It's coming RSN. We're trying to get UiBinder into GWT 2.0. It will
>>> certainly be in SVN this month or early next.
>>> I know I've been saying that for a while, but now we're actually, like,
>>> working to make it happen.
>>>
>>> On Mon, Jul 13, 2009 at 11:05 PM, brett.wooldridge <
>>>
>>> brett.wooldri...@gmail.com> wrote:
>>>
>>> > I've read the docs for UIBinder in the wiki, and like everyone else
>>> > who has read it, I am anxious to start using it.  However, even though
>>> > the doc and examples are in the wiki, I am unable to find the UIBinder
>>> > code in svn.  Is it available?   Or can it be made available?  Rough
>>> > or not, documented or not, there are many developers who would like to
>>> > start playing with it (and helping to fix issues).
>>>
>>> > Thanks
>>> > Brett
>> >
>>
>
> >
>

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

[gwt-contrib] Re: Generalized RPC for server-enhanced objects

[Arthur Kalmenson]

This sounds very promising! Will there be (is there already?) a wiki
page explaining how this works?

Regards,
--
Arthur Kalmenson



On Wed, Jul 29, 2009 at 3:04 PM,  wrote:
>
> Reviewers: robertvawter_google.com, scottb,
>
> Description:
> This patch removes the previous special-case handling of JDO objects in
> favor of a more general approach.  First we determine which classes may
> be enhanced, based on annotations in the classes themselves or a new
> "rpc.enhancedClasses" configuration property.  For those classes that
> are (possibly) enhanced and which may be transmitted in both directions
> between client and server, we place a list of client-visible methods
> into the .gwt.rpc file containing the RPC-able classes.  At runtime, we
> use this list to identify any server-only fields and apply server-side
> serialization to them.  When deserializing an enhanced object on the
> server, we user setter methods where possible rather than direct field
> writes.
>
>
> Please review this at http://gwt-code-reviews.appspot.com/51823
>
> Affected files:
>   user/src/com/google/gwt/user/RemoteService.gwt.xml
>   user/src/com/google/gwt/user/rebind/rpc/ClientDataSerializer.java
>   user/src/com/google/gwt/user/rebind/rpc/FieldSerializerCreator.java
>
> user/src/com/google/gwt/user/rebind/rpc/JdoDetachedStateClientDataSerializer.java
>   user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java
>   user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracle.java
>   user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilder.java
>   user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleImpl.java
>   user/src/com/google/gwt/user/rebind/rpc/Shared.java
>   user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java
>   user/src/com/google/gwt/user/server/rpc/SerializationPolicy.java
>   user/src/com/google/gwt/user/server/rpc/SerializationPolicyLoader.java
>
> user/src/com/google/gwt/user/server/rpc/impl/JdoDetachedStateServerDataSerializer.java
>
> user/src/com/google/gwt/user/server/rpc/impl/LegacySerializationPolicy.java
>   user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java
>   user/src/com/google/gwt/user/server/rpc/impl/ServerDataSerializer.java
>
> user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
>
> user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamWriter.java
>
> user/src/com/google/gwt/user/server/rpc/impl/StandardSerializationPolicy.java
>
> user/super/com/google/gwt/user/translatable/com/google/gwt/core/client/impl/WeakMapping.java
>   user/test/com/google/gwt/user/server/rpc/RPCTest.java
>
> user/test/com/google/gwt/user/server/rpc/impl/StandardSerializationPolicyTest.java
>
>
>
> >
>

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

[gwt-contrib] Re: bombarded by commit messages?

[Arthur Kalmenson]

Finger slipped? :P

On Jul 28, 8:15 pm, Scott Blum  wrote:
> Nothing to see here... move along please.
>
>
>
> On Tue, Jul 28, 2009 at 8:14 PM, Ray Cromwell  wrote:
>
> > Anyone else just get bombarded by about 20+ old commit messages? I got
> > messages from stuff committed days ago.
>
> > -Ray
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: GWT emulation of HTML5/CSS3 features

[Arthur Kalmenson]

This would definitely be a killer feature.

A common API for something like Web Workers and App Cache (maybe
wrapper for http://code.google.com/p/webstorageportabilitylayer/) that
can seamlessly switch talk to Gears or native HTML 5 implementation
would be very nice. I think it's a lot easier to convince a company to
install Gears then installing and using a completely new browser, so
at least for enterprise settings some common API would be very useful.

Regards,
--
Arthur Kalmenson



On Mon, Jun 29, 2009 at 10:24 AM, dflorey wrote:
>
> Hi,
> I've been wondering how GWT should deal with upcoming new features in
> HTML5/CSS3.
> There are several areas where functionality that has been implemented
> in GWT is now also available in the upcoming rendering engines.
>
> GWT is creating highly optimized JavaScript and the JavaScript-engines
> are getting better and better... but: My guess is that for example
> animations will be smoother when using CSS3 animations instead of
> JavaScript based animations.
> Same about rounded corners/shadows and stuff alike. In GWT you'll
> typically use DecoratedPanel to implement rounded corners with
> shadows. But Firefox3.5 and the latest Safari and Chrome releases also
> support css-based rounded borders and shadows.
>
> So my proposal would be to use deferred binding to "emulate" these
> features on browsers that do not support the latest features (IE8...)
> and to use a lightweight css based impl on WebKit/Firefox 3.5.
>
> In my example of DecoratedPanel the 9x9 approach should be kept for IE
> and a null impl with css based rounded corners should be available for
> Firefox (css have to match the given theme).
> Animations that come with the standard widgets should also be able to
> fallback to css based animations when available.
>
> I've been also reading some posts about the new datagrid html
> extension and thought it might be clever to have a look at the spec
> when moving the tables from incubator to trunk to see how far the
> concepts match. Would be very cool to have a native table
> implementation on WebKit browsers while other fallback to gwt impls.
>
> What do you think?
> >
>

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

[gwt-contrib] Re: UIBinder

[Arthur Kalmenson]

Sweet, can't wait :)

--
Arthur Kalmenson



On Tue, Jul 14, 2009 at 12:25 PM, Ray Ryan wrote:
> It's coming RSN. We're trying to get UiBinder into GWT 2.0. It will
> certainly be in SVN this month or early next.
> I know I've been saying that for a while, but now we're actually, like,
> working to make it happen.
>
> On Mon, Jul 13, 2009 at 11:05 PM, brett.wooldridge
>  wrote:
>>
>> I've read the docs for UIBinder in the wiki, and like everyone else
>> who has read it, I am anxious to start using it.  However, even though
>> the doc and examples are in the wiki, I am unable to find the UIBinder
>> code in svn.  Is it available?   Or can it be made available?  Rough
>> or not, documented or not, there are many developers who would like to
>> start playing with it (and helping to fix issues).
>>
>> Thanks
>> Brett
>>
>>
>
>
> >
>

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

[gwt-contrib] Re: Continuous integration

[Arthur Kalmenson]

Good question, I'd be interested in a nightly build of GWT trunk as well.

--
Arthur Kalmenson



On Thu, Jun 25, 2009 at 4:14 AM, nicolas de
loof wrote:
> Hi
> is there a pulic CI server for GWT 2.0 where I could get the latest 2.0
> artifacts ?
> I'd like to improve the gwt-maven-plugin for gwt-2.0, but for Integration
> testing I'd like to use the latests code, not just the one I could build
> myself
> Cheers,
> Nicolas
> >
>

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

[gwt-contrib] Re: naming runAsync calls

[Arthur Kalmenson]

For what it's worth, I like the moniker class idea best. Staying type
safe, IMHO, is always a good thing.

With regards to the downside John Tamplin mentioned (multiple runAsync
calls in one class), why not consider that a feature? Since the
original idea of naming the runAsync call is to allow for prefetching,
putting several runAsync class in one class could allow you to easily
prefetch a particular large chunk of code. If you find you don't want
to prefetch, nothing happens and little pieces download each time.

If you put this together with Bruce's class hierarchy idea, you might
be able to provide a single name to call to fetch the entire
application. This could be integrated with a "Go offline" button for
an easy download everything call.

With this idea of using moniker classes, would you still provide the
class name as a parameter to runAsync or would the compiler just
assume the name of the runAsync call is the name of the class it lives
in? If you allow providing a class name, would you check it's the name
of the class the call is in? I like the automagic naming using the
class name.

Best regards,
--
Arthur Kalmenson

P.S. Naming to allow for prefetching is an awesome idea. I was
thinking how one would prefetch components while watching the GWT
Google I/O sessions. This would definitely make going offline easy
too.


On Wed, Jun 24, 2009 at 10:55 PM, Cameron Braid wrote:
> All good points.
>
> Would interfaces be supported as well ?
>
> Are there any dangers of allowing arbitrary classes (or interfaces) to be
> used as monikers ?
>
> i.e from your example, would there be anything wrong with using
> EmailCompositionView.class as the moniker ?
>
>> void onComposeButtonClicked() {
>>  GWT.runAsync(EmailCompositionView.class, new AsyncCallback() {
>>    public void onError(Throwable e) { ... }
>>       public void onSucess() {
>>         new EmailCompositionView().activate();
>>     }
>>   });
>
> I guess the compiler would have to verify that each call to runAsync uses a
> unique moniker - is there anything else ?
>
> Must the moniker class exists in your own module ?
>
> Would you only allow leaf classes to be used as monikers, i.e. could you use
> OfficeSuiteSplitPoint.class as a moniker ?
>
> Cam
>
> 2009/6/25 Bruce Johnson 
>>
>> Four additional arguments in favor of using "split point moniker classes"
>> is that they
>> 1) are easier to find within an IDE (i.e. "Show References" in your IDE
>> from a moniker class declaration would show you the associated runAsync
>> call),
>> 2) can take advantage of inheritance as a way to group split points into
>> meaningful families (which would make them more easily browsable and
>> navigable in javadoc and in an IDE),
>> 3) can be javadoc'ed to explain what they do, and
>> 4) they could potentially be augmented with additional hints to the code
>> splitter using annotations (these are a stretch; Lex might be able to think
>> of more realistic example annotations)
>>
>> /**
>>  * Split points in this hierarchy relate to the email functionality within
>> the office suite.
>>  */
>> class EmailSplitPoint extends OfficeSuiteSplitPoint {
>> }
>>
>> /**
>>  * This split point carves out all heavyweight functionality related to
>> composing emails,
>>  * most importantly, the rich text area clases.
>>  */
>> @ProhibitPreloading
>> @MustBeExclusiveFragment
>> class EmailCompositionSplitPoint extends EmailSplitPoint {
>> }
>>
>> // ... elsewhere ...
>>
>> void onComposeButtonClicked() {
>>   GWT.runAsync(EmailCompositionSplitPoint.class, new AsyncCallback() {
>>     public void onError(Throwable e) { ... }
>>     public void onSucess() {
>>   new EmailCompositionView().activate();
>>     }
>>   });
>> }
>>
>> On Wed, Jun 24, 2009 at 6:50 PM, Cameron Braid 
>> wrote:
>>>
>>> Each of these different libraries would be enclosed within a unique GWT
>>> module therefore when you refer to the split point name, can't you just use
>>> the module name + split point name ?
>>>
>>> in module ThirdParty :
>>>
>>> GWT.runAsync("one", new RunAsyncCallback() { ... });
>>>
>>> in MyModule :
>>>
>>> GWT.runAsync("one", new RunAsyncCallback() { ... });
>>>
>>> >> name="compiler.splitpoint.initial.sequence" value="MyModule#one" />
>>> >> name="compiler.splitpoint.initial.sequence" value="ThirdParty#one" />
>>>
>>> Cam
>

[gwt-contrib] Re: Extracting feature

[Arthur Kalmenson]

Would it be better to post this to the GWT Discussion Group? You'll
get a lot more feedback there. You can find the group here:
http://groups.google.com/group/Google-Web-Toolkit

--
Arthur Kalmenson



On Mon, Jun 22, 2009 at 5:10 PM, Elad and Osnat wrote:
>
> Here is a link to the project page
> http://code.google.com/p/extractingfeature
> Since we need to hand out this project very shortly - we will be happy
> to get your remarks as soon as possible. Thanks!
>
> On 22 יוני, 15:04, Joel Webber  wrote:
>> I may have missed something, but it's not clear exactly what and where the
>> project you're referring to is. If you could include a link to a project
>> page, that would be helpful.
>>
>> On Sun, Jun 21, 2009 at 10:37 AM, Elad and Osnat 
>> wrote:
>>
>>
>>
>>
>>
>> > Hi,
>>
>> > We will appreciate if you could find time to look at our new
>> > extracting feature to GWT content,
>> > and to give us your remarks as soon as possible.
>> > All the information about this feature is in the Extracting library
>> > and ITM.txt file that was upload an June 15.
>> > The extracting library itself is in E1.rar that was upload aslo at
>> > June 15.
>> > For any problems or questions please turn to us.
>>
>> > Thanks a head,
>> > Elad and Osnat.-הסתר טקסט מצוטט-
>>
>> -הראה טקסט מצוטט-
> >
>

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

[gwt-contrib] Re: Java source transformation

[Arthur Kalmenson]

> Now, MyBean does not implement interface X, but a generator/AOP
> interceptor could make a subclass of MyBean that has interface X
> implement. IIRC, GWT RPC just invokes the default constructor, so
> there's no way to intercept this and substitute a replacement.

Yeah, that is an interesting question. However, wouldn't the AOP be
happening before you send the object over the wire? You wouldn't
really care about any interception at that point

--
Arthur Kalmenson



On Wed, Apr 22, 2009 at 12:28 AM, Ray Cromwell  wrote:
>
> On Tue, Apr 21, 2009 at 7:11 PM, Arthur Kalmenson  
> wrote:
>>
>> Hmm, but don't you normally send some kind of Model or domain object
>> over the wire and not something that would need to be injected with
>> dependencies by Gin?
>
>
> I think what he's saying is that he might have an RPC method like this:
>
> public interface MyService extends RemoteService {
>   MyBean getBean();
> }
>
> Now, MyBean does not implement interface X, but a generator/AOP
> interceptor could make a subclass of MyBean that has interface X
> implement. IIRC, GWT RPC just invokes the default constructor, so
> there's no way to intercept this and substitute a replacement.
>
> I think the other thing he might want to do is intercept client-side
> UI classes and make them call addPropertyChangeListener() on a model
> object based on certain invocations.
>
> -Ray
>
>> And Bruce, that's an interesting example. I was thinking how one would
>> implement AOP in GWT, perhaps it's not as hard as I originally
>> thought. Is there a way to extend this example to dynamically create
>> proxies for any class that'll be advised by some aspect?
>>
>> Also, Nicolas, AFAIK, the GWT team (bobv) is working on a data binding
>> (and validation?) framework. I'm hoping something will hit the
>> incubator soon so we can all jump on board and help out. It'd
>> definitely have saved us thousands of lines of glue code ;).
>>
>> P.S. Sorry about not writing up that how-to for GWTMockUtilities,
>> Bruce. I'll try to do it some time this week.
>>
>> Best regards,
>> --
>> Arthur Kalmenson
>>
>>
>>
>> On Tue, Apr 21, 2009 at 2:58 PM, Ray Cromwell  wrote:
>>>
>>> Interesting question. Gin auto-creates RPC interfaces as well, for
>>> example, if you have:
>>>
>>> public interface MyFoo extends Ginjector {
>>>   MyServiceAsync getService();
>>> }
>>>
>>> then Gin implicitly looks for MyService.class and invokes
>>> GWT.create(MyService.class) when calling getService(). Since Gin is
>>> handling the creation, I'm not sure if it handles RPC methods with
>>> classes have have @Inject annotations, but you could probably setup a
>>> separate binding. The de-serialization logic in RPC is not likely to
>>> allow Gin interception, since it apparently uses default constructors
>>> to create classes, and what you want it to do is delegate the
>>> construction to some injectable mechanism (e.g. to substitute your own
>>> subclasses)
>>>
>>> It doesn't sound impossible to make this work, and is probably easier
>>> to get right than trying to make new Foo() interceptable by the
>>> compiler. I would join the Gin groups and ask the guys there about it.
>>>
>>> -Ray
>>>
>>>
>>> On Tue, Apr 21, 2009 at 11:49 AM, nicolas de loof
>>>  wrote:
>>>> Sounds a good solution.
>>>> How would this solve the use case "data returned by RPC call" ?
>>>>
>>>> 2009/4/21 Ray Cromwell 
>>>>>
>>>>> I really think Guice-style dependency injection is the way to go to
>>>>> solve this problem, rather than trying to emulate Java
>>>>> Proxies/Classloader in the compiler. If you use Guice/Gin, then in Gin
>>>>> you can inject GWT.create-d versions, and in JUnit-mode, you can use
>>>>> regular Guice injection. The code use is 99% between GWT and non-GWT
>>>>> versions test versions, with the exception of the
>>>>> Guice-config/Injector creation.
>>>>>
>>>>> Because of the way Gin works transitively, you only need a single
>>>>> GWT.create() and this is isolated to your startup code while in your
>>>>> JUnit version, you kick off a Guice-injected class instead.
>>>>>
>>>>> -Ray
>>>>>
>>>>> On Tue, Apr 21, 2009 at 11:28 AM, nicolas de loof
>>>

[gwt-contrib] Re: Java source transformation

[Arthur Kalmenson]

Gin actually falls back on calling GWT.create() if it can't find a
binding for an injected dependency. This means that, using Bruce's
example, you could have something like this:

public class SomeWidget() {

  @Inject
  public SomeWidget(PersonBeanWithMethodCallLogger personBean) {
person.getName();
  }
}

All you need to do is bind SomeWidget, but no implicit binding is
required for PersonBeanWithMethodCallLogger. It might actually work if
you inject PersonBean, I'll check it out later though.

With regards to unit testability. If you use Gin throughout, and don't
instantiate any UIObject anywhere in your code (but rather DI them),
you can fully mock anything if you use GWTMockUtilities calling the
disarm() and restore() methods (see the class' Javadoc). You can then
write integration tests using GWTTestCase by having a Ginjector inside
your test case and calling GWT.create() on it.

> ... I'm not sure if it handles RPC methods with
> classes have have @Inject annotations

Hmm, but don't you normally send some kind of Model or domain object
over the wire and not something that would need to be injected with
dependencies by Gin?

And Bruce, that's an interesting example. I was thinking how one would
implement AOP in GWT, perhaps it's not as hard as I originally
thought. Is there a way to extend this example to dynamically create
proxies for any class that'll be advised by some aspect?

Also, Nicolas, AFAIK, the GWT team (bobv) is working on a data binding
(and validation?) framework. I'm hoping something will hit the
incubator soon so we can all jump on board and help out. It'd
definitely have saved us thousands of lines of glue code ;).

P.S. Sorry about not writing up that how-to for GWTMockUtilities,
Bruce. I'll try to do it some time this week.

Best regards,
--
Arthur Kalmenson



On Tue, Apr 21, 2009 at 2:58 PM, Ray Cromwell  wrote:
>
> Interesting question. Gin auto-creates RPC interfaces as well, for
> example, if you have:
>
> public interface MyFoo extends Ginjector {
>   MyServiceAsync getService();
> }
>
> then Gin implicitly looks for MyService.class and invokes
> GWT.create(MyService.class) when calling getService(). Since Gin is
> handling the creation, I'm not sure if it handles RPC methods with
> classes have have @Inject annotations, but you could probably setup a
> separate binding. The de-serialization logic in RPC is not likely to
> allow Gin interception, since it apparently uses default constructors
> to create classes, and what you want it to do is delegate the
> construction to some injectable mechanism (e.g. to substitute your own
> subclasses)
>
> It doesn't sound impossible to make this work, and is probably easier
> to get right than trying to make new Foo() interceptable by the
> compiler. I would join the Gin groups and ask the guys there about it.
>
> -Ray
>
>
> On Tue, Apr 21, 2009 at 11:49 AM, nicolas de loof
>  wrote:
>> Sounds a good solution.
>> How would this solve the use case "data returned by RPC call" ?
>>
>> 2009/4/21 Ray Cromwell 
>>>
>>> I really think Guice-style dependency injection is the way to go to
>>> solve this problem, rather than trying to emulate Java
>>> Proxies/Classloader in the compiler. If you use Guice/Gin, then in Gin
>>> you can inject GWT.create-d versions, and in JUnit-mode, you can use
>>> regular Guice injection. The code use is 99% between GWT and non-GWT
>>> versions test versions, with the exception of the
>>> Guice-config/Injector creation.
>>>
>>> Because of the way Gin works transitively, you only need a single
>>> GWT.create() and this is isolated to your startup code while in your
>>> JUnit version, you kick off a Guice-injected class instead.
>>>
>>> -Ray
>>>
>>> On Tue, Apr 21, 2009 at 11:28 AM, nicolas de loof
>>>  wrote:
>>> > A simple example : databinding
>>> > Lets consider I want to bind some Label text to some model Bean value.
>>> > Gwt
>>> > Label widget "text" can be accessed as a javaBean property, so this
>>> > sound a
>>> > typical java.beans.binding use-case
>>> > This requires my model bean to support PropertyChangeListeners. As I'm
>>> > lazy
>>> > I'd like a generator to create an "enhanced" model class with such
>>> > support
>>> > for the "value" property.
>>> > I can get this to work today if my model Bean is created using
>>> > GWT.create(),
>>> > but this makes my code GWT-dependant and not testable in "standalone"
>>> > junit.
&

[gwt-contrib] Re: Java source transformation

[Arthur Kalmenson]

With regards to AOP, as Ray mentioned, you might want to check out
Google GIN. They haven't yet implemented Interceptors (AFAIK), so you
might want to combine efforts with them to get this to work.

With regards to data binding, bobv is, AFAIK, working on that feature.
If you hold off until it's dropped in the incubator, you could avoid
duplicate work.

Best regards,
--
Arthur Kalmenson



On Mon, Apr 20, 2009 at 3:03 AM, nicolas de loof
 wrote:
>
> What I'm looking for is both some AOP capability and a way to port javaFx
> "bind" keyword to Java / GWT.
> gwt-beans-binding is doing databinding using marker interface in model and
> "wrappers" for widgets. This makes impossible to use advanced widgets from
> 3rd tier librairy without some more code to write.
> Anyway, thanks a lot for this interesting link.
> Nicolas
>
> 2009/4/20 Ray Cromwell 
>>
>> GWT generators cannot access the source AST of the original class,
>> only the class metadata (fields/method names, parameters, signatures),
>> no method body stuff. If you're looking to do AOP/Method Interception,
>> I suggest you take a look at Google Gin which is a Guice
>> implementation for Git. It's a dependency injection framework, and
>> you'll only need a single GWT.create() call in the beginning to start
>> the process.
>>
>> You can't 'intercept' classes with regular GWT generators like you can
>> with a classloader if that's what you're trying to do. But with Gin,
>> the dependency injection is transitive, so in effect, you can
>> intercept other classes that appear as injected parameters or fields.
>>
>> -Ray
>>
>>
>> On Sun, Apr 19, 2009 at 11:43 PM, nicolas de loof
>>  wrote:
>> >>
>> >> > I wonder if there is any way to also "pre-process" Java sources, for
>> >> > example
>> >> > this would enable support for Aspect Oriented Programming or maybe
>> >> > some
>> >> > DataBinding framework.
>> >>
>> >> Depends what you mean by "pre-process"... Generally, generators
>> >> analyze the class they're called for (for example, looking for
>> >> specific annotations on methods or on the class itself) and according
>> >> to this generate a Java class extending the one they've been called
>> >> for.
>> >> (is this understandable? is this at least no-so-bad english?)
>> >
>> > In many case the generator will create from MyClassX some MyClassXImpl
>> > or
>> > equivalent that extends the original one, bu not REPLACE it as Java
>> > source.
>> > This is what I mean by "pre-process".
>> > For example, to implement a AOP framework I'd like to instrument all
>> > calls
>> > to some method. For this reason I'd like a generator / pre-processor to
>> > check the source files and detect the matching pointcuts to add some
>> > adived
>> > code. Many other example can apply, including annotation processing for
>> > declarative coding (ex : @Property annotation to automagically introduce
>> > the
>> > required PropertyChangeListeners)
>> > I never tried it myself, but I'n not sure a generator can REPLACE the
>> > original Java Source. I may be wrong but I also thing the generated code
>> > is
>> > only available when using   GWT.create(), making the code less testable
>> > (with standard junit, not GWTTestCase) and fully GWT-dependenant.
>> > Cheers,
>> > Nicolas
>> >
>> >
>> >>
>> >
>> >
>> > >
>> >
>>
>>
>
>
> >
>

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

[gwt-contrib] Re: Google Plugin for Eclipse

[Arthur Kalmenson]

Is the Google Eclipse Plugin not a Google Code OSS project?

--
Arthur Kalmenson



On Thu, Apr 16, 2009 at 11:18 PM, Alex Rudnick  wrote:
>
> Gary,
>
> Here is fine (alternatively, on the Google-Web-Toolkit group). What
> issues and questions have you got?
>
> On Thu, Apr 16, 2009 at 8:20 PM, Gary Miller  wrote:
>>
>> Where is the correct place to post issues and questions for Google
>> Plugin for Eclipse?
>
>
>
> --
> Alex Rudnick
> swe, gwt, atl
>
> >
>

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

[gwt-contrib] Re: GWT-RPC broken in GAE/J

[Arthur Kalmenson]

I haven't tried GAE/J just yet, but I'm guessing the problem with JPA
is the same one you would have with any database. If your domain
objects aren't very large, you can use Dozer to map the object onto
itself which removes all the enhancements and makes them regular
objects.

--
Arthur Kalmenson



On Fri, Apr 10, 2009 at 12:30 PM, Ray Cromwell  wrote:
>
> The only 'real' way to make detached entities to work with GWT would be to
> make the 'enhancer' generate Java source like a GWT generator OR make an
> interface like 'Detachable' and have a GWT generator do it, because not only
> do you need the extra state fields (jdoDetachedState), but the method calls
> of the class have to be intercepted to manipulate the detached state.
> Actually, a generator probably can't do it because IIRC JDO enhancement
> involves intercepting even field references, and Generators don't get an
> AST.
>
> So it's either transient instances, or some kind of Ant task that generates
> GWT-friendly DTO helper classes for you along with the enhancement process.
> -Ray
> On Fri, Apr 10, 2009 at 7:19 AM, Robert Hanson 
> wrote:
>>
>> I didn't see a thread on this yet, but the GWT-RPC doesn't work well
>> in GAE with JPA.  It seems that the JPA entities are "enhanced" at
>> compile time, and this is not compatible with the GWT serialization on
>> the client side.  The GWT app complains that the serialization is not
>> compatible.
>>
>> Ray has a workaround, but it is less than ideal
>>
>> http://timepedia.blogspot.com/2009/04/google-appengine-and-gwt-now-marriage.html
>>
>> And you can always use a DTO, but I recall that Serializable was added
>> to GWT just so that you didn't need to do that.
>>
>> So... I'm not really asking for a fix... I am more wondering what the
>> "official response" is.  Is this something that you want to fix,
>> something that isn't safe to fix, or something that you don't want to
>> fix?
>>
>> Thanks.
>>
>> Rob
>>
>>
>
>
> >
>

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

[gwt-contrib] Re: Announcing GWT 1.6...and quite a bit more

[Arthur Kalmenson]

*jaw drops*

--
Arthur Kalmenson



On Wed, Apr 8, 2009 at 3:44 AM, stuckagain  wrote:
>
> Great news,
>
> Any chance for getting an offline installation for the eclipse
> plugin ? Company policy makes it impossible to connect my development
> machine to the internet.
>
> Davdi
>
> On Apr 8, 5:54 am, Bruce Johnson  wrote:
>> Hi Folks!
>>
>> Exciting news today. Rather than attempting to describe everything here, let
>> me point you to some blog posts that hopefully you will find interesting:
>>
>> GWT 1.6 and 
>> friends:http://googlewebtoolkit.blogspot.com/2009/04/introducing-gwt-16-and-f...
>>
>> Seriously this time, the new language on App Engine: 
>> Javahttp://googleappengine.blogspot.com/2009/04/seriously-this-time-new-l...
>>
>> Google Plugin for Eclipse -- Peanut Butter to Eclipse's 
>> Chocolatehttp://googlewebtoolkit.blogspot.com/2009/04/google-plugin-for-eclips...
>>
>> -- Bruce, on behalf of the GWT, App Engine, and Google Plugin teams
> >
>

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

[gwt-contrib] Re: Feature request: RPC automagically transferred values

[Arthur Kalmenson]

It depends on how you are building your authorization. If you use
something like Spring Security, this is done automatically with every
RPC you make.

--
Arthur Kalmenson



On Wed, Apr 1, 2009 at 11:43 PM, John Tamplin  wrote:
> On Wed, Apr 1, 2009 at 10:22 PM, Vitali Lovich  wrote:
>>
>> I've encountered this pattern a few times, and think it would be great if
>> the RPC layer could be given a serializable object that is always
>> transferred on every RPC call.
>>
>> In the GWT security documentation it says not to use cookies but instead
>> pass the session id manually on every RPC call, which is a real hassle to
>> maintain & results in a lot of boilerplate.  Instead it would be nice if the
>> GWT layer could do it automatically for me, and then RemoteServiceServlet
>> would provide it through a call like getSessionData() (templated for
>> convenience) which would de-serialize the object & return it.
>>
>> Additionally, the server side could also set the data manually with
>> setSessionData() & then the user side would never even need to know about
>> it.
>
> Take a look at http://code.google.com/p/google-web-toolkit/wiki/RpcAuth
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: testability of static methods

[Arthur Kalmenson]

I was just discussing this on the #gwt IRC channel and tieTYT gave a
good suggestion for getting around these static methods. Just create a
wrapper class which you can then mock out in a unit test. Sounds like
it should work :)

> Mind? Heck no! That would be great!

Sorry Bruce, being killed by a current project. I'll write something up soon.

--
Arthur Kalmenson



On Wed, Feb 18, 2009 at 6:34 PM, Bruce Johnson  wrote:
> Mind? Heck no! That would be great!
> On Wed, Feb 18, 2009 at 5:21 PM, Arthur Kalmenson 
> wrote:
>>
>> Hello everyone,
>>
>> I have a fairly complex class that is almost entirely non-GWT specific
>> aside from a single line that uses GWT's URL.decodeComponent method.
>> While I rediscovered GWTMockUtilities and found EasyMock Class
>> extension, I still can't think of any way to mock out the URL class.
>> This is because the object is not instantiable (it's final) and it's a
>> static method call.
>>
>> I'm not sure if there's some performance reason behind making it a
>> final class and using static methods, but it does make testing a pain.
>> It forces me to use GWTTestCase instead of TestNG to test that
>> particular class because of the single line of code.
>>
>> P.S. Does anyone mind if I write a little guide in the GWT Group about
>> using GWTMockUtilities with EasyMock?
>>
>> --
>> Arthur Kalmenson
>>
>>
>
>
> >
>

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

[gwt-contrib] Re: Date Picker, multiple selected

[Arthur Kalmenson]

Hi tfreitas,

You got the wrong group. You should try the regular GWT Group:
http://groups.google.com/group/Google-Web-Toolkit

To answer your question though, you would do date ranges using two
date pickers. One to choose the lower range, another to choose the
higher range. AFAIK there is no way to select multiple dates at once
on the date picker.

Another solution could be to catch clicks on dates and make the first
one the lower range and the next click the higher range, but this
would pose usability problems IMHO.

--
Arthur Kalmenson



On Tue, Feb 24, 2009 at 11:20 PM, tfreitas  wrote:
>
> Hi, great product, thank you very much
>
> Date Picker allows to select a date range?
> or is a new issue?
>
>
>
>
> >
>

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

[gwt-contrib] Re: Associating Data Transfer Objects (DTOs) with Suggestion Objects

[Arthur Kalmenson]

> On a side note, I found when I was writing this patch that HasValue
> extends HasValueChangeHandlers in trunk. It occurs to me that this
> relationship could possibly be backwards. I don't think that something
> with a value necessarily should be required to broadcast changes. See
> the implementation of MultiWordSuggestion for an illustration of this.
> Requiring something that HasValueChangeHandlers to have a value (that
> value which changes) makes more sense to me on the face of it.

This makes more sense to me too.

> p.s. Thank you, Gmail Labs, for reminding me that I forgot to attach the 
> patch.

Handy, ain't it? :)

--
Arthur Kalmenson



On Tue, Feb 24, 2009 at 6:42 PM, Isaac Truett  wrote:
> I basically agree with John and Ray. In general, I agree that using
> the most remote parent type possible (without introducing casts) is
> ideal. But when the subtype exists specifically as a convenience,
> using the parameterized super class instead and then complaining about
> it is... let's call it silly.
>
> To better illustrate my proposal, I have attached a quick-and-dirty
> patch against trunk r4850. In this patch Suggestion extends HasValue
> and TypedSuggestBox is a super class of SuggestBox, as I described
> above.
>
> On a side note, I found when I was writing this patch that HasValue
> extends HasValueChangeHandlers in trunk. It occurs to me that this
> relationship could possibly be backwards. I don't think that something
> with a value necessarily should be required to broadcast changes. See
> the implementation of MultiWordSuggestion for an illustration of this.
> Requiring something that HasValueChangeHandlers to have a value (that
> value which changes) makes more sense to me on the face of it.
>
> - Isaac
>
> p.s. Thank you, Gmail Labs, for reminding me that I forgot to attach the 
> patch.
>
>
> On Tue, Feb 24, 2009 at 1:03 PM, Emily Crutcher  wrote:
>> If that concern doesn't seem like it would be a problem, then I  definitely
>> agree with you that creating abstract base classes that have the
>> parametrized types seems like the best solution.
>>
>>
>> On Tue, Feb 24, 2009 at 10:54 AM, Ray Ryan  wrote:
>>>
>>> That feedback sounds a bit pedantic and impractical to me. And my job
>>> title used to be Senior Pedant.
>>>
>>> On Tue, Feb 24, 2009 at 7:44 AM, Emily Crutcher  wrote:
>>>>
>>>> It could work, though I found when I used this technique with
>>>> DatePicker (DatePicker extends AbstractDatePicker>>> CalandarView>), there was some feedback that having that abstract type 
>>>> layer
>>>> was slightly confusing because good OO practice implied that references
>>>> should then be typed as AbstractDatePicker, which then brought in the
>>>> complexity of the generic types back into the lives of the 90% who did not
>>>> care about the parameterized arguments.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Feb 24, 2009 at 10:00 AM, Ray Ryan  wrote:
>>>>>
>>>>> How about extracting a parameterized super class:
>>>>> AbstractSuggestionBox
>>>>> SuggestionBox extends AbstractSuggestionBox
>>>>> rjrjr
>>>>>
>>>>> On Mon, Feb 23, 2009 at 7:15 PM, Emily Crutcher  wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, Feb 23, 2009 at 7:04 PM, Isaac Truett 
>>>>>> wrote:
>>>>>>>
>>>>>>> The API documentation has this to say on the subject:
>>>>>>>
>>>>>>> "[...] To send back a DTO with each suggestion, extend the Suggestion
>>>>>>> interface and define a getter method that has a return value of the
>>>>>>> DTO's type. Define a class that implements this subinterface and use
>>>>>>> it to encapsulate each suggestion.
>>>>>>>
>>>>>>> To access a suggestion's DTO when the suggestion is selected, add a
>>>>>>> SuggestionHandler to the SuggestBox (see SuggestBox's documentation
>>>>>>> for more information). In the
>>>>>>> SuggestionHandler.onSuggestionSelected(SuggestionEvent event) method,
>>>>>>> obtain the selected Suggestion object from the SuggestionEvent object,
>>>>>>> and downcast the Suggestion object to the subinterface. Then, acces
>>>>>>> the DTO using the DTO getter method that was defined 

[gwt-contrib] testability of static methods

[Arthur Kalmenson]

Hello everyone,

I have a fairly complex class that is almost entirely non-GWT specific
aside from a single line that uses GWT's URL.decodeComponent method.
While I rediscovered GWTMockUtilities and found EasyMock Class
extension, I still can't think of any way to mock out the URL class.
This is because the object is not instantiable (it's final) and it's a
static method call.

I'm not sure if there's some performance reason behind making it a
final class and using static methods, but it does make testing a pain.
It forces me to use GWTTestCase instead of TestNG to test that
particular class because of the single line of code.

P.S. Does anyone mind if I write a little guide in the GWT Group about
using GWTMockUtilities with EasyMock?

--
Arthur Kalmenson

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

[gwt-contrib] Re: Doing AOP, Dojo style

[Arthur Kalmenson]

Hello Jarrod,

If you're looking for a Dependency Injection framework for the client
side, look no further then Google GIN:
http://code.google.com/p/google-gin/. It's essentially a Guice
implementation on the client side. Method interception, i.e. AOP, is
planned: http://code.google.com/p/google-gin/wiki/GuiceCompatibility.

--
Arthur Kalmenson



On Sun, Feb 8, 2009 at 1:27 PM, jarrod  wrote:
>
> I'm a huge fan of GWT, but I'm also a big fan of development
> methodologies, like Inversion of Control and Aspect-Oriented
> Programming.
>
> IoC and AOP are two concepts I've struggled to work into the GWT
> framework since day one, with AOP being a bit more difficult to
> achieve than IoC, in my opinion.
>
> I recently came across the Dojo Toolkit, which includes, among other
> things, a facility for advising your code, AOP style:
> http://svn.dojotoolkit.org/src/tags/release-1.2.3/dojox/lang/aspect.js
>
> After digging into it, it appears to take advantage of the dynamic
> nature of the JavaScript language, swapping out implementations of
> advised methods at run time with wrapper functions.
>
> All-in-all, I think this is a rather brilliant approach, and it's
> something I'd love to see supported in GWT. The only problem I see is
> how to go about crossing that dynamic bridge that, at first glance,
> appears to be the kind of thing Java and GWT might not work well
> with.
>
> Of course, deferring to native code implementation is an option, but
> that seems to defeat the purpose of the compiler's advantages. Any
> suggestions on this?
> >
>

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

[gwt-contrib] Re: default GWT version in Maven central repo wrong

[Arthur Kalmenson]

Yep, that's what I meant, so if you don't include a version and let
Maven pick up the latest version, it'll pick up 1.5-RC1. You can also
see from the size graph that 1.5-RC1 is considered newer then 1.5.3.
This might be a problem for some people.

P.S. Will 1.6-M1 hit central or will it be just the final release?

--
Arthur Kalmenson



On Fri, Feb 6, 2009 at 10:57 AM, nicolas de loof
 wrote:
> AFAIK, mvnrepository "latest" is based on textual version comparison, so
> 1.5-RC* > 1.5.3
>
> On Fri, Feb 6, 2009 at 4:54 PM, nicolas de loof 
> wrote:
>>
>> What make you say ths is the default one ?
>> Index of /maven2/com/google/gwt/gwt-user/
>> ../
>> 1.4.60/17-Sep-2007 17:57
>> -
>> 1.4.62/23-Mar-2008 09:10
>> -
>> 1.5-M1/01-Apr-2008 10:29
>> -
>> 1.5-M2/13-May-2008 13:20
>> -
>> 1.5-RC1/   29-May-2008 10:40
>> -
>> 1.5.1/ 11-Aug-2008 08:35
>> -
>> 1.5.2/ 01-Sep-2008 11:59
>> -
>> 1.5.3/ 20-Oct-2008 14:19
>>     -
>>
>> As there is no metadata.xml file, there is no default !
>>
>> PS : I'm the guy who uploads those artifacts
>> On Fri, Feb 6, 2009 at 4:40 PM, Arthur Kalmenson 
>> wrote:
>>>
>>> Hello everyone,
>>>
>>> I'm not sure who rsyncs GWT releases to Maven central, but if you look
>>> at: http://mvnrepository.com/artifact/com.google.gwt/gwt-user you can
>>> see that the default GWT version is 1.5-RC1 and not 1.5.3.
>>>
>>> --
>>> Arthur Kalmenson
>>>
>>>
>>
>
>
> >
>

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

[gwt-contrib] default GWT version in Maven central repo wrong

[Arthur Kalmenson]

Hello everyone,

I'm not sure who rsyncs GWT releases to Maven central, but if you look
at: http://mvnrepository.com/artifact/com.google.gwt/gwt-user you can
see that the default GWT version is 1.5-RC1 and not 1.5.3.

--
Arthur Kalmenson

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

[gwt-contrib] Re: Announcing GWT 1.6 Milestone 1

[Arthur Kalmenson]

Congratulations! I'll try to give this a swing this week or next week,
I hope it doesn't break the gwt-maven plugin too badly. Does anyone
know when this milestone will hit the central Maven repo?

--
Arthur Kalmenson



On Wed, Feb 4, 2009 at 7:34 PM, Scott Blum  wrote:
> Greetings GWT developers,
> The GWT team is happy to announce the availability of 1.6 Milestone 1!
> Binary distributions are available for download directly from GWT's Google
> Code project.
> http://code.google.com/p/google-web-toolkit/downloads/list?can=1&q=1.6.0
> As always, milestone builds like this are use-at-your-own-risk. There are
> known bugs, and it definitely isn't ready for production use. Please expect
> some trial and error getting everything to work. The javadoc that comes
> bundled with the distribution should be up-to-date, but the online Developer
> Guide (http://code.google.com/docreader/#p=google-web-toolkit-doc-1-6) is
> still very much a work in progress. We will be updating it over the next
> several weeks. In lieu of an up-to-date Developer Guide and release notes,
> below are the major highlights relative to GWT 1.5.3.
> *** New Project Structure in GWT 1.6 ***
> One of the biggest changes to GWT 1.6 is a new project structure. The old
> output format has been replaced by the standard Java web app expanded "war"
> format, and the actual directory name does default to "/war". Note that the
> war directory is not only for compiler output; it is also intended to
> contain handwritten static resources that you want to be included in your
> webapp alongside GWT modules (that is, things you'd want to version
> control). Please also note that the "GWTShell" and "GWTCompiler" tools will
> maintain their legacy behavior, but they have been deprecated in favor of
> new "HostedMode" and "Compiler" tools which use the new war output. When 1.6
> is officially released, we will be encouraging existing projects to update
> to the new directory format and to use the new tools to take advantage of
> new features and for compatibility with future GWT releases.
> The sample projects provided in the GWT distribution provide an example of
> correct new project configurations. For more details on the specifics of the
> new project format, please see GWT 1.6 WAR design document
> (http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6).
> A couple of important changes we should highlight here:
> - Projects with server-side code (GWT RPC) must configure a "web.xml" file
> at "/war/WEB-INF/web.xml". This web.xml file must define and publish any
> servlets associated with the web application. See the included DynaTable
> sample. Additionally, server-side library dependencies must be copied into
> "/war/WEB-INF/lib". For example, any GWT RPC servlets must have a copy of
> gwt-servlet.jar in this folder.
> - HTML host pages will no longer typically be located in a GWT module's
> public path. Instead, we'll be recommending that people take advantage of
> the natural web app behavior for serving static files by placing host pages
> anywhere in the war structure that makes sense. For exmaple, you might want
> to load a GWT module from a JSP page located in the root of your web app. To
> keep such handwritten static files separate from those produced by the GWT
> compiler, the latter will be placed into module-specific subdirectories. Any
> page that wishes to include a GWT module can do so via a script tag by
> referencing the GWT-produced ".nocache.js script" within that
> module's subdirectory. As of 1.6, we'll be recommending that only
> module-specific resources used directly by GWT code, such as image files
> needed by widgets, should remain on the public path. See the included
> Showcase sample for some examples of this distinction.
> - When you do need to load resources from a module's public path, always
> construct an absolute URL by prepending GWT.getModuleBaseURL(). For example,
> 'GWT.getModuleBaseURL() + "dir/file.ext"'. This advice has not changed, but
> in the past it was easy to be sloppy with this, because the host page and
> GWT module typically lived in the same directory, so using a relative URL
> would usually do the right thing. Now that GWT modules live in a
> subdirectory, you must reference public resources through
> GWT.getModuleBaseURL().
> *** Hosted Mode Enhancements ***
> Although the legacy GWTShell still uses an embedded Tomcat server, the new
> HostedMode runs Jetty instead. There is also a new "Restart Server" button
> on the main hosted mode window. Clicking this button restarts the internal
> Jetty server, which allows Ja

[gwt-contrib] Re: CSS for ScrollTable out of date

[Arthur Kalmenson]

Thanks John, that works :)

--
Arthur Kalmenson



On Wed, Jan 21, 2009 at 4:05 PM, John LaBanca  wrote:
> You can use the CSS from the gen2 demo:
> http://code.google.com/p/google-web-toolkit-incubator/source/browse/trunk/src/com/google/gwt/demos/scrolltable/public/ScrollTableDemo.css
>
> And the image:
> http://code.google.com/p/google-web-toolkit-incubator/source/browse/#svn/trunk/src/com/google/gwt/demos/scrolltable/public/images%3Fstate%3Dclosed
>
> Hope this helps.
>
> Thanks,
> John LaBanca
> jlaba...@google.com
>
>
> On Wed, Jan 21, 2009 at 3:02 PM, Arthur Kalmenson 
> wrote:
>>
>> Hello everyone,
>>
>> I've tried to play around with the gen2 ScrollTable and I found that
>> the CSS posted here:
>> http://code.google.com/p/google-web-toolkit-incubator/wiki/ScrollTable
>> doesn't work. thomas.husfeldt commented 7 comments from the bottom
>> with some updated CSS that sort of works (not as nice as the demo). Is
>> there any CSS available that works with the gen2 ScrollTable? Thank
>> you.
>>
>> Regards,
>> --
>> Arthur Kalmenson
>>
>>
>
>
> >
>

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

[gwt-contrib] CSS for ScrollTable out of date

[Arthur Kalmenson]

Hello everyone,

I've tried to play around with the gen2 ScrollTable and I found that
the CSS posted here:
http://code.google.com/p/google-web-toolkit-incubator/wiki/ScrollTable
doesn't work. thomas.husfeldt commented 7 comments from the bottom
with some updated CSS that sort of works (not as nice as the demo). Is
there any CSS available that works with the gen2 ScrollTable? Thank
you.

Regards,
--
Arthur Kalmenson

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

[gwt-contrib] Re: Bug? Cannot unsink ONMOUSEWHEEL event on Firefox

[Arthur Kalmenson]

Hi Yann,

You found the wrong forum (Google Group). The GWT Contributors Google
Group is specifically to discuss development in GWT, not for support
questions. You'll have better luck on the regular GWT Group:
http://groups.google.com/group/Google-Web-Toolkit

--
Arthur Kalmenson



On Tue, Jan 13, 2009 at 11:36 AM, Yann  wrote:
>
> Hi,
>
> This is my first post on the GWT forums, so I wanted to start with
> thanking Google and all of the contributors for this great tool! It's
> very impressive and very pleasant to use.
>
> To prevent usage of the mousewheel on a sub area of an application, I
> have been calling these two lines:
>
> FocusPanel focusPanel = new FocusPanel();
> focusPanel.unsinkEvents(Event.ONMOUSEWHEEL);
>
> This works pretty well in IE6 but not in Firefox. So I started nailing
> down the issue and I found what I believe is a bug in:
>
> com.google.gwt.user.client.impl.DOMImplMozilla.sinkEventsMozilla
>
> It says:
>
>   if (bits & 0x2) {
>  elem.addEventListener(.);
>}
>
> while I *presume* there should be an else clause with a remove
> counterpart.
>
> Should I raise a bug report?
>
>
> Note: a temporary workaround I found was to redefine the behavior in
> the following manner:
>
> public class MyDOMImplMozilla extends DOMImplMozillaOld
> {
>@Override
>public native void sinkEventsMozilla(Element elem, int bits) /*-{
>   if (bits & 0x2) {
>   elem.addEventListener('DOMMouseScroll',
> @com.google.gwt.user.client.impl.DOMImplStandard::dispatchEvent,
> false);
>   }
>   else {
>   elem.removeEventListener('DOMMouseScroll',
> @com.google.gwt.user.client.impl.DOMImplStandard::dispatchEvent,
> false);
>   }
>}-*/;
> }
>
> and
>
>
>
>
>
>
>
> Many thanks in advance
> Best regards
>
> >
>

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

[gwt-contrib] Re: Call for critical 1.6 bugs

[Arthur Kalmenson]

Hello Olivier,

Does this run GWTTestCases or is it possible to have it run
GWTTestSuites? Running each GWTTestCase individually is very slow.

--
Arthur Kalmenson



On Sun, Jan 11, 2009 at 10:03 AM, Olivier Modica  wrote:
>
> Ray et al.,
>
> You may be interested to know that at Lombardi we got GWTTestCases
> running through Maven/Surefire and integrated into TeamCity. We still
> had to deal with issue 
> http://code.google.com/p/google-web-toolkit/issues/detail?id=1032
> that is mentioned here but it didn't turn out to be a blocker. I
> describe our solution here: http://development.lombardi.com/?p=380.
>
> Olivier.
>
> On Jan 7, 6:11 pm, "Ray Cromwell"  wrote:
>> Well, my own wishlist includes Issue 
>> #1032,http://code.google.com/p/google-web-toolkit/issues/detail?id=1032. It
>> only effects Maven users, and is somewhat mitigated by the GWT maven
>> plugin, but it is an annoyance because GWT unit tests cannot run
>> inside of the standard maven test harness, which impacts
>> down-the-chain tools like CI servers, report generators, etc.  For
>> example, we use TeamCity as our CI build server, which keeps
>> historical timeseries for each unit test, and provides graphs, even
>> performance regression data, but because of #1032, we have to mock out
>> alot of GWT and use TestCase instead of GwtTestCase. I don't know if
>> this will be mitigated by OOPHM or Jetty inclusion.
>>
>> Java 1.6 support on OSX would be nice as well, but I assume this is
>> pending OOPHM and the jettisoning of SWT.
>>
>> -Ray
>>
>> On Wed, Jan 7, 2009 at 2:48 PM, Scott Blum  wrote:
>> > Hi all,
>> > We've narrowed down the set of bugs we'd like to fix for GWT 1.6. Our plan
>> > is for a very short release cycle this time, which forces us to fix only a
>> > small set of bugs.  Of course, we don't want to miss anything critical.
>>
>> > Here is the current set of Critical 1.6 bugs we intend to fix:
>> >http://code.google.com/p/google-web-toolkit/issues/list?can=2&q=miles...
>>
>> > If you know of some burning issue that we've missed, please use this thread
>> > to suggest bugs to add to this list, and explain why it's critically
>> > important.  The kinds of issues we consider to be critical include bugs 
>> > that
>> > affect a large number of users, possible security issues, or bugs that
>> > cannot be worked around easily (such as GWT compiler crashes).
>> > Please DO NOT use this thread to debate whether any particular issue should
>> > be in our out.  We just want to collect a list of critical issues, and we
>> > will consider each suggestion individually.
>> > Thanks!
>> > Scott
>
> >
>

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

[gwt-contrib] Re: 1.6 date picker question

[Arthur Kalmenson]

I look forward to it!

--
Arthur Kalmenson



On Thu, Jan 8, 2009 at 3:40 PM, Isaac Truett  wrote:
>
> Thank you for the reminder, Emily! I'll get you a patch as soon as I
> have a few minutes to spare.
>
>
> On Thu, Jan 8, 2009 at 2:44 PM, Emily Crutcher  wrote:
>> By the way, now that gwt-incubator is sourced against 1.6,  if you can
>> retarget your DropDownDatePicker for 1.6 and the com.google.gwt.gen2.picker
>> package I'd love to review it.
>>
>>
>>
>> On Fri, Dec 5, 2008 at 1:08 AM, Emily Crutcher  wrote:
>>>
>>> Also, the code should be reviewed before committing. I'll be happy to be
>>> your reviewer once we land the 1.6 datepicker + release the 1.5 final
>>> gwt-incubator drop. As until then, we cannot add 1.6 specific code to
>>> gwt-incubator.
>>>
>>> On Fri, Dec 5, 2008 at 1:05 AM, Emily Crutcher  wrote:
>>>>
>>>> Yep, sounds right, thanks!
>>>>
>>>> On Thu, Dec 4, 2008 at 6:53 PM, Isaac Truett  wrote:
>>>>>
>>>>> On second thought, gwt-incubator is supposed to compile against trunk,
>>>>> isn't it? Well, since this is written to compile against the
>>>>> 1_6_datepicker branch, I'll hold off committing until that branch is
>>>>> merged to trunk (soon, right...?).
>>>>>
>>>>> I've attached the DropDownDatePicker proof-of-concept patch. It's
>>>>> very, very ugly, but it works. I'll see about tending to the style a
>>>>> little bit when I have more time.
>>>>>
>>>>> Comments welcome, of course.
>>>>>
>>>>> - Isaac
>>>>>
>>>>> On Thu, Dec 4, 2008 at 10:36 AM, Emily Crutcher  wrote:
>>>>> > That sounds great, thanks.
>>>>> >
>>>>> > On Thu, Dec 4, 2008 at 10:31 AM, Isaac Truett 
>>>>> > wrote:
>>>>> >>
>>>>> >> I wrote a MonthSelector a while back that uses DropDownListBoxes for
>>>>> >> month and year. I can fix it up to be compatible with recent changes
>>>>> >> and add it to the incubator. I'll see if I can fit that in tonight.
>>>>> >>
>>>>> >>
>>>>> >> On Thu, Dec 4, 2008 at 9:39 AM, Emily Crutcher 
>>>>> >> wrote:
>>>>> >> > It is definitely something that we would consider. Of course, the
>>>>> >> > first
>>>>> >> > step
>>>>> >> > would be to get some good alternative month selectors into the
>>>>> >> > gwt-incubator...
>>>>> >> >
>>>>> >> >
>>>>> >> > On Wed, Dec 3, 2008 at 9:28 PM, Arthur Kalmenson
>>>>> >> > 
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> Hi John,
>>>>> >> >>
>>>>> >> >> Thank you for the reply. Are there any plans in the future to
>>>>> >> >> include
>>>>> >> >> various variations of the date picker for developers to choose
>>>>> >> >> from
>>>>> >> >> (which would be inline with the requests for a "richer" widget
>>>>> >> >> set)?
>>>>> >> >>
>>>>> >> >> --
>>>>> >> >> Arthur Kalmenson
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> On Mon, Dec 1, 2008 at 11:37 AM, John LaBanca
>>>>> >> >> 
>>>>> >> >> wrote:
>>>>> >> >> > [+ecc, +google-web-toolkit-contributors]
>>>>> >> >> >
>>>>> >> >> > The default DatePicker will only include next and previous
>>>>> >> >> > buttons,
>>>>> >> >> > but
>>>>> >> >> > you
>>>>> >> >> > can replace the MonthSelector with your own that does any of the
>>>>> >> >> > things
>>>>> >> >> > you
>>>>> >> >> > suggest.  We thought about using a fancy MonthSelector by
>>>>> >> >> > default,
>>>>> >> >&g

[gwt-contrib] Re: Panel loading one by one

[Arthur Kalmenson]

Ravindra, you'll have better luck asking in the GWT Group
(http://groups.google.com/group/Google-Web-Toolkit). This group is
specifically for discussion regarding the development of GWT, not for
general questions.

--
Arthur Kalmenson



On Wed, Jan 7, 2009 at 8:03 AM, kundlaravin...@gmail.com
 wrote:
>
> Hi All,
>
>How to display panel one by one.I am using borderLayout panel with
> NORTH(Header),WEST(Left),CENTER. First i have to display header then
> leftside treePanel and center panel.
> Please help me on this regard.
>
>
> Thanks&Regards,
> Ravindra
>
>
> >
>

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

[gwt-contrib] Re: Any objections to 1.5-final gwt-incubator drop going out this week?

[Arthur Kalmenson]

Sounds good to me.

--
Arthur Kalmenson



On Wed, Dec 17, 2008 at 10:25 AM, Emily Crutcher  wrote:
> For gwt-incubator users who are using svn tip from gwt-1.6 or gwt-trunk, we
> currently are in a confusing situation of having two different, almost
> identical event systems:  one in gwt-incubator itself and one in gwt. In
> many cases, both are currently in use. Additionally,  we have tons of
> deprecation warnings, because gwt-incubator widgets cannot switch to the
> "real" event handlers so are stuck using listeners.
>
> To fix this situation, we need to post a gwt-incubator 1.5 final relatively
> soon. Until the next gwt-incubator jar drop, the gwt-incubator tip  would
> then only be certified to work with gwt-trunk svn tip. After the first gwt
> 1.6 milestone or release candidate, gwt-incubator  would be certified to
> work against that 1.6 jar and gwt-trunk.
>
> Objections anyone?
>
>
> --
> "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: RR: HasValue is not ready for primetime

[Arthur Kalmenson]

We're currently using the MVC approach with our project and it seems
to be working out pretty well. We follow the same approach that Ray
Cromwell mentioned with the USPostalAddress example and we use the
HasValue interface to implement it. It seems to work pretty well at
the moment. Having most of the Widgets implement HasValue would
really help us clean up the code.

Perhaps CheckBox should implement HasValue using some "complex"
object that combines the Boolean and String value that the CheckBox
contains for its type?

--
Arthur Kalmenson



On Thu, Dec 11, 2008 at 6:24 PM, Ray Ryan  wrote:
> Well put, RayC, thanks. MVC is exactly the intended point of HasValue.
> (Freeland, John, it's HasValue, that's not being debated, fret ye not.)
> And you guys are right, I think, that we're wrong to paralyze ourselves with
> fears of future confusion with our still-vague-but-crystallizing-nicely
> notions of a data binding framework.
> The specific issue that got me to lob this grenade was a disgusted internal
> complaint by someone who has long been frustrated by our CheckBox's lack of
> access to the dom value field. When he saw the longed for method appear and
> do exactly the wrong thing, and in a manner redundant with isChecked...
> I like HasValue, but its application to CheckBox has produced very confusing
> little beastie. So, how about we narrow the scope of this conversation to
> CheckBox api repair. How about this:
>
> Deprecate CheckBox#isChecked and CheckBox#setChecked
> Introduce CheckBox#setFormValue
> Add copious javadoc to compare and contrast the two set...Value methods
>
> If this flies, are there other widgets that need the setFormValue method?
> rjrjr
> On Fri, Dec 12, 2008 at 7:42 AM, Ray Cromwell  wrote:
>>
>> IMHO, the concept of a Widget having a value is that it has only one
>> value. The "value" can certainly be an object with multiple fields, or
>> with conversion helper functions (String->Boolean), but it's one value
>> with a normalized internal representation.
>>
>> For example, consider an USPostalAddressWidget, which
>> HasValue. This widget is quite complex, with probably
>> ample internal textboxes for each field (street, city, state, zip,
>> suite, etc) and also validation. However, the widget conceptually has
>> a single value: a USPostalAddress that can be get and set.
>>
>> In this context, I think it is clear that HasValue is really a
>> Model-View interface. If it were a Table, it would be
>> HasValue or HasValue, for example. Probably the
>> primary difference is HasValue doesn't require models to provide
>> change listener interfaces.
>>
>> I don't believe that Data Binding and Model/View architectures are
>> mutually exclusive. The main difference is, with MVC, typically, you
>> build model POJOs, and build the View to be tightly coupled to the
>> model interface, so that there is usually (but not always) a one to
>> one correspondence between View and Model types.  With Data Binding
>> frameworks, the coupling is looser and you can have a many-to-one
>> relationship, e.g bind POJO.fooField to Widget A and bind
>> POJO.barField to WidgetB, or further, you can bind into composite
>> widgets exposing their innards. Data Binding allows for more reuse
>> since you can repurpose pojo models by slicing and dicing them with
>> binding expressions, on the other hand, lots of bindings can get messy
>> and make it harder to track what widgets deal with what data,
>> especially if the bindings are dynamic or in a DSL.
>>
>> -Ray
>>
>>
>> On Thu, Dec 11, 2008 at 11:49 AM, Isaac Truett  wrote:
>> >
>> > At the risk of seeming to hand-wave that problem away, I would say
>> > that any Widget seeking to implement HasValue twice is not a candidate
>> > for HasValue at all. HasValue is, by definition, for Widgets with a
>> > single distinct value. The value of a CheckBox is either a String or a
>> > Boolean (we've seen arguments either way) or it simply isn't a
>> > HasValue because it's a complex Widget with two equally important and
>> > independent values.
>> >
>> >
>> > On Thu, Dec 11, 2008 at 2:41 PM, John Tamplin  wrote:
>> >> On Thu, Dec 11, 2008 at 2:20 PM, Freeland Abbott
>> >>  wrote:
>> >>>
>> >>> To be fair, my friend was extending TextBox---which came to implement
>> >>> HasValue, and thus acquired the colliding String getValue()---when he
>> >>> should
>> >>> have extended Composite (which doesn't) instead; that was my sugges

[gwt-contrib] Re: 1.6 date picker question

[Arthur Kalmenson]

That would be awesome. We've been meaning to implement it ourselves
for some time but haven't had the chance. I'll be very interested in
using it. Thanks!

--
Arthur Kalmenson



On Thu, Dec 4, 2008 at 10:31 AM, Isaac Truett <[EMAIL PROTECTED]> wrote:
>
> I wrote a MonthSelector a while back that uses DropDownListBoxes for
> month and year. I can fix it up to be compatible with recent changes
> and add it to the incubator. I'll see if I can fit that in tonight.
>
>
> On Thu, Dec 4, 2008 at 9:39 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>> It is definitely something that we would consider. Of course, the first step
>> would be to get some good alternative month selectors into the
>> gwt-incubator...
>>
>>
>> On Wed, Dec 3, 2008 at 9:28 PM, Arthur Kalmenson <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Hi John,
>>>
>>> Thank you for the reply. Are there any plans in the future to include
>>> various variations of the date picker for developers to choose from
>>> (which would be inline with the requests for a "richer" widget set)?
>>>
>>> --
>>> Arthur Kalmenson
>>>
>>>
>>>
>>> On Mon, Dec 1, 2008 at 11:37 AM, John LaBanca <[EMAIL PROTECTED]> wrote:
>>> > [+ecc, +google-web-toolkit-contributors]
>>> >
>>> > The default DatePicker will only include next and previous buttons, but
>>> > you
>>> > can replace the MonthSelector with your own that does any of the things
>>> > you
>>> > suggest.  We thought about using a fancy MonthSelector by default, but
>>> > we
>>> > figured everyone would have a different opinion on the ideal version, so
>>> > we
>>> > instead designed it so you can replace it.
>>> >
>>> > Thanks,
>>> > John LaBanca
>>> > [EMAIL PROTECTED]
>>> >
>>> >
>>> > On Mon, Dec 1, 2008 at 9:41 AM, Arthur Kalmenson <[EMAIL PROTECTED]>
>>> > wrote:
>>> >>
>>> >> Hello John,
>>> >>
>>> >> Will the 1.6 date picker include a year spinner? I know the current
>>> >> incubator version does not have a year spinner, so this makes it
>>> >> pretty difficult to use the date picker if you have a date that's more
>>> >> then a year off. Another nice feature would be to be able to select
>>> >> the date. For example you could click on the year the date picker
>>> >> shows, and that would turn it into a text box where you can enter the
>>> >> year you'd like.
>>> >>
>>> >> Best regards,
>>> >> --
>>> >> Arthur Kalmenson
>>> >
>>> >
>>
>>
>>
>> --
>> "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: 1.6 date picker question

[Arthur Kalmenson]

Hi John,

Thank you for the reply. Are there any plans in the future to include
various variations of the date picker for developers to choose from
(which would be inline with the requests for a "richer" widget set)?

--
Arthur Kalmenson



On Mon, Dec 1, 2008 at 11:37 AM, John LaBanca <[EMAIL PROTECTED]> wrote:
> [+ecc, +google-web-toolkit-contributors]
>
> The default DatePicker will only include next and previous buttons, but you
> can replace the MonthSelector with your own that does any of the things you
> suggest.  We thought about using a fancy MonthSelector by default, but we
> figured everyone would have a different opinion on the ideal version, so we
> instead designed it so you can replace it.
>
> Thanks,
> John LaBanca
> [EMAIL PROTECTED]
>
>
> On Mon, Dec 1, 2008 at 9:41 AM, Arthur Kalmenson <[EMAIL PROTECTED]>
> wrote:
>>
>> Hello John,
>>
>> Will the 1.6 date picker include a year spinner? I know the current
>> incubator version does not have a year spinner, so this makes it
>> pretty difficult to use the date picker if you have a date that's more
>> then a year off. Another nice feature would be to be able to select
>> the date. For example you could click on the year the date picker
>> shows, and that would turn it into a text box where you can enter the
>> year you'd like.
>>
>> Best regards,
>> --
>> Arthur Kalmenson
>
>

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

[gwt-contrib] Re: please solve this prob ..

[Arthur Kalmenson]

The error message seems pretty explanatory, and it's kind of hard to
understand what the problem is without a code snippet. You'd be better
off asking your question on the regular mailing list:
http://groups.google.com/group/Google-Web-Toolkit as this one is
specific to contributors and not general questions.

--
Arthur Kalmenson



On Tue, Nov 25, 2008 at 8:43 AM, Bhupen <[EMAIL PROTECTED]> wrote:
>
> [ERROR] Uncaught exception escaped
> java.lang.AssertionError: A widget in the detach list was found not
> attached to the document. The is likely caused by wrapping an existing
> element and removing it from the document without calling
> RootPanel.detachNow().
>at com.google.gwt.user.client.ui.RootPanel.detachWidgets
> (RootPanel.java:200)
>at com.google.gwt.user.client.ui.RootPanel$1.onWindowClosed
> (RootPanel.java:221)
>at com.google.gwt.user.client.Window.fireClosedImpl(Window.java:465)
>at com.google.gwt.user.client.Window.fireClosedAndCatch(Window.java:
> 456)
>at com.google.gwt.user.client.Window.onClosed(Window.java:430)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>at java.lang.reflect.Method.invoke(Unknown Source)
>at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:
> 103)
>at com.google.gwt.dev.shell.ie.IDispatchImpl.callMethod
> (IDispatchImpl.java:126)
>at com.google.gwt.dev.shell.ie.IDispatchProxy.invoke
> (IDispatchProxy.java:155)
>at com.google.gwt.dev.shell.ie.IDispatchImpl.Invoke
> (IDispatchImpl.java:294)
>at com.google.gwt.dev.shell.ie.IDispatchImpl.method6
> (IDispatchImpl.java:194)
>at org.eclipse.swt.internal.ole.win32.COMObject.callback6
> (COMObject.java:117)
>at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
>at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1925)
>at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2966)
>at com.google.gwt.dev.GWTShell.pumpEventLoop(GWTShell.java:720)
>at com.google.gwt.dev.GWTShell.run(GWTShell.java:593)
>at com.google.gwt.dev.GWTShell.main(GWTShell.java:357)
>
> >
>

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

[gwt-contrib] Re: RR: Adding .project to gwt-incubator root directory

[Arthur Kalmenson]

We check the .project file in for all of our projects, this makes
picking it up from the repo really easy.

--
Arthur Kalmenson



On Mon, Nov 24, 2008 at 11:31 AM, Lex Spoon <[EMAIL PROTECTED]> wrote:
>
> On Mon, Nov 17, 2008 at 4:28 PM, BobV <[EMAIL PROTECTED]> wrote:
>>
>>> What exactly is the reason we can't do the same here?
>>
>> subclipse won't handle linked resources.
>
> Seconded.  Saying that the trunk arrangement "works" is a mild overstatement.
>
> That said, I don't know if there is some way to make an eclipse
> subdirectory work or not.  It might be possible if the linked
> resources can be avoided.  Still, checking in the .project file works
> fine as far as I know.  I've worked on projects that did so before.
>
>
>  -Lex
>
> >
>

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

[gwt-contrib] Re: [ANN] GWT maven plugin released

[Arthur Kalmenson]

Well it looks like the two plugins are merging, I'm very happy to hear
that! I look forward to the merging of the features of both of these
plugins.

--
Arthur Kalmenson



On Mon, Nov 24, 2008 at 4:00 AM, nicolas.deloof
<[EMAIL PROTECTED]> wrote:
>
> I have lots of respect for Charlie's work on its plugin
>
> I don't miss an archetype for GWT (you only need one plugin config to
> get GWT working !), and  only use GWTTests for integration testing
> purpose (unit tests are far more quicker). I can't see why the mojo
> plugin couldn't run GwtTestSuite - but never tested.
> That beeing said, this is just MY way to use gwt and maven together.
> For example, googlecode gwt-maven has no support to create eclipse
> launch configuration, but runs hosted mode from maven with remote
> debugging. It also has (AFAIK) no support to generate Async interfaces
> for RPC services.
>
> Yu can also find many other gwt/maven plugins created for custom use
> cases (nl.jteam:maven-gwt-plugin, some others attached as contribution
> in Mojo Jira ...). This is not a good think if they overlap, but today
> mojo vs googlecode gwt-maven-plugin is just about how you like to use
> gwt with maven. The "run the compiler" part is the only common
> element.
>
> Maybe some official gwt hosted plugin could support the basic tools
> (compiler, i18n) as a maven plugin, and others could then contribute
> with other features. As a side effect, a gwt native support for maven
> could benefict for better integration with GWTCompiler class, that has
> changed many time and required us (maven plugin developpers) to fork a
> JVM or other hack.
>
> Nicolas
>
> On 24 nov, 04:03, "Arthur Kalmenson" <[EMAIL PROTECTED]> wrote:
>> I have to agree with Ray, Charlie Collins has done a fantastic job on
>> the gwt-maven plugin and has some very important features that seem to
>> be missing from this plugin (an archetype, running GWTTestCases from
>> the GWTTestSuite, etc). I too would like to see these two plugins
>> merged together.
>>
>> --
>> Arthur Kalmenson
>>
>> On Sun, Nov 23, 2008 at 3:20 AM, nicolas.deloof
>>
>> <[EMAIL PROTECTED]> wrote:
>>
>> > I understand your point of view,
>>
>> > I just want to notice Mojo project has been created to avoid such case
>> > of multiple plugins for same use-cases / technology.
>>
>> > Anyone can get write acces to Mojo when donating a plugin, and this is
>> > the primary place where maven user will search for maven a maven
>> > plugin to support XX technology. It doesn't use the constraining
>> > Apache fundation release and licensing rules, so Mojo committer are
>> > free to create and promote nice plugins.
>>
>> > I was not aware of googlecode gwt-maven plugin when I searched one,
>> > and found the one in Mojo sandbox that required some improvements. I
>> > later was pointed to google code, but hopefully I didn't plan same
>> > features.
>>
>> > Same issue may occur with android or any other technology. I myself
>> > planned to study android and to support it as part of Mojo, but your
>> > comment let me thing there is allready plugins available *somewhere*
>> > for that ;) It would be better for such project to support own
>> > plugins, to avoid such ambiguous brother plugins.
>> > We (Mojo project) could also add links to such 3rd party plugins.
>>
>> > Cheers,
>> > Nicolas
>>
>> > On 23 nov, 08:25, "Ray Cromwell" <[EMAIL PROTECTED]> wrote:
>> >> Nicolas,
>> >>   I hope you didn't take my comment the wrong way. I just wanted to
>> >> point out that Charlie Collin's plugin has been out a lot longer and
>> >> has many more people using it. It's great that the Mojo version has
>> >> finally been brought up to a similar state, I just lament the fact
>> >> that there are so few people maintaining gwt maven plugins that it
>> >> might serve better to have a unified project. Charlie Collins recently
>> >> did this with his Android Maven pluging, merging it with the Masa
>> >> plugin which had a different featureset.
>>
>> >>   I am not involved in either project, I'm just a heavy user of
>> >> gwt-maven plugin from Charlie's project, and long term, I'd like to
>> >> see a sort of defacto standard GWT maven plugin, defacto standard GWT
>> >> repo, etc. Right now, everyone and their brother is putting GWT
>> >> packages into repos, using various

[gwt-contrib] Re: [ANN] GWT maven plugin released

[Arthur Kalmenson]

I have to agree with Ray, Charlie Collins has done a fantastic job on
the gwt-maven plugin and has some very important features that seem to
be missing from this plugin (an archetype, running GWTTestCases from
the GWTTestSuite, etc). I too would like to see these two plugins
merged together.

--
Arthur Kalmenson



On Sun, Nov 23, 2008 at 3:20 AM, nicolas.deloof
<[EMAIL PROTECTED]> wrote:
>
> I understand your point of view,
>
> I just want to notice Mojo project has been created to avoid such case
> of multiple plugins for same use-cases / technology.
>
> Anyone can get write acces to Mojo when donating a plugin, and this is
> the primary place where maven user will search for maven a maven
> plugin to support XX technology. It doesn't use the constraining
> Apache fundation release and licensing rules, so Mojo committer are
> free to create and promote nice plugins.
>
> I was not aware of googlecode gwt-maven plugin when I searched one,
> and found the one in Mojo sandbox that required some improvements. I
> later was pointed to google code, but hopefully I didn't plan same
> features.
>
> Same issue may occur with android or any other technology. I myself
> planned to study android and to support it as part of Mojo, but your
> comment let me thing there is allready plugins available *somewhere*
> for that ;) It would be better for such project to support own
> plugins, to avoid such ambiguous brother plugins.
> We (Mojo project) could also add links to such 3rd party plugins.
>
> Cheers,
> Nicolas
>
> On 23 nov, 08:25, "Ray Cromwell" <[EMAIL PROTECTED]> wrote:
>> Nicolas,
>>   I hope you didn't take my comment the wrong way. I just wanted to
>> point out that Charlie Collin's plugin has been out a lot longer and
>> has many more people using it. It's great that the Mojo version has
>> finally been brought up to a similar state, I just lament the fact
>> that there are so few people maintaining gwt maven plugins that it
>> might serve better to have a unified project. Charlie Collins recently
>> did this with his Android Maven pluging, merging it with the Masa
>> plugin which had a different featureset.
>>
>>   I am not involved in either project, I'm just a heavy user of
>> gwt-maven plugin from Charlie's project, and long term, I'd like to
>> see a sort of defacto standard GWT maven plugin, defacto standard GWT
>> repo, etc. Right now, everyone and their brother is putting GWT
>> packages into repos, using various packaging schemes.
>>
>> -Ray
>>
>> On Sat, Nov 22, 2008 at 11:18 PM, nicolas.deloof
>>
>> <[EMAIL PROTECTED]> wrote:
>>
>> > Mojo.codehaus.org is the place where maven community starts plugins
>> > ideas or incubates third-party ones. They can get focus from many
>> > developpers and improve, until they get new releases.
>>
>> > The gwt-maven mojo has been created as an experiment but failed due to
>> > GwtCompiler System.exit(). I then came to fix this and add support for
>> > "no installation" libs.zip, and other stuff like Asyn code generation.
>>
>> > Charlie Collins as any other contributor is welcome to join the large
>> > Mojo community and donate code / help to improve the plugin with any
>> > new feature.
>>
>> > I google guys want to maintain themselve a gwt plugin, they could
>> > either join Mojo, or Mojo could donate the plugin to GWT.
>>
>> > Nicolas
>>
>> > On 22 nov, 21:08, Ray Cromwell <[EMAIL PROTECTED]> wrote:
>> >> I'd like to see this plugin and the one from Charlie Collins (total)
>> >> unified, cause it seems like each have valuable nonoverlapping
>> >> features and a real stable feature rich production quality plugin
>> >> should be blessed by google in much the same way as ide plugins and
>> >> ant tasks.
>>
>> >> Even though the gwt team doesn't use maven, a sizable market of people
>> >> do and all major ides now integrate tightly with it.
>>
>> >> Just my two cents.
>>
>> >> On Nov 22, 2008, at 9:43 AM, "nicolas.deloof"
>>
>> >> <[EMAIL PROTECTED]> wrote:
>>
>> >> > The Mojo team is pleased to announce the release of the GWT Maven
>> >> > Plugin version 1.0.
>>
>> >> >http://mojo.codehaus.org/gwt-maven-plugin/
>>
>> >> > This is the first stable release after some month of real-life tests
>> >> > in sandbox.
>>
>> >> > To get this update, simply specify the version in your project's
>> >> > plugin configuration:
>>
>> >> > 
>> >> >  org.codehaus.mojo
>> >> >  gwt-maven-plugin
>> >> >  1.0
>> >> > 
>>
>> >> > Regards,
>>
>> >> > Nicolas De loof
> >
>

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

[gwt-contrib] Re: auto-deploy GWT on maven repo ?

[Arthur Kalmenson]

I'm going to second that request. We use Hudson and we get no
reporting on GWTTestCases that are being run by Maven. Would be nice
to get those reports.

--
Arthur Kalmenson



On Thu, Nov 20, 2008 at 5:19 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
>
> BTW, while we're discussing maven, fixing the long standing hosted
> mode classloader issue (Issue #1032) that blocks the maven JUnit test
> runner from working would be nice. :) The gwt-maven plugin works
> around this with a custom test runner, but it exists outside of
> maven's reporting and error handling infrastructure, meaning that
> other Maven enabled products like JetBrain's TeamCity continuous
> integration server, or some IDEs, won't deal coherently with the
> outputs of the tests.
>
> -Ray
>
>
> On Thu, Nov 20, 2008 at 2:15 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
>> If this is done, please make sure that the conventions adhere to the
>> gwt-maven plugin's repo layout. This allows you to use the
>> maven-dependency plugin to download the platform specific JNI
>> libraries separately and unpack them, so that one doesn't have to
>> "install" the GWT distribution and set up a GWT_HOME environment
>> variable.
>>
>> I use this in my build process which allows Chronoscope to build clean
>> on an empty computer with only Java and Maven installed and no other
>> prerequisites or reliance on absolute file system paths. This allows
>> us to startup a VMWare instant with an OS of our choice, and have it
>> build and test out of the box with virtually no configuration needed.
>>
>> -Ray
>>
>> On Thu, Nov 20, 2008 at 2:09 PM, nicolas.deloof
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> I was considering only releases, as google-maven-repository has a
>>> rsync to publish on maven central
>>> But maybe you'd like to have a custom snapshot / milestones repository
>>> (the way Springframework does for example).
>>>
>>> Nicolas
>>>
>>> On 20 nov, 21:59, Scott Blum <[EMAIL PROTECTED]> wrote:
>>>> Do you mean for things like nightlies, or just full releases?
>>>>
>>>> On Wed, Nov 19, 2008 at 11:12 AM, nicolas.deloof
>>>> <[EMAIL PROTECTED]>wrote:
>>>>
>>>>
>>>>
>>>> > Hi,
>>>>
>>>> > As a maven developper, I have contributed the central repository with
>>>> > gwt artifacts. I now GWT team doesn't want to use maven as build
>>>> > system, and I'm fine with this. I'm not here to try changing your
>>>> > choice.
>>>>
>>>> > I just would like the build script to support deploying the GWT
>>>> > artifacts to a maven repo (there is one dedicated to google projects
>>>> > athttp://code.google.com/p/google-maven-repository/). I did this
>>>> > manually myself for 1.5.x versions, but a more automated deployment
>>>> > would be nice.
>>>>
>>>> > What's your opinion ?
>>> >>
>>>
>>
>
> >
>

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

[gwt-contrib] Re: RR: Adding .project to gwt-incubator root directory

[Arthur Kalmenson]

This would make jumping into the incubator much easier.

Regards,
--
Arthur Kalmenson



On Mon, Nov 17, 2008 at 3:18 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> Several months ago we had the discussion of whether it was worth polluting
> the root directory of gwt-incubator with eclipse specific project files in
> order to make sub-eclipse and/or other subversion plugins to work correctly
> with the gwt-incubator source.
>
> At the time, there was a lot of discussion about that potential change, so
> we pended the issue and I  tried running with an  experimental eclipse
> config for a while.
>
> My conclusion after running with the alternative eclipse config, is that
> subversion is an extremely useful tool when doing the creation/refactoring
> work that is common when growing new libraries.
>
> Therefore, would any of you (particularly the non-eclipse users) object to
> having a checked in .project, .classpath, and .checkstyle files in the root
> directory of the gwt-incubator project?
>
>  Thanks,
>
>  Emily
>
>
>
>
>
> --
> "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

[Arthur Kalmenson]

Hello Rahul,

Here's some of the projects:

gwt-data-binding: http://code.google.com/p/gwt-data-binding/
gwt-validation: http://code.google.com/p/gwt-validation/

I'm working on visibility logic as we speak, I'll make a post when I
get the chance.

I am also wondering what the status of the GWT teams solution is.

Regards,
--
Arthur Kalmenson



On Thu, Nov 13, 2008 at 8:41 PM, rahul <[EMAIL PROTECTED]> wrote:
>
> Hello Emily,
>
>>
>> *Metadata Systems, comprising Models and Controllers*
>> xforms, Ian's databinding system, Arthur's validation system, gwt team's
>> upcoming proposal for data management:
>
> Do you have links to the above resources please, where we could find
> more details/sources?
>
> Also, you mentioned GWT team's upcoming proposal for data management -
> is it available online yet?
>
> Thanks,
>
> Rahul
>
> >
>

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

[gwt-contrib] Re: data binding framework for GWT

[Arthur Kalmenson]

> Do you know what svnsync does?  The svnsync help says that the
> destination repository should be a "read-only mirror" of the source,
> but I'd like to switch to the public repository for future
> development.  Can I svnsync and then start using it as a read-write
> repo?  Does svnsync copy all the history, or just the current version?
>  Does it track file moves like standard svn?

If your data bindings stuff was always in a specific folder of the
larger project, you should be able to svnsync that part of the project
into Google Code. Check out the "How do I import an existing
Subversion repository?" section here:
http://code.google.com/p/support/wiki/FAQ. It does track all svn
activity from that sub directory.

You might have to ask to have your svn repo reset to 0 so you can sync
it. Check out the Group here:
http://groups.google.com/group/google-code-hosting

--
Arthur Kalmenson



On Wed, Oct 22, 2008 at 11:49 AM, Ian Petersen <[EMAIL PROTECTED]> wrote:
>
> On Wed, Oct 22, 2008 at 11:41 AM, Arthur Kalmenson
> <[EMAIL PROTECTED]> wrote:
>>
>>> Great, I've added a ticket already. The code would be helpful though
>>> :P. We'd like to start sending in patches when we find some things to
>>> change.
>>
>> OK, the code is there now, but what do you use to build your projects
>> usually? Do you use Maven or Ant? Personally, I prefer Maven
>
> It's not really there yet.  I'd like to mirror the changes I went
> through in my private repository so other people can glean whatever
> they can from the revision history so what's there now is the very
> first version of my work.
>
> Do you know what svnsync does?  The svnsync help says that the
> destination repository should be a "read-only mirror" of the source,
> but I'd like to switch to the public repository for future
> development.  Can I svnsync and then start using it as a read-write
> repo?  Does svnsync copy all the history, or just the current version?
>  Does it track file moves like standard svn?
>
> As for build tools, I'm using Ant myself.  Right now, my private copy
> of the data binding library is one piece of a big project so the build
> script is external to the data binding piece.  I intend to get my
> revision history uploaded, then add a data binding-specific build
> scrip to the public repo.
>
> Ian
>
> >
>

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

[gwt-contrib] Re: data binding framework for GWT

[Arthur Kalmenson]

> Great, I've added a ticket already. The code would be helpful though
> :P. We'd like to start sending in patches when we find some things to
> change.

OK, the code is there now, but what do you use to build your projects
usually? Do you use Maven or Ant? Personally, I prefer Maven

--
Arthur Kalmenson



On Wed, Oct 22, 2008 at 9:48 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
>> I don't expect to require HasData, I just expect to have some kind of
>> generic implementation for both Editor and Viewer that wrap a HasData
>> instance so that, given a HasData instance, you don't have to do any
>> work to integrate with the data binding library.
>
> Ah, thanks for clearing that up.
>
>> Done.  http://code.google.com/p/gwt-data-binding/  There's nothing
>> there yet, but I'll look into fixing that ASAP.
>
> Great, I've added a ticket already. The code would be helpful though
> :P. We'd like to start sending in patches when we find some things to
> change.
>
>> Indeed, but I'll be a Seattlite in three weeks for a new job.  Given
>> that, the next three weeks are going to be _very_ busy for me so I'm
>> not sure how much progress I'll be able to make in any given
>> direction.
>
> Oh, working for the enemy :P? Well good luck with your move, hope all goes 
> well.
>
> --
> Arthur Kalmenson
>
>
>
> On Tue, Oct 21, 2008 at 10:41 AM, Ian Petersen <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Oct 21, 2008 at 9:07 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
>>> I think requiring the HasData interface isn't a bad thing, but this
>>> might frustrate developers in the short term as standard GWT widgets
>>> don't implement the HasData interface.
>>
>> I don't expect to require HasData, I just expect to have some kind of
>> generic implementation for both Editor and Viewer that wrap a HasData
>> instance so that, given a HasData instance, you don't have to do any
>> work to integrate with the data binding library.
>>
>>> Overall it looks good. I like the new API idea.
>>
>> I think that settles it--I like it, too, and I guess your +1 makes me
>> not insane.
>>
>>> P.S. Are you going to create a new Google Code project? It'd be easier
>>> to track issues and contribute code. Thanks!
>>
>> Done.  http://code.google.com/p/gwt-data-binding/  There's nothing
>> there yet, but I'll look into fixing that ASAP.
>>
>>> P.P.S. Nice to have a fellow Torontonian here :)
>>
>> Indeed, but I'll be a Seattlite in three weeks for a new job.  Given
>> that, the next three weeks are going to be _very_ busy for me so I'm
>> not sure how much progress I'll be able to make in any given
>> direction.
>>
>> Ian
>>
>> >>
>>
>

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

[gwt-contrib] Re: data binding framework for GWT

[Arthur Kalmenson]

> I don't expect to require HasData, I just expect to have some kind of
> generic implementation for both Editor and Viewer that wrap a HasData
> instance so that, given a HasData instance, you don't have to do any
> work to integrate with the data binding library.

Ah, thanks for clearing that up.

> Done.  http://code.google.com/p/gwt-data-binding/  There's nothing
> there yet, but I'll look into fixing that ASAP.

Great, I've added a ticket already. The code would be helpful though
:P. We'd like to start sending in patches when we find some things to
change.

> Indeed, but I'll be a Seattlite in three weeks for a new job.  Given
> that, the next three weeks are going to be _very_ busy for me so I'm
> not sure how much progress I'll be able to make in any given
> direction.

Oh, working for the enemy :P? Well good luck with your move, hope all goes well.

--
Arthur Kalmenson



On Tue, Oct 21, 2008 at 10:41 AM, Ian Petersen <[EMAIL PROTECTED]> wrote:
>
> On Tue, Oct 21, 2008 at 9:07 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
>> I think requiring the HasData interface isn't a bad thing, but this
>> might frustrate developers in the short term as standard GWT widgets
>> don't implement the HasData interface.
>
> I don't expect to require HasData, I just expect to have some kind of
> generic implementation for both Editor and Viewer that wrap a HasData
> instance so that, given a HasData instance, you don't have to do any
> work to integrate with the data binding library.
>
>> Overall it looks good. I like the new API idea.
>
> I think that settles it--I like it, too, and I guess your +1 makes me
> not insane.
>
>> P.S. Are you going to create a new Google Code project? It'd be easier
>> to track issues and contribute code. Thanks!
>
> Done.  http://code.google.com/p/gwt-data-binding/  There's nothing
> there yet, but I'll look into fixing that ASAP.
>
>> P.P.S. Nice to have a fellow Torontonian here :)
>
> Indeed, but I'll be a Seattlite in three weeks for a new job.  Given
> that, the next three weeks are going to be _very_ busy for me so I'm
> not sure how much progress I'll be able to make in any given
> direction.
>
> Ian
>
> >
>

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

[gwt-contrib] Re: data binding framework for GWT

[Arthur Kalmenson]

Hello Ian,

> Given HasData, it might be possible to write some really generic
> implementations of Editor and Viewer that wrap an instance of HasData
> to make it easier for developers to come up with an instance of Editor
> to bind to, but I'm a little squirrelly about binding to arbitrary
> widgets.

I think requiring the HasData interface isn't a bad thing, but this
might frustrate developers in the short term as standard GWT widgets
don't implement the HasData interface.

> Thoughts?

Overall it looks good. I like the new API idea.

P.S. Are you going to create a new Google Code project? It'd be easier
to track issues and contribute code. Thanks!

P.P.S. Nice to have a fellow Torontonian here :)

Regards,
--
Arthur Kalmenson


On Wed, Oct 15, 2008 at 5:16 PM, Ian Petersen <[EMAIL PROTECTED]> wrote:
>
> Hi Ray,
>
> On Wed, Oct 8, 2008 at 6:24 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
> >  Something struck me about the way you are approaching things, that
> > is, letting the BoundField's return widgets. With the new HasData
> > stuff being proposed, why not let the programmer create the widget,
> > and bind the field to an already created widget? (if the widgets
> > export an interface like HasData which permits wiring them up.) That
> > seems to provide more flexibility, since people tend to design the
> > look and layout of the widgets and wire up the logic separately.
> >
> > Couldn't the API look more like this?
> >
> > PersonForm form = GWT.create(PersonForm.class);
> >
> > form.getFirstName().bind(existingWidget, personInstance);
> > form.getLastName().bind(anotherExistingWidget, personInstance);
> >
> > or perhaps
> >
> > form.bindInstance(personInstance).
> >  getFirstName().bind(widget1).
> >  getLastName().bind(widget2);
> >
> > I realize there may be issues making this work with arbitrary
> > subclasses of Widget, but let's leave that aside for a moment and
> > assume the proper support can be added to the widgets.  This would
> > also seem to work alot better with the proposed UI Templating system
> > being proposed.
>
> Sorry for the long delay--it's taking a while to come back to the real
> world after a weekend that included about 45 hours in a car and a fair
> amount of turkey.
>
> Anyway, I've thought some more about your suggestion here (that
> widgets be passed into the binding framework, rather than defining
> them on the form), and I think I agree with you.  Given that the same
> value could be displayed/edited in more than one kind of widget, the
> choice of _which_ widget seems like a presentation issue while the
> business logic in the binding itself seems like a model issue.  I
> think that's enough argument for me that you're right.  (As a bonus,
> your suggestion also cleans up the smell of defining constructor
> arguments in string form on the @UseEditor and @UseViewer
> annotations.)
>
> I do disagree with the particular APIs you suggested, though.  To me,
> a Form is to a class as a BoundForm is to an instance.  I think it
> should be possible to use the same form in multiple places at once,
> and each "place" should be relatively independent, sharing only
> definitions and not "instances".  I'd therefore suggest something like
> the following:
>
> BeanForm form = GWT.create(BeanForm.class);
>
> BoundForm boundForm = form.bindTo(beanInstance);
>
> panel.add(boundForm.bind(form.getFieldOne(), new
> TextBoxEditor(CurrencyConverter.INSTANCE));
> panel.add(boundForm.bind(form.getFieldTwo(), new
> LabelViewer(DefaultToString.INSTANCE));
> panel.add(boundForm.bind(form.getFieldThree(), new CreditCardEditor());
>
> The above code could be shortened if you assume it was in the context
> of a DataComposite instead of in some random UI code:
>
> public class BeanComposite extends DataComposite {
>
>  private static final BeanForm form = GWT.create(BeanForm.class);
>
>  // in retrospect, I really like this code--there's hardly any
>  // generic type cheese in the _use_ of the binding library
>  // anywhere except the definition of the form itself.
>  public BeanComposite() {
>super(form);
>
>FlowPanel panel = new FlowPanel();
>
>panel.add(bind(form.getFieldOne(), new
> TextBoxEditor(CurrencyConverter.INSTANCE)));
>panel.add(bind(form.getFieldTwo(), new
> LabelViewer(DefaultToString.INSTANCE)));
>panel.add(bind(form.getFieldThree(), new CreditCardEditor()));
>
>initWidget(panel);
>  }
> }
>
> // in random UI code
> BeanComposite bc = new BeanComposite();
>
> RootWidget.get().add(bc);
>
> 

[gwt-contrib] Re: polishing and promoting the incubator

[Arthur Kalmenson]

Hello Emily,

> Internally, we've started to toy with the idea of labeling
> widgets/libraries: Here is the initial proposal
>
>1. @ReleaseCandidate: This widget has been slotted for a GWT release. Its
>bug reports are taken as seriously as any normal gwt widgets and its API is
>less likely to change.
>2. @Beta:  This is a widget intended for wide distribution and is being
>actively supported by at least one developer. The code should be reasonably
>bug free as well.
>3. @DoNotUse or no tag: Don't use, is either in the process of being
>dropped from incubator or is still in alpha.

That sounds like a great idea, we could probably make at least
@ReleaseCandidate widgets available to a wider audience.

>- A maven repository to pick up the most recent gwt-incubator + gwt-trunk
>milestone build. If possible, would also create a nightly build as well.

Yes please! I'm a Maven person and I know there are a lot of Maven
users out there. A nightly gwt-incubator for Maven would be very
welcome!

>- Also, someone who would be willing to go through the current demos and
>improve them/flag developers if they are missing and/or just suck.

I can try to improve some of them, but I can definitely say which ones
need to be improved and which aspects. Should I start another post so
people can comment on which demos need improvement and what needs to
be improved?

>- Finally,  if people could nominate widgets they would like to see leave
>incubator, that would be very helpful as well!

This should be very easy to do with a Google Docs Form. Do you want me
to create one?

Regards,
Arthur Kalmenson

On Oct 10, 6:02 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> I actually tend to agree with Authur here, that in gwt-incubator we have
> widgets at different stages in the pipeline and while some we don't want
> users to touch, others are much more stable, and would benefit from wider
> user distribution and are at least as good, or better, then almost any other
> available gwt library.
>
> As widgets are moved into gen2, they are being all given default style
> sheets though improvements are always appreciated.
>
> Internally, we've started to toy with the idea of labeling
> widgets/libraries: Here is the initial proposal
>
>    1. @ReleaseCandidate: This widget has been slotted for a GWT release. Its
>    bug reports are taken as seriously as any normal gwt widgets and its API is
>    less likely to change.
>    2. @Beta:  This is a widget intended for wide distribution and is being
>    actively supported by at least one developer. The code should be reasonably
>    bug free as well.
>    3. @DoNotUse or no tag: Don't use, is either in the process of being
>    dropped from incubator or is still in alpha.
>
> Also, here is my wish list of things I'd love to get volunteers for:
>
>    - A maven repository to pick up the most recent gwt-incubator + gwt-trunk
>    milestone build. If possible, would also create a nightly build as well.
>    - Some sort of  ant/python/shell/ script that crawls through the new
>    src-demo and automatically builds all the  demos there.  We could then use
>    that  to easily publish on google app engine up-to-date demos for all
>    incubator widgets before each public drop.
>    - Someone to go through the documentation, fix what can be easily fixed,
>    and then e-mail out those widgets/libraries whose documentation need 
> serious
>    attention.
>    - Also, someone who would be willing to go through the current demos and
>    improve them/flag developers if they are missing and/or just suck.
>    - Finally,  if people could nominate widgets they would like to see leave
>    incubator, that would be very helpful as well!
>
> On Fri, Oct 10, 2008 at 4:57 PM, Arthur Kalmenson <[EMAIL PROTECTED]>wrote:
>
>
>
>
>
> > OK that makes sense. Maybe we need a project that's in between
> > incubator and GWT, something that has regular releases and uses
> > polished content from the incubator but content that's not so polished
> > that it would go into GWT. While what's in the incubator is a work in
> > progress, it is still a) much faster then what the other libraries
> > offer, b) mostly cleaner and better written then the other libraries,
> > c) gives people an idea of where GWT is headed.
>
> > While making custom widgets is easy in GWT, there is a lot of overlap
> > in what people need and there is usually a rich suite of widgets that
> > people would like out of the box. It's not very easy to pick up GWT
> > and dive in making great and interactive apps. There's a lot of group
> > work that needs to 

[gwt-contrib] Re: polishing and promoting the incubator

[Arthur Kalmenson]

OK that makes sense. Maybe we need a project that's in between
incubator and GWT, something that has regular releases and uses
polished content from the incubator but content that's not so polished
that it would go into GWT. While what's in the incubator is a work in
progress, it is still a) much faster then what the other libraries
offer, b) mostly cleaner and better written then the other libraries,
c) gives people an idea of where GWT is headed.

While making custom widgets is easy in GWT, there is a lot of overlap
in what people need and there is usually a rich suite of widgets that
people would like out of the box. It's not very easy to pick up GWT
and dive in making great and interactive apps. There's a lot of group
work that needs to be done to build rich widgets. It seems a waste
that this group work is done on every GWT project by all the various
organizations that use GWT. I know that the GWT team said GWT was
meant to be pretty low level and they wanted the community to build on
top of that, but it seems that the community is not delivering. I know
Bruce mentioned that better widgets are on the agenda, so I don't
know....

Regards,
Arthur Kalmenson

On Oct 10, 4:36 pm, "Isaac Truett" <[EMAIL PROTECTED]> wrote:
> We don't want people to be afraid of the Incubator, but we do want them to
> be cautious. It isn't a library per se, but a workshop for ideas. Things in
> the Incubator may be half finished or in the middle of refurbishing at any
> given time. It's an environment where you may have to get your hands dirty.
> It's not something that all GWT users will have the patience or risk
> tolerance for.
> Improving the contents of the Incubator is, of course, important. That's
> what it's there for. But I would expect that as things are "cleaned up"
> they'll be promoted to the main GWT project or spun off into separate
> libraries. What's left in the Incubator will always be works-in-progress.
>
> On Fri, Oct 10, 2008 at 4:15 PM, Arthur Kalmenson <[EMAIL PROTECTED]>wrote:
>
>
>
> > Hello everyone,
>
> > There was some discussion on the IRC channel about this, and I figured
> > I'd put it up for everyone here.
>
> > I think that the incubator has a lot of useful things (FooBundle,
> > CssResource, DatePicker), a lot of great ideas (Declarative UI) and
> > some not so great things (PagingScrollTable). The incubator has a lot
> > of potential, it just needs some polish and promotion. I think it
> > needs the following:
>
> > 1. Better and nicer examples of widgets and use of some nice CSS (just
> > use one of the GWT themes).
> > 2. Clean up the existing widgets and make them easier to use.
> > 3. A showcase to show off all these widgets and make them accessible
> > like the main GWT showcase.
> > 4. Promoting incubator as a great resource on the regular GWT group
> > and on the main GWT site.
>
> > As it stands right now, few people know about the incubator and those
> > that do are usually scared away. Most people end up going to widget
> > libraries like ExtGWT and others. Just about every widget library I've
> > seen is poorly done and ends up giving GWT a really bad name (ExtGWT
> > especially). I think the incubator can offer a much better and cleaner
> > widget library and components, but it needs to be cleaned up and
> > promoted so more people contribute and give feedback.
>
> > What do you think?
>
> > Regards,
> > Arthur Kalmenson
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] polishing and promoting the incubator

[Arthur Kalmenson]

Hello everyone,

There was some discussion on the IRC channel about this, and I figured
I'd put it up for everyone here.

I think that the incubator has a lot of useful things (FooBundle,
CssResource, DatePicker), a lot of great ideas (Declarative UI) and
some not so great things (PagingScrollTable). The incubator has a lot
of potential, it just needs some polish and promotion. I think it
needs the following:

1. Better and nicer examples of widgets and use of some nice CSS (just
use one of the GWT themes).
2. Clean up the existing widgets and make them easier to use.
3. A showcase to show off all these widgets and make them accessible
like the main GWT showcase.
4. Promoting incubator as a great resource on the regular GWT group
and on the main GWT site.

As it stands right now, few people know about the incubator and those
that do are usually scared away. Most people end up going to widget
libraries like ExtGWT and others. Just about every widget library I've
seen is poorly done and ends up giving GWT a really bad name (ExtGWT
especially). I think the incubator can offer a much better and cleaner
widget library and components, but it needs to be cleaned up and
promoted so more people contribute and give feedback.

What do you think?

Regards,
Arthur Kalmenson
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

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

[Arthur Kalmenson]

Hello Emily,

> Is there anyway we can convince you to use the Apache license rather then
> the GPL?  That would bring your project base into the same license as GWT,
> so it would be easier to grab code.

I switched the project to Apache 2 a few weeks ago, but the classes
that have comments on them still say it's under the LGPL. I'll update
that as soon as I can.

> I like the idea of a set of widgets used to rapidly create forms.   It  will
> be a little tricky to get right, because we'd want to explicitly not make
> any assumptions about data binding or validation.   How cleanly we can do
> that influences how much we should try this before the data
> binding/validation framework is in place.

I don't think it'll integrate with the data binding or validation at
all. I'll make sure to make it as extensible as possible, but I don't
think that visibility logic that deals with presentation needs to
integrate with validation or data binding. However, I think that it
will fit in a general forms framework where data binding and
validation could live.

> The Questions could then implement HasValue and fire
> SelectionEvents. This would make it easy for the QuestionLayoutPanel to
> figure out when to fire a given QuestionLayoutRule, where a
> QuestionLayoutRule takes in a set of Questions and is activated if any of
> those Questions change state.  The hope is that we could then  share the
> same visual framework with a variety of data-binding and validation
> frameworks, as we are not putting anything but presentation code into the
> actual Question widgets.  For instance, it might be possible to generate at
> compile time QuestionPanel from an xforms template  :-)
>
> So, here is some sample code.
>   QuestionPanel MedicalForm = new QuestionPanel();
>   List yesNoMaybe = ListUtil.create("yes","no", "maybe");
>   RadioButtonQuestion gender = new RadioButtonQuestion("gender",
> yesNoMaybe);
>   CheckBoxQuestion pregnant = new CheckBoxQuestion("Are you pregnant?",
> yesNoMaybe);
>   MedicalForm.add(gender);
>   MedicalForm.addQuestionLayoutRule(new InsertIfEqualRule(gender,"yes",
> pregnant));

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.

Regards,
Arthur Kalmenson

On Oct 8, 10:43 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> Is there anyway we can convince you to use the Apache license rather then
> the GPL?  That would bring your project base into the same license as GWT,
> so it would be easier to grab code.
>
> I like the idea of a set of widgets used to rapidly create forms.   It  will
> be a little tricky to get right, because we'd want to explicitly not make
> any assumptions about data binding or validation.   How cleanly we can do
> that influences how much we should try this before the data
> binding/validation framework is in place.
>
> What about the idea of creating a QuestionWidget hierarchy? Then we would
> have Questions like TextQuestion, RadioButtonQuestion, and, of course a
> QuestionPanel, where the QuestionPanel takes in a set of QuestionWidgets
> and QuestionLayoutRules.
>
> The Questions could then implement HasValue and fire
> SelectionEvents. This would make it easy for the QuestionLayoutPanel to
> figure out when to fire a given QuestionLayoutRule, where a
> QuestionLayoutRule takes in a set of Questions and is activated if any of
> those Questions change state.  The hope is that we could then  share the
> same visual framework with a variety of data-binding and validation
> frameworks, as we are not putting anything but presentation code into the
> actual Question widgets.  For instance, it might be possible to generate at
> compile time QuestionPanel from an xforms template  :-)
>
> So, here is some sample code.
>       QuestionPanel MedicalForm = new QuestionPanel();
>       List yesNoMaybe = ListUtil.create("yes","no", "maybe");
>       RadioButtonQuestion gender = new RadioButtonQuestion("gender",
> yesNoMaybe);
>       CheckBoxQuestion pregnant = new CheckBoxQuestion("Are you pregnant?",
> yesNoMaybe);
>       MedicalForm.add(gender);
>       MedicalForm.addQuestionLayoutRule(new InsertIfEqualRule(gender,"yes",
> pregnant));
>
>    Cheers,
>
>           Emily
>
> O

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

[Arthur Kalmenson]

Sounds good to me, a solution that fits seamlessly with GWT would be
very nice.

Will you be posting a design document about it? Will this all tie into
some form component for GWT? Will you include other useful features
like visibility logic?

Best regards,
Arthur Kalmenson

On Oct 8, 10: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
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] RR: visibility logic management

[Arthur Kalmenson]

As I mentioned before (http://groups.google.com/group/Google-Web-
Toolkit-Contributors/browse_thread/thread/b696e7319fc6bea/), I'm
looking to contribute our project back to the incubator as I refactor/
rebuild it. One of the main things that we were looking to simplify
was visibility management.

In our particular use cases, almost every application we build has a
relatively extensive form with complex visibility logic. For example,
if the user presses "Yes" on a radio button, another few fields open
up and they fill those fields out. The way that this logic is
currently done in GWT is through listeners and a lot of manual work.
The module that we created was suppose to simplify this. Here's what
we have so far.

We have something called a FormatPanel that allows you to make calls
like showIfSet(Widget a, Widget b, VisibilityRule rule). The
VisibilityRule sets listeners and so receives events from widgets a
and b. It then determines if widget "b" should be shown depending on
the value of widget a. There is also a hideIfSet() method.

Does this approach make sense? Let me know what you think. I'll
continue updating this part of the project and I'll try to post some
code and more concrete examples in the next few days. I'm just
wondering if the approach makes sense to people. Thank you.

Regards,
Arthur Kalmenson
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: data binding framework for GWT

[Arthur Kalmenson]

I'm sorry to hear that. I hope you have a safe journey.

Regards,
Arthur Kalmenson

On Oct 8, 12:14 pm, "Ian Petersen" <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 8, 2008 at 11:46 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
> > Will you start a new Google Code project for this data binding
> > framework?
>
> I can do that, but my week has suddenly filled up--I'm driving from
> Toronto to Winnipeg tonight for a funeral and then I'll be back Sunday
> night--so I'm not sure when things will get done.  If I have internet
> access between now and Sunday, I'll try to move forward during my
> trip.
>
> As for the rest of your post, I'll need to get back to it some other time.
>
> Ian
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: data binding framework for GWT

[Arthur Kalmenson]

Hi Ian,

> I *think* validation
> could be tied into the data binding framework in a pretty
> straightforward way by extending Editor and Viewer to be
> validation-aware.

I agree, it shouldn't be too hard to tie validation into data binding,
but...

> I think data binding and validation probably need to be aware of each
> other (or, at least, data binding needs to be aware of validation),
> but I think they're separate concerns.  To me, data binding is just a
> way of automating the display and update of a bean's properties via
> some widgets.  Validation, on the other hand, is a way of making sure
> that a property is within some bounds, or some combination of
> properties together follow some rules.  Data binding impacts
> validation because the user could transform a bean into or out of a
> valid state, and validation impacts data binding because you usually
> need to give the user feedback about the validity of the bean being
> edited, but I think the relationship between data binding and
> validation is probably best mediated through a thin interface that
> keeps things loosely coupled.
>
> What do you think?  (Or anyone else, for that matter.)

I agree, I think that they should be loosely coupled or completely
decoupled.

One question that arises from this is, who's role is it to display
error messages to the user? Should it be the data binding framework,
the validation framework or something else? Personally, I think that a
third library should come into play here that will be able to apply
the appropriate formatting to widgets when they are invalid/valid. I
think that these three components should be tied together with
listeners or handlers or some other implementation of the observer
pattern. I'm thinking something like this:

Widgets changes
=> bean is updated by data binding
=> data binding broadcasts that something has changed
=> validation picks up change and validates the bean
=> validation broadcasts results
=> formatter library catches new validation and updates widgets
accordingly

I think that we should get Chris Ruffalo in on the conversation so
that something like this could be coordinated between these two
frameworks. I know that Ray said the GWT will be implementing
something themselves (http://groups.google.com/group/Google-Web-
Toolkit-Contributors/browse_thread/thread/8c611ab8bb076ead) but I'm
sure what you and Chris have done will help the GWT team out a lot.

Will you start a new Google Code project for this data binding
framework?

Regards,
Arthur Kalmenson

On Oct 7, 3:47 pm, "Ian Petersen" <[EMAIL PROTECTED]> wrote:
> Hi Arthur,
>
> On Tue, Oct 7, 2008 at 1:51 PM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
> >> I don't mean to nitpick, but it's actually the editor that puts back
> >> the previous value, not the converter.  The converter just throws a
> >> ConversionException if the String couldn't be converted.  It's up to
> >> the editor to decide what to do with the ConversionException.
>
> > Ah, sorry, I misunderstood how it was working. Thanks for clearing
> > that up. This also deals with the original use case I proposed above
> > (not updating the model right away). I only thought of that case
> > because it kept trying to convert and reverting the field to it's
> > previous value, which prevented validation from running its course.
> > I'll just create my own editor and leave the field the way it was.
>
> I read your comment on issue 343
> (http://code.google.com/p/google-web-toolkit/issues/detail?id=343#c31).
>  I haven't finished reading the Bean Validation JSR yet, and I haven't
> looked at Chris Ruffalo's code, but I have dipped my toe into using
> Hibernate validation in my own server-side code.  I *think* validation
> could be tied into the data binding framework in a pretty
> straightforward way by extending Editor and Viewer to be
> validation-aware.
>
> At the moment, Viewer and Editor just provide simple interfaces
> to view (and edit) a value of type T.  If there was some way to talk
> about the validity of a given value, Viewer (and, by extension,
> Editor) could be extended to provide feedback to the user when the
> value it's displaying changes from invalid to valid or valid to
> invalid.
>
> I assume that Hibernate validation-style validation requires some kind
> of "validation service" that is external to the beans being validated.
>  (As opposed to the beans themselves somehow performing validation and
> reporting the results.)  If that's the case, a BoundField could listen
> to its editor for EditorChangeEvents and filter the new value through
> validation before/after/around updating the related bean.  If you

[gwt-contrib] Re: data binding framework for GWT

[Arthur Kalmenson]

> When I designed the library, I thought of bound widgets as views on
> fields in a bean.  If the bean changes, the widget is updated and if
> the widget changes, the bean is updated.  If you created a "detached"
> editor that didn't automatically update the bean, what would you want
> to happen if the bean were to change behind the scenes?  Right now, if
> the bean SourcesPropertyChangeEvents, the editors and viewers are
> updated onPropertyChange.  Would you want a detached editor to ignore
> property change events from the associated bean?

When you put it that way, I see that the use case I mentioned isn't
really useful. You make some good points and I think that your
approach is what we'll end up using. Keeping with the MVC pattern by
keeping the model and view in sync is a better idea (and can let
people collaborate on a single model). Thanks for clearing that up for
me.

> I'd be surprised if a
> real application had a single field with 100+ dependent viewers,
> though.

I was thinking more along the lines of 100+ fields bound to various
objects, but it probably won't be a problem. I could run some GWT
benchmarks to see if there is any issue.

> I don't mean to nitpick, but it's actually the editor that puts back
> the previous value, not the converter.  The converter just throws a
> ConversionException if the String couldn't be converted.  It's up to
> the editor to decide what to do with the ConversionException.

Ah, sorry, I misunderstood how it was working. Thanks for clearing
that up. This also deals with the original use case I proposed above
(not updating the model right away). I only thought of that case
because it kept trying to convert and reverting the field to it's
previous value, which prevented validation from running its course.
I'll just create my own editor and leave the field the way it was.

Ian, I think this data binding framework is really excellent. It's
really well thought out and I think it'll be a major contribution to
GWT. I hope it makes it into the incubator soon. Thanks for your hard
work.

Regards,
Arthur Kalmenson

On Oct 7, 11:29 am, "Ian Petersen" <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 7, 2008 at 10:56 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
> > Yes, I'm looking to avoid updating the bean automatically. I want to
> > specify when the bean should be updated.
>
> I see.  I hadn't thought of that use case.  As it stands, no, you
> can't do that.  BoundFieldImpl has a nested class Listener that
> implements EditorChangeListener.  BoundFieldImpl's getEditor() adds
> an instance of Listener as a change listener to the editor before
> returning it.  That listener takes care of updating the bean when the
> editor changes and, as it stands, you can't not add the listener.
>
> When I designed the library, I thought of bound widgets as views on
> fields in a bean.  If the bean changes, the widget is updated and if
> the widget changes, the bean is updated.  If you created a "detached"
> editor that didn't automatically update the bean, what would you want
> to happen if the bean were to change behind the scenes?  Right now, if
> the bean SourcesPropertyChangeEvents, the editors and viewers are
> updated onPropertyChange.  Would you want a detached editor to ignore
> property change events from the associated bean?
>
> > It'll also be interesting to see what the performance implications are
> > of having the bean updated on any change. Does it work fine for forms
> > of 100+ fields?
>
> I haven't explicitly tested it with that many fields, but I'd expected
> it to be okay--only the property bound to a given widget will be
> updated when that widget changes.  In the example I posted, the Person
> class has firstName and lastName properties.  When you edit a given
> person, the firstName and lastName properties are bound to text boxes.
>  If you edit the first name, only the firstName property is updated
> and likewise for the last name.  Where there could be performance
> considerations is if you have "lots" of viewers and/or calculated
> fields all depending on the same property and then you edit that
> property.  I don't know what would happen then--the UI would probably
> freeze until the updates were all complete.  I'd be surprised if a
> real application had a single field with 100+ dependent viewers,
> though.
>
> > Hmm, that's a good point. However, the way the current Converters work
> > is that they remove the value that is entered by the user if it
> > doesn't convert properly. As you mentioned, this probably has to do
> > with the way exceptions are handled (putting back the previ

[gwt-contrib] Re: data binding framework for GWT

[Arthur Kalmenson]

> I'm not sure what you mean.  Are you looking to avoid updating the
> bean until sometime after the editor has changed?

Yes, I'm looking to avoid updating the bean automatically. I want to
specify when the bean should be updated.

It'll also be interesting to see what the performance implications are
of having the bean updated on any change. Does it work fine for forms
of 100+ fields?

> I understand the converters as a way to map between a textual widget
> and some non-String data type T.  To me, a validator has as a first
> assumption that the value it's validating is at least of the right
> type.  For example, validation on a birth date might require that the
> birth date be before System.currentTimeMillis(), but the validator
> would assume that it's validating a Date and not a String.  In this
> case, the converters are necessary as a first pass before the
> validators.
>
> I haven't looked at the validators, though, so I'll have a look when I
> get to the office and think it over some more.

Hmm, that's a good point. However, the way the current Converters work
is that they remove the value that is entered by the user if it
doesn't convert properly. As you mentioned, this probably has to do
with the way exceptions are handled (putting back the previous value,
which happened to be empty).

I think that the validation that you have in mind is bean based
validation, which is being discussed already (http://code.google.com/p/
google-web-toolkit/issues/detail?id=343). This is different from the
widget based validation which is currently in the incubator. Things
are all over the place right now, and I think we need some direction
from the GWT team.

> Thanks!  And thanks for looking at it, too.  Besides documentation
> (and tests, I guess) another big thing that needs to be handled is
> i18n.  Right now, the best way to get nice labels for bound fields is
> with the @Label annotation.  That should probably go away and,
> instead, the FormGenerator should spit out a Form implementation that
> gets its labels from a properties file via a Constants subtype.  I'm
> not sure the best way to do that, though, because I haven't used GWT's
> i18n facilities much.

We'll try to take a closer look and see if we can help out. We need to
get started on some of our projects, but this data binding framework
would be very helpful since we build/will build a lot of form based
applications. Thanks for sharing your code!

On Oct 7, 10:20 am, "Ian Petersen" <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 7, 2008 at 9:28 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
> > - Is it possible to run the binding on demand instead of automatically
> > with the attached listeners? Say I want to only run the binding after
> > the user pressed the submit button, is that possible?
>
> I'm not sure what you mean.  Are you looking to avoid updating the
> bean until sometime after the editor has changed?
>
> > - the converters are useful for general data mapping, but they also
> > seem to be performing the role of validator. Is it possible to use the
> > validation framework from the incubator or the one proposed here:
> >http://code.google.com/p/google-web-toolkit/issues/detail?id=343#c30.
> > Or, should the converters continue to perform the role of converting
> > the data to match the binded data type? The converters wouldn't be a
> > problem if the binding could be delayed and allow validation to run
> > it's course.
>
> I understand the converters as a way to map between a textual widget
> and some non-String data type T.  To me, a validator has as a first
> assumption that the value it's validating is at least of the right
> type.  For example, validation on a birth date might require that the
> birth date be before System.currentTimeMillis(), but the validator
> would assume that it's validating a Date and not a String.  In this
> case, the converters are necessary as a first pass before the
> validators.
>
> I haven't looked at the validators, though, so I'll have a look when I
> get to the office and think it over some more.
>
> > - when executing Integer.parseInt() in the converters on non Integers,
> > an exception should be thrown, but it seems to be getting caught
> > somewhere. Where is that happening?
>
> I'm guessing without looking at the source code, but I think you're
> talking about HasTextEditor.widgetChanged().  There's some code
> that looks roughly like this (the code might be different, and there
> aren't as many comments):
>
> private void widgetChanged() {
>   try {
>     // calls converter.fromString(widget.getText());
>     this.value = doReadV

[gwt-contrib] Re: data binding framework for GWT

[Arthur Kalmenson]

Hello Ian,

I had a coworker take a look at the data binding framework. It looks
really good so far, but we had a couple of questions:

- Is it possible to run the binding on demand instead of automatically
with the attached listeners? Say I want to only run the binding after
the user pressed the submit button, is that possible?
- the converters are useful for general data mapping, but they also
seem to be performing the role of validator. Is it possible to use the
validation framework from the incubator or the one proposed here:
http://code.google.com/p/google-web-toolkit/issues/detail?id=343#c30.
Or, should the converters continue to perform the role of converting
the data to match the binded data type? The converters wouldn't be a
problem if the binding could be delayed and allow validation to run
it's course.
- when executing Integer.parseInt() in the converters on non Integers,
an exception should be thrown, but it seems to be getting caught
somewhere. Where is that happening?

This framework looks very promising and well thought out. A less
verbose binding mechanism would be nice, but I'm not entirely sure how
it would be done. Thanks for the great work, I hope that this makes it
into the incubator soon.

Regards,
Arthur Kalmenson

On Oct 3, 11:09 pm, "Ian Petersen" <[EMAIL PROTECTED]> wrote:
> Here's a sample project.  The .tgz includes an updated
> data_binding.jar because I found a few bugs while working on the
> example.  The new JAR also includes .class files as generated by Sun's
> javac version 1.5.something.  The .tgz includes Sandy McArthur's
> PropertyChange stuff, so you _should_ be able to import the Eclipse
> project and run it.  Let me know if you have problems.
>
> Ian
>
>  data_binding_example.tgz
> 196KViewDownload
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR: updates and design changes to incubator validation

[Arthur Kalmenson]

Hey Emily,

Is there a use case when a ValidatorController will hold different
types of Subjects and Validators or can I assume that
ValidatorController is generic and the generic type will be the same
in Validators and Subjects?

Regards,
Arthur Kalmenson

On Oct 6, 12:20 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> > va 1.5 features that are now available
> > 
> > This is pretty straight forward. I would use typed lists in
> > AbstractValidationController, make Subject a generic interface (for
> > the value returned), and other minor changes.
>
> Yes.
>
>
>
> > Use interfaces instead of abstract classes
> > 
> > A lot of the main validation classes are abstract classes. Some
> > examples are ErrorHandler, AbstractValidationController and Validator.
> > This creates a lot of problems for unit testing these classes because
> > you can't really mock them out, you have to instantiate them, etc.
> > Therefore, I think it's better to make these classes interfaces and
> > make an abstract concrete implementation that includes the current
> > code.
>
> To me, this depends upon how well you can factor them into characteristic
> interfaces.  What we want to avoid is an interface with a "bundle of
> functionality" where we locked out of adding more features.
>
> Some of the system might be able to be be mapped into the event handlers
> framework or something similar (i.e. a set of validation events consumed by
> validation handlers)  this pattern gives the the advantages of interfaces,
> but can still be enhanced over time.
>
>
>
> > Write test cases
> > 
> > The validation library is currently missing unit tests, I'd like to
> > add extensive tests. I wanted to use EasyMock (http://
> >www.easymock.org/) for testing some of the stuff that doesn't involve
> > GWT.create() calls. EasyMock is under the MIT license, is it
> > acceptable to use and include?
>
> Let me check with legal on this one.  GWT code certainly runs with easy
> mock, however I don't know if we can bundle it with the gwt-incubator code.
>
> > Remove static methods
> > 
> > There are a number of static methods scattered around in classes like
> > the DefaultTextBoxSubject, RegExValidator and ValidatorController.
> > Static methods really make testing hard, and global states are in
> > general bad. Is there a specific reason for these static methods?
>
> This is completely true of server side code, and therefore as validation is
> a shared system, we would definitely want to go over it with a fine-toothed
> comb.
>
> GWT Client side web applications, in general, are less subject to this
> rule,  because
>
>    1. They are, by nature, single threaded
>    2. They are, by nature, single user
>    3. They run on JavaScript, so are,by nature, slow
>    4. They need to include the fewest lines of code possible, which means we
>    must be very careful that the compiler can trace through when code is
>    actually needed, in other words a lot of the injection-dependency systems
>    which are perfect for server code end up creating really bad  GWT apps.
>
>
>
> > Annotation based validation
> > 
> > What do you think about annotation based validation? It could look
> > something like this:
>
> > @NotEmptyValidator
> > TextBox firstName = new TextBox();
>
> > @NumberRangeValidator(low = 18, high = 100)
> > TextBox age = new TextBox();
>
> > I like the general principle, the devil, of course, will be in the details!
> > Let me know what you think. Thank you.
>
> > Regards,
> > Arthur Kalmenson
>
> --
> "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: RR: updates and design changes to incubator validation

[Arthur Kalmenson]

> To me, this depends upon how well you can factor them into characteristic
> interfaces.  What we want to avoid is an interface with a "bundle of
> functionality" where we locked out of adding more features.
>
> Some of the system might be able to be be mapped into the event handlers
> framework or something similar (i.e. a set of validation events consumed by
> validation handlers)  this pattern gives the the advantages of interfaces,
> but can still be enhanced over time.

I was thinking of just copying and pasting the methods the current
abstract classes have to make a new interface. For example, Validator
will look like this:

public interface Validator {
  public void checkValid(Subject subject);
  public void checkValid(Subject element, ErrorHandler handler);
}

and the abstract concrete implementation would be:

public abstract class AbstractValidator implements Validator {
  public final void checkValid(Subject subject) {
checkValid(subject, ValidatorController.getDefaultErrorHandler());
  }
}

Putting this into the event handler framework sounds like an
interesting idea. I'm not familiar with event handlers yet, but I'll
take a look.

> This is completely true of server side code, and therefore as validation is
> a shared system, we would definitely want to go over it with a fine-toothed
> comb.
>
> GWT Client side web applications, in general, are less subject to this
> rule,  because
>
>1. They are, by nature, single threaded
>2. They are, by nature, single user
>3. They run on JavaScript, so are,by nature, slow
>4. They need to include the fewest lines of code possible, which means we
>must be very careful that the compiler can trace through when code is
>actually needed, in other words a lot of the injection-dependency systems
>which are perfect for server code end up creating really bad  GWT apps.

Hmm, that makes sense. It's still kind of nasty from a testing
perspective. Furthermore, since you touched on dependency injection,
perhaps a good way to wire these classes together would be to use
Google GIN (http://code.google.com/p/google-gin/). It's fairly new,
but it looks very promising.

I'll add an issue about the update to Java 1.5 and I'll start
implementing that portion.

Regards,
Arthur Kalmenson

On Oct 6, 12:20 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> > va 1.5 features that are now available
> > 
> > This is pretty straight forward. I would use typed lists in
> > AbstractValidationController, make Subject a generic interface (for
> > the value returned), and other minor changes.
>
> Yes.
>
>
>
> > Use interfaces instead of abstract classes
> > 
> > A lot of the main validation classes are abstract classes. Some
> > examples are ErrorHandler, AbstractValidationController and Validator.
> > This creates a lot of problems for unit testing these classes because
> > you can't really mock them out, you have to instantiate them, etc.
> > Therefore, I think it's better to make these classes interfaces and
> > make an abstract concrete implementation that includes the current
> > code.
>
> To me, this depends upon how well you can factor them into characteristic
> interfaces.  What we want to avoid is an interface with a "bundle of
> functionality" where we locked out of adding more features.
>
> Some of the system might be able to be be mapped into the event handlers
> framework or something similar (i.e. a set of validation events consumed by
> validation handlers)  this pattern gives the the advantages of interfaces,
> but can still be enhanced over time.
>
>
>
> > Write test cases
> > 
> > The validation library is currently missing unit tests, I'd like to
> > add extensive tests. I wanted to use EasyMock (http://
> >www.easymock.org/) for testing some of the stuff that doesn't involve
> > GWT.create() calls. EasyMock is under the MIT license, is it
> > acceptable to use and include?
>
> Let me check with legal on this one.  GWT code certainly runs with easy
> mock, however I don't know if we can bundle it with the gwt-incubator code.
>
> > Remove static methods
> > 
> > There are a number of static methods scattered around in classes like
> > the DefaultTextBoxSubject, RegExValidator and ValidatorController.
> > Static methods really make testing hard, and global states are in
> > general bad. Is there a specific reason for these static methods?
>
> This is completely true of server side code, and therefore as validation is
> a shared system, we would definitely want to go over it with a fine-toothed
> comb.
>
> GWT Clien

[gwt-contrib] RR: updates and design changes to incubator validation

[Arthur Kalmenson]

Hello all,

I'd really like to use the validation part of incubator, but I'd like
to do the following updates and design changes:

Update to use Java 1.5 features that are now available

This is pretty straight forward. I would use typed lists in
AbstractValidationController, make Subject a generic interface (for
the value returned), and other minor changes.

Use interfaces instead of abstract classes

A lot of the main validation classes are abstract classes. Some
examples are ErrorHandler, AbstractValidationController and Validator.
This creates a lot of problems for unit testing these classes because
you can't really mock them out, you have to instantiate them, etc.
Therefore, I think it's better to make these classes interfaces and
make an abstract concrete implementation that includes the current
code.

Write test cases

The validation library is currently missing unit tests, I'd like to
add extensive tests. I wanted to use EasyMock (http://
www.easymock.org/) for testing some of the stuff that doesn't involve
GWT.create() calls. EasyMock is under the MIT license, is it
acceptable to use and include?

Remove static methods

There are a number of static methods scattered around in classes like
the DefaultTextBoxSubject, RegExValidator and ValidatorController.
Static methods really make testing hard, and global states are in
general bad. Is there a specific reason for these static methods?

Annotation based validation

What do you think about annotation based validation? It could look
something like this:

@NotEmptyValidator
TextBox firstName = new TextBox();

@NumberRangeValidator(low = 18, high = 100)
TextBox age = new TextBox();


Let me know what you think. Thank you.

Regards,
Arthur Kalmenson
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Incubator review request: HasValue

[Arthur Kalmenson]

Does this mean that all the GWT core widgets will implement the
HasValue interface?

On Oct 4, 10:33 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> LGTM
>
>
>
> On Fri, Oct 3, 2008 at 9:16 PM, Isaac Truett <[EMAIL PROTECTED]> wrote:
> > Oops. My *other* datepicker, right.
> > Here's the new patch with gen2 datepicker and implementing HasValue on
> > DropDownListBox instead of CustomListBox.
>
> > Thanks,
> > Isaac
>
> > On Fri, Oct 3, 2008 at 6:21 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
> >> I like the feel of it, can you patch against the gen2 datepicker though?
> >> Also, I think we might want to move the HasValue interface from
> >> CustomListBox to DropDownListBox, as we plan to eventually have a
> >> MultiSelectListBox and therefore, we might want to keep our options open.
>
> >> On Fri, Oct 3, 2008 at 5:43 PM, Isaac Truett <[EMAIL PROTECTED]> wrote:
>
> >>> I originally proposed a HasValue interface in this 
> >>> thread.
> >>> Although the discussion largely focused on data binding, HasValue is not 
> >>> an
> >>> attempt at a data binding library. The HasValue concept is more about
> >>> providing a common API for many Widgets and other Objects that have a
> >>> distinct logical value. This is conceptually the same as HasText, but
> >>> parameterized to allow for data types other than String.
> >>> The attached patch to the Incubator trunk includes the HasValue interface
> >>> and implements this interface in DropDownListBox and DatePicker.
>
> >> --
> >> "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] Re: RR: making extracting and setting widget data easier

[Arthur Kalmenson]

Sorry for not getting a chance to respond earlier...

> However, at the same time, a more complex data binding API seems like it
> could be very useful as well. Maybe the trick is we should treat the two
> discusions seperately.

I agree completely.

> a) Create a HasValue, potencially extending a HasReadOnlyValue
> interface which is used even for base ui widgets. This one might make into
> 1.6 even.

I think that this idea is fine because the data extraction and setting
is simple for core GWT widgets. The main reason I didn't do it this
way, as I mentioned to Emily, was that I didn't want to mirror all the
core GWT widgets. If this makes it into 1.6, that would be great (if
it can appear in the trunk, I'll switch to trunk so I can use this).

However, for more complex widgets, I think a separation between data
management logic and the widget's primary role of displaying itself is
a good idea. As Ian said, building data bindings and data management
on top of widgets allows you to separate concern and roll your own
solutions (instead of subclassing and overriding Widgets). Therefore,
baking HasValue into the base Widgets makes customization a little
complex.

> b) Create a data binding framework that  binds widgets to more complex
> data.  It will probably not be ready for several months and should be very
> flexible.

I'll start another discussion about data binding since I think it's an
important and useful feature and should probably be included in
incubator if not in gwt. I was talking to papick in #gwt who created a
simple data binding library using generators. I'll try to see if he
can release his code, so we could potentially work from it.

Regards,
Arthur Kalmenson

On Oct 3, 1:25 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> I think this basic idea makes sense, though I might argue that we might want
> to create a DropDownListBox and a MultiSelectListBox  and deprecate list
> box, as the API for ListBox is hard to normalize this way.
>
> However, at the same time, a more complex data binding API seems like it
> could be very useful as well. Maybe the trick is we should treat the two
> discusions seperately.
>
> a) Create a HasValue, potencially extending a HasReadOnlyValue
> interface which is used even for base ui widgets. This one might make into
> 1.6 even.
>
> b) Create a data binding framework that  binds widgets to more complex
> data.  It will probably not be ready for several months and should be very
> flexible.
>
>
>
> On Fri, Oct 3, 2008 at 1:09 PM, Isaac Truett <[EMAIL PROTECTED]> wrote:
>
> > > Perhaps.  What would ListBox implement?  HasData or
> > > HasData> (ie. do we assume single-select or
> > > multi-select)?
>
> >   /**
> >   * Gets the currently-selected item. If multiple items are selected, this
> >   * method will return the first selected item ([EMAIL PROTECTED]
> > #isItemSelected(int)}
> >   * can be used to query individual items).
> >   *
> >   * @return the selected index, or -1 if none is selected
> >   */
> >  public int getSelectedIndex() {
> >    return getSelectElement().getSelectedIndex();
> >  }
>
> > To me, this indicates an existing single-select bias. On that basis, I
> > would say that ListBox implements HasValue. Or...
>
> > interface HasValue {
> >  T getValue();
> >  void setValue(T value);
> > }
>
> > interface HasValues> extends HasValue {
> >  Collection getValues();
> >  void setValues(Collection values);
> > }
>
> > I'm shooting from the hip there, but at first glance it makes sense.
> > Then ListBox implements HasValues and you get singular methods
> > which return the first selected item or set the only selected
> > (removing any other selections) item. The plural methods obviously get
> > and set all selected items.
>
> > > Would Label implement HasData?
>
> > Yes. HasData would essentially replace HasText, wouldn't it?
>
> > On Fri, Oct 3, 2008 at 12:52 PM, Ian Petersen <[EMAIL PROTECTED]> wrote:
>
> > > Isaac has also replied while I'm writing this.  I now see that Isaac's
> > > and Ray's suggestions are not as all-encompassing as I originally
> > > interpreted them.  I'm just stepping out for lunch now, though, so I
> > > don't really have time to think about this properly or reply with the
> > > thoughtfulness that's due.  Maybe after lunch I'll extend what
> > > follows.
>
> > > On Fri, Oct 3, 2008 at 12:38 PM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> > >> I think you're reading too much into the word "data."
>
>

[gwt-contrib] data binding framework for GWT

[Arthur Kalmenson]

Hello everyone,

As per the topic started here:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/b696e7319fc6bea/1e5032e44b52f280
I wanted to start a separate topic about data binding in GWT. I know
that this topic has already been discussed here:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/cf792280b5451a2a/06cdc183274e3fd4
and here: 
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/2c89a4239fde2b97/92b2d01619cc76c1
but that was back in January and GWT has change substantially since
then.

I think with the new features in 1.5 there are a number of different
approaches that we could take to data binding (maybe annotation
based?). What's you're take on a data binding framework for GWT? For
me, a data binding framework will be _very_ useful especially for my
particular use case where we have large forms with dozens of
questions. Being able to automatically map them to beans that I can
send to the server side and store would be a huge plus.

Regards,
Arthur Kalmenson
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR: making extracting and setting widget data easier

[Arthur Kalmenson]

> If you buy my argument that HasData needs to imply
> SourcesDataChangeEvents, then I think it follows that Label should
> not implement HasData.  Something like HasReadOnlyData (like
> Emily suggested) would be necessary to bridge the gap between
> "editors" and "viewers".

I agree 100%, the hasText interface is very confusing. Sometimes it's
used to represent text set by users (TextBox) as well as text set by
the application (Label). I think that a HasData and
HasReadOnlyData is a great idea. Implementing some
SourcesDataChangeEvents interface will make it easier to do
validation and help make efficient data binding where the target bean
will only receive changed widgets.

> On a completely different note, I just noticed that RadioButton
> inherits from CheckBox.  Does it make sense for RadioButton to
> implement HasData?  To me, a collection of RadioButtons is
> roughly equivalent to a single-select ListBox and, as such,
> RadioButton implementing HasData is somewhat nonsensical,
> whereas a collection of RadioButtons should probably implement
> HasData, or something similar.

I agree, it should be HasData, but I think that RadioButton
should not be a single entity that's linked by a String group name (at
least not from the GWT side, I understand the JS side has to be like
that). I think that RadioButton should be RadioButtons and should act
more like ListBox where you can add additional choices. The current
RadioButton implementation is pretty low level and is rather close to
the way it's done in Javascript.

Regards,
Arthur Kalmenson

On Oct 3, 2:33 pm, "Ian Petersen" <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 3, 2008 at 1:09 PM, Isaac Truett <[EMAIL PROTECTED]> wrote:
> >> Would Label implement HasData?
>
> > Yes. HasData would essentially replace HasText, wouldn't it?
>
> (As an aside, if HasData replaces HasText, perhaps HasText
> should be "redefined" to extend HasData.)
>
> Ray talked about creating a "uniform way to find out what value a
> widget is showing" and Isaac described HasData as "a tool for
> normalizing API".  I think those are key ideas.  As such, I think we
> need to go one step further.  HasData should imply
> SourcesChangeEvents, or maybe SourcesDataChangeEvents.  A TextBox
> certainly HasData, but I think it's equally important that the
> user can change the data in the text box.  Any data binding library is
> going to have to listen for updates from the widgets that are capable
> of editing a value, and I think normalizing the notification of those
> changes is at least as useful as normalizing the display of values.
> In particular, I think CheckBox would benefit from
> SourcesDataChangeEvents.
>
> If you buy my argument that HasData needs to imply
> SourcesDataChangeEvents, then I think it follows that Label should
> not implement HasData.  Something like HasReadOnlyData (like
> Emily suggested) would be necessary to bridge the gap between
> "editors" and "viewers".
>
> On a completely different note, I just noticed that RadioButton
> inherits from CheckBox.  Does it make sense for RadioButton to
> implement HasData?  To me, a collection of RadioButtons is
> roughly equivalent to a single-select ListBox and, as such,
> RadioButton implementing HasData is somewhat nonsensical,
> whereas a collection of RadioButtons should probably implement
> HasData, or something similar.
>
> Ian
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR: making extracting and setting widget data easier

[Arthur Kalmenson]

> > Why wrappers? Why not have the widgets simply implement a HasData
> > interface?

As Emily pointed out, this helps separate presentation logic from the
data model. Furthermore, there are cases when you want to get data out
of the same widget in different ways. A good example is a DataManager
for ListBoxes. A simple implementation would look something like this:

public class ListBoxDataManager implements DataManager {
public String getData(ListBox widget) {
String result = null;
if (widget.getSelectedIndex() > -1) {
result = widget.getValue(widget.getSelectedIndex());
}
return result;
}

public void setData(ListBox widget, String data) {

// go through the list of
for (int i = 0; i < widget.getItemCount(); i++) {
if (widget.getValue(i).equals(data)) {
widget.setSelectedIndex(i);
break;
}
}
}
}

However, if you're working with a lot of ListBoxes that have a default
value set at index 0, you might create a different DataManager to
handle that particular use case and return null if the first index is
selected.

> The same widgets might be used to get/set different data types and it
> separates the presentation logic from the data model, so separating the two
> seems to make some sense. On the other hand, it means that there is no
> simple interface that can be used when you actually do have data model
> objects:
>
> So what if we combined the two:
>
> public interface HasData {
>public T getData();
>public void setData(T data);
>
> }
>
> then:
>
> public interface DataManager   {
>  public HasData getData(T widget);
>  public void setData(T widget, S data);

That's a good point but I'm not sure I really understand the sample
code. Is the idea that if I have a data model Widget, it would
implement the HasData interface? It seems that S would end up being
the same as T in the generic implementation. I'll try to implement
this to get an idea what you mean.

Best regards,
Arthur Kalmenson

On Oct 3, 11:25 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> Having worked on similar projects, I am very enthusiastic about the idea of
> creating a full gwt forms module,  as apart from it being a true pain in the
> neck to create them by hand, improving the overall quality of such forms
> will, in the long term, save lives, so I'm looking forward to this work.
>
> ---
>
> The same widgets might be used to get/set different data types and it
> separates the presentation logic from the data model, so separating the two
> seems to make some sense. On the other hand, it means that there is no
> simple interface that can be used when you actually do have data model
> objects:
>
> So what if we combined the two:
>
> public interface HasData {
>        public T getData();
>        public void setData(T data);
>
> }
>
> then:
>
> public interface DataManager   {
>      public HasData getData(T widget);
>      public void setData(T widget, S data);
>
>
>
> }
> On Fri, Oct 3, 2008 at 11:06 AM, Isaac Truett <[EMAIL PROTECTED]> wrote:
>
> > Why wrappers? Why not have the widgets simply implement a HasData
> > interface?
>
> > public interface HasData {
> >        public T getData();
> >        public void setData(T data);
> > }
>
> > Maybe I'm just not seeing your use case.
>
> > On Fri, Oct 3, 2008 at 10:55 AM, Arthur Kalmenson <[EMAIL PROTECTED]>
> > wrote:
>
> > > Hello every,
>
> > > Just a little backgrounder for this RR. For some time now, a coworker
> > > and I have been working on and off on a library/framework to simplify
> > > creation of GWT applications, specifically those that cover most of
> > > our use cases. For the most part, the applications we build involve
> > > filling out rather large forms, retrieving data, generating reports,
> > > etc. Building these large forms by hand is very tedious, so we created
> > > an open source project called Mount Sinai Hospital Application Builder
> > > (mshab) which you can find here:http://code.google.com/p/mshab/.
>
> > > I started to overhaul the project to make it easier to use and easier
> > > to extend. As I started the overhaul, I noticed that the incubator
> > > started to get populated with a lot of similar widgets and libraries
> > > that I was redeveloping. I contacted Emily Crutcher about the
> > > Validation aspect 

[gwt-contrib] RR: making extracting and setting widget data easier

[Arthur Kalmenson]

Hello every,

Just a little backgrounder for this RR. For some time now, a coworker
and I have been working on and off on a library/framework to simplify
creation of GWT applications, specifically those that cover most of
our use cases. For the most part, the applications we build involve
filling out rather large forms, retrieving data, generating reports,
etc. Building these large forms by hand is very tedious, so we created
an open source project called Mount Sinai Hospital Application Builder
(mshab) which you can find here: http://code.google.com/p/mshab/.

I started to overhaul the project to make it easier to use and easier
to extend. As I started the overhaul, I noticed that the incubator
started to get populated with a lot of similar widgets and libraries
that I was redeveloping. I contacted Emily Crutcher about the
Validation aspect and we ended up talking a bit about the incubator. I
decided that it'll be best to try to commit back to the incubator so
we could avoid having to throw away our code after the incubator
implemented the same ideas. I'll start making RRs about the various
parts that we were working on to get feedback and hopefully
incorporate it into the incubator.

Now, to the meat of the post. Right now, extracting data from widgets
is very different depending on the widget. From a TextBox, you call
textBox.getText(). For a ListBox you call
listBox.getValue(listBox.getSelectedItem()). Setting the data is
different too, and sometimes pretty "complex" (ListBox involves a
loop, etc). Therefore, I'm proposing a common interface that wraps
around core GWT widgets and provides one way to extract and set data
to widgets. There are a number of use cases where this can be applied.
Some good examples are validation and simple data binding.

The interface is a straight forward generic interface that works with
a generic widget and a generic data type (comments removed):

public interface DataManager {

public S getData(T widget);

public void setData(T widget, S data);
}

Here's an example of how it would be used to manage TextBoxBase
widgets.

public class TextBoxBaseDataManager implements
DataManager {

public String getData(TextBoxBase widget) {
return widget.getText();
}

public void setData(TextBoxBase widget, String data) {
widget.setText(data);
}
}

To help developers easily get the appropriate DataManager for a
specific widget, I created a DataManagerCollection interface where you
can get the specific DataManager for a given widget and then start
working with it. The developer can either use existing
DataManagerCollection implementations or wire their own.

public interface DataManagerCollection {

public boolean hasDataManager(Widget widget);

public DataManager getDataManager(Widget widget);

public void setDataManager(Widget widget, DataManager
dataManager);
}

We're currently working on creating wrappers for all the core GWT
widgets and the incubator ones. Feedback would be much appreciated.
Thank you for your time.

Best regards,
Arthur Kalmenson
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---