Re: [gwt-contrib] Re: typo in documentation?
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 t.bro...@gmail.com 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?
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)
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, ncha...@google.com 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)
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, knor...@google.com 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)
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 unn...@google.com 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 title 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 arthur.k...@gmail.com 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 unn...@google.com 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 arthur.k...@gmail.com 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 unn...@google.com 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 arthur.k...@gmail.com 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, unn...@google.com 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
[gwt-contrib] expense isn't getting GWT RC1 release
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: repository idgwt-repo/id urlhttp://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven/url nameGoogle Web Toolkit Repository/name /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] Re: expense isn't getting GWT RC1 release
Just to confirm, changing the repository definition to: repository idgwt-repo/id urlhttps://oss.sonatype.org/content/repositories/google-snapshots/url nameGoogle Web Toolkit Repository/name /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 arthur.k...@gmail.com 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: repository idgwt-repo/id urlhttp://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven/url nameGoogle Web Toolkit Repository/name /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] Re: expense isn't getting GWT RC1 release
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 jlaba...@google.com 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 arthur.k...@gmail.com wrote: Just to confirm, changing the repository definition to: repository idgwt-repo/id urlhttps://oss.sonatype.org/content/repositories/google-snapshots/url nameGoogle Web Toolkit Repository/name /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 arthur.k...@gmail.com 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: repository idgwt-repo/id urlhttp://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven/url nameGoogle Web Toolkit Repository/name /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
Re: [gwt-contrib] Add Support for server side script selection in linker (issue941802)
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 unn...@google.com 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 arthur.k...@gmail.com 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, unn...@google.com 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)
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, unn...@google.com 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)
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 x...@google.com wrote:
On Wed, Aug 18, 2010 at 01:44, t.bro...@gmail.com 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. b foo=ishould be
bold would be sanitized to lt;b foo=ishould 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 b bold/b, 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(br/) will result in br/br
which is interpreted by browsers as brbr [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(a href=\{0}\)
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)
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, ncha...@google.com 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: [gwt-contrib] Public: Start of a sample application showing GWT validation. (issue760802)
Ah, sorry about that. -- Arthur Kalmenson On Tue, Aug 17, 2010 at 2:04 PM, Ray Ryan rj...@google.com 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 arthur.k...@gmail.com 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, ncha...@google.com 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)
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 arthur.k...@gmail.com wrote: Ah, sorry about that. -- Arthur Kalmenson On Tue, Aug 17, 2010 at 2:04 PM, Ray Ryan rj...@google.com 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 arthur.k...@gmail.com 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, ncha...@google.com 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] RR: What if UiBinder could take a factory?
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 rj...@google.com 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 UiBinderWithFactoryU, O, F extends UiBinderU, O {
/**
* Sets a factory to use when instantiating objects that are not
* provided via @UiFactory methods or @UiField(provided = true) fields.
* p
* 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.
* p
* 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 UiBinderWithFactoryWidget, 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
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?
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 ara...@gmail.com 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 UiBinderWithFactoryU, O, F extends UiBinderU, O {
/**
* Sets a factory to use when instantiating objects that are not
* provided via @UiFactory methods or @UiField(provided = true)
fields.
* p
* 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.
* p
* 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 UiBinderWithFactoryWidget,
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] Re: Add the ability to change the default HandlerManager of a Widget
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 itru...@gmail.com 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 rj...@google.com 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 jlaba...@google.com 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 sven.brun...@googlemail.com wrote: On 10 Feb., 16:28, Ray Ryan rj...@google.com 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 be able to change the default handlermanager (which is the goal in the end). On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call setHandlerManager with a new HandlerManager. If we dont check for a prior existing HandlerManager, all old HandlerRegistration's will be lost. If you dont know what happened, you will search forever why your old handlers are not working. You wont have the problem with a createHandlerManager method. On 9 Feb., 17:55, Ray Ryan rj...@google.com wrote: If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish
Re: [gwt-contrib] Announcing GWT 2.0.1
Great job! Some nice bug squishing. -- Arthur Kalmenson 2010/2/2 Miguel Méndez mmen...@google.com: 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)
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 rj...@google.com 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 rj...@google.com 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 ukcue...@gmail.com 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 ??
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 jarrod.carl...@gmail.com 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
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 david.no...@gmail.com 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 dilbert.elbo...@gmail.com 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 jlaba...@google.com 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 dilbert.elbo...@gmail.com 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 rj...@google.com 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. If the incubator is shut down how will we developers be able to find the new widgets and tools that are being incubated by Google developers? It is a bit hard to find them browsing trough Google code. I suggest that You put a couple of links in the Tools and Libraries section of gwt (http://code.google.com/webtoolkit/tools.html). It would be very helpful. Our intention is to be less bashful about developing things right in the trunk. Regards. -- 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] Re: now.. afetr GWT 2.0?
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 qcomps...@gmail.com 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] now.. afetr GWT 2.0?
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 br...@google.com wrote: Working on a draft one. What do folks here think is important? On Wed, Dec 16, 2009 at 7:42 AM, tfreitas tfrei...@gmail.com 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
[gwt-contrib] wrong DTD generated for modules in GEP
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] uibinder and bnudled CSS
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 nicolas.del...@gmail.com 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
Re: [gwt-contrib] Re: now.. afetr GWT 2.0?
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 konstantin.scheg...@gmail.com 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] Re: Problems with UiBinder Internals
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 rj...@google.com 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));
}
}
ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
ui:with field='paramValues' type='com.jarod.ParamValuesPojo'/
div
object classid=clsid:8AD9C840-044E-11D1-B3E9-00805F499D93
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
param name=code
value=org.jets3t.apps.uploader.Uploader.class /
param name=codebase value=. /
param name=archive
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 /
param name=type value=application/x-java-
applet;version=1.6 /
param name=scriptable value=false /
param name=mayscript value=false /
param name=uri value={paramValues.uri} /
param name=token value={paramValues.token} /
No Java Support.
/object
/div
/ui:UiBinder
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Inlining nocache.js
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 Braidcame...@braid.com.au wrote: I'd be keen to see this land in trunk ! Cam 2009/8/7 John Tamplin j...@google.com On Fri, Aug 7, 2009 at 3:51 AM, George Georgovassilis g.georgovassi...@gmail.com 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: Inlining nocache.js
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 Tamplinj...@google.com wrote: On Fri, Aug 7, 2009 at 9:43 AM, Arthur Kalmenson arthur.k...@gmail.com 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: UIBinder
Today sounds like it'll be the day we switch to trunk ;) -- Arthur Kalmenson On Tue, Aug 4, 2009 at 9:42 AM, Ray Ryanrj...@google.com 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 brett.wooldri...@gmail.com 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 rj...@google.com 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: [INFO] A new version of GWT (1.7.0) is available
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. Ridgeeeb...@gmail.com 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: Generalized RPC for server-enhanced objects
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, r...@google.com 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?
Finger slipped? :P On Jul 28, 8:15 pm, Scott Blum sco...@google.com wrote: Nothing to see here... move along please. On Tue, Jul 28, 2009 at 8:14 PM, Ray Cromwell cromwell...@gmail.com 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
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, dfloreydaniel.flo...@gmail.com 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: Continuous integration
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 loofnicolas.del...@gmail.com 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: Extracting feature
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 Osnatosnat.no...@gmail.com 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 j...@google.com 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 osnat.no...@gmail.comwrote: 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: naming runAsync calls
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 Braidcame...@braid.com.au 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 br...@google.com
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 came...@braid.com.au
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() { ... });
extend-configuration-property
name=compiler.splitpoint.initial.sequence value=MyModule#one /
extend-configuration-property
name=compiler.splitpoint.initial.sequence value=ThirdParty#one /
Cam
2009/6/25 Lex Spoon sp...@google.com
On Wed, Jun 24, 2009 at 2:15 PM, Lex Spoonsp...@google.com wrote:
Overall, unless I missed something,
Okay, Bruce pointed out a new constraint to me: if different libraries
name their runAsync calls, then we want to able to refer to those
calls reliably even if different libraries choose the same name. This
isn't an issue immediately, but it likely will be in the future.
Thinking about libraries, I would add another constraint: we don't
want libraries to have to expose their implementation. Library
writers should ideally be able to document a named runAsync call
without exposing the precise arrangement of their internal classes.
After some discussion at the office, a tweak to option 4
[gwt-contrib] Re: Java source transformation
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 cromwell...@gmail.com wrote:
On Tue, Apr 21, 2009 at 7:11 PM, Arthur Kalmenson arthur.k...@gmail.com
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 cromwell...@gmail.com 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
nicolas.del...@gmail.com wrote:
Sounds a good solution.
How would this solve the use case data returned by RPC call ?
2009/4/21 Ray Cromwell cromwell...@gmail.com
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
nicolas.del...@gmail.com 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.
If the generator enhanced class is used even when I use new Model()
or
get a Model bean from RPC, my code can be easily unit tested.
Cheers,
Nicolas
2009/4/21 Bruce Johnson br...@google.com
On Tue, Apr 21, 2009 at 12:38 PM, nicolas de loof
nicolas.del...@gmail.com wrote:
The only critism I'd have is the requirement to use GWT.create() to
get
code from
[gwt-contrib] Re: Java source transformation
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 nicolas.del...@gmail.com 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 cromwell...@gmail.com 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 nicolas.del...@gmail.com 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
Is the Google Eclipse Plugin not a Google Code OSS project? -- Arthur Kalmenson On Thu, Apr 16, 2009 at 11:18 PM, Alex Rudnick a...@google.com 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 miller.ga...@gmail.com 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
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 cromwell...@gmail.com 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 iamroberthan...@gmail.com 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
*jaw drops* -- Arthur Kalmenson On Wed, Apr 8, 2009 at 3:44 AM, stuckagain david.no...@gmail.com 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 br...@google.com 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
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 j...@google.com wrote: On Wed, Apr 1, 2009 at 10:22 PM, Vitali Lovich vlov...@gmail.com 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
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 br...@google.com wrote: Mind? Heck no! That would be great! On Wed, Feb 18, 2009 at 5:21 PM, Arthur Kalmenson arthur.k...@gmail.com 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: Associating Data Transfer Objects (DTOs) with Suggestion Objects
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 itru...@gmail.com 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 e...@google.com 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 rj...@google.com 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 e...@google.com wrote: It could work, though I found when I used this technique with DatePicker (DatePicker extends AbstractDatePickerMonthSelector, 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 rj...@google.com wrote: How about extracting a parameterized super class: AbstractSuggestionBoxT extends Suggestion SuggestionBox extends AbstractSuggestionBoxSuggestion rjrjr On Mon, Feb 23, 2009 at 7:15 PM, Emily Crutcher e...@google.com wrote: On Mon, Feb 23, 2009 at 7:04 PM, Isaac Truett itru...@gmail.com 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 on the subinterface. See http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user/client/ui/SuggestOracle.Suggestion.html (the 1.6 version is similar, but with the new event model) So the endorsed solution is to extend and cast. Fair enough. This probably dates from pre-1.5, and it was good enough for then. But is there a reason not to parameterize SuggestBox with T extends Suggestion (and SuggestOracleT, SelectionEventT, etc.) now that that's an option? Or perhaps make Suggestion implement HasValueT? I have an application that uses many SuggestBoxes and many different Suggestion subclasses and this would simplify things (and eliminate much type-casting). I'm not sure parameterizing SuggestBox itself would be worth it, as most people use it without creating new types of suggestions: so the parameterization would add clutter for the many and prevent casts for the few. Though, I completely agree it is annoying to have to cast. Perhaps we could create a composite-based CustomSuggestBox that is parameterized
[gwt-contrib] Re: Date Picker, multiple selected
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 tfrei...@gmail.com 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] testability of static methods
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] default GWT version in Maven central repo wrong
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
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 sco...@google.com 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=1q=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 module.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 Java code changes to take effect on the server without having to completely exit and restart hosted mode. This is useful when making code changes to RPC servlets, or when serializable RPC types are modified and the server and client are out of sync. *** New EventHandler System *** Event handlers have been added to replace the old event listeners used by Widgets, History, and various other classes. The new system has a few differences
[gwt-contrib] CSS for ScrollTable out of date
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
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 jan.vorw...@googlemail.com 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
replace-with class=MyDOMImplMozilla
when-type-is class=com.google.gwt.user.client.impl.DOMImpl/
when-property-is name=user.agent value=gecko1_8/
/replace-with
Many thanks in advance
Best regards
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Call for critical 1.6 bugs
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 omod...@gmail.com 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 cromwell...@gmail.com 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 sco...@google.com 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=2q=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: Panel loading one by one
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 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. ThanksRegards, Ravindra --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: 1.6 date picker question
I look forward to it! -- Arthur Kalmenson On Thu, Jan 8, 2009 at 3:40 PM, Isaac Truett itru...@gmail.com 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 e...@google.com 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 e...@google.com 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 e...@google.com wrote: Yep, sounds right, thanks! On Thu, Dec 4, 2008 at 6:53 PM, Isaac Truett itru...@gmail.com 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 e...@google.com wrote: That sounds great, thanks. On Thu, Dec 4, 2008 at 10:31 AM, Isaac Truett itru...@gmail.com 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 e...@google.com 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 arthur.k...@gmail.com 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 jlaba...@google.com 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 jlaba...@google.com On Mon, Dec 1, 2008 at 9:41 AM, Arthur Kalmenson arthur.k...@gmail.com 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 -- 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 -- 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: Any objections to 1.5-final gwt-incubator drop going out this week?
Sounds good to me. -- Arthur Kalmenson On Wed, Dec 17, 2008 at 10:25 AM, Emily Crutcher e...@google.com 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
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 HasValueT interface to implement it. It seems to work pretty well at the moment. Having most of the Widgets implement HasValueT would really help us clean up the code. Perhaps CheckBox should implement HasValueT 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 rj...@google.com wrote: Well put, RayC, thanks. MVC is exactly the intended point of HasValue. (Freeland, John, it's HasValueT, 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 cromwell...@gmail.com 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 HasValueUSPostalAddress. 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 HasValueTableModel or HasValueTableData, 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 itru...@gmail.com 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 j...@google.com wrote: On Thu, Dec 11, 2008 at 2:20 PM, Freeland Abbott gwt.team.fabb...@gmail.com 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 suggested resolution for him. He grumbled (but it 'is-a' TextBox, that should be extends), but conceded. However, the old HasValue is not parameterized, and implies something has *string* value, period. As applied to CheckBox, that's confusing-to-wrong. Isaac is correct that we can resolve this by making CheckBox not a HasValue, and keep the interface... but the discussion makes me think that HasValueT has merit, and for example a CheckBox would be HasValueBoolean and a TextBox would be HasValueString (my friend should still make Composites
[gwt-contrib] Re: 1.6 date picker question
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
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: RR: Adding .project to gwt-incubator root directory
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: please solve this prob ..
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
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
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
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
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: Flurry of Data binding threads
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] Re: data binding framework for GWT
Hi Ian, I *think* validation could be tied into the data binding framework in a pretty straightforward way by extending EditorT and ViewerT 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 EditorT and ViewerT to be validation-aware. At the moment, ViewerT and EditorT 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, ViewerT (and, by extension, EditorT) 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 perform validation at that time, you have access to the editor that changed, the bean that's (in)valid, the property that's (in)valid, and the validation state. You could probably give very rich feedback to the user about that particular property, and there are a number of rational ways to handle an invalid value. Handling multi-property validation is a little more complex but, assuming the validation
[gwt-contrib] Re: data binding framework for GWT
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: Incubator review request: HasValue
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 threadhttp://groups.google.com/group/Google-Web-Toolkit-Contributors/browse 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: updates and design changes to incubator validation
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] RR: making extracting and setting widget data easier
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 DataManagerT, S {
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
DataManagerTextBoxBase, String {
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
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: making extracting and setting widget data easier
If you buy my argument that HasDataT needs to imply SourcesDataChangeEventsT, then I think it follows that Label should not implement HasDataT. Something like HasReadOnlyDataT (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 HasDataT and HasReadOnlyDataT is a great idea. Implementing some SourcesDataChangeEventsT 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 HasDataBoolean? To me, a collection of RadioButtons is roughly equivalent to a single-select ListBox and, as such, RadioButton implementing HasDataBoolean is somewhat nonsensical, whereas a collection of RadioButtons should probably implement HasDataString, or something similar. I agree, it should be HasDataString, 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 HasDataString? Yes. HasDataString would essentially replace HasText, wouldn't it? (As an aside, if HasDataString replaces HasText, perhaps HasText should be redefined to extend HasDataString.) Ray talked about creating a uniform way to find out what value a widget is showing and Isaac described HasDataT as a tool for normalizing API. I think those are key ideas. As such, I think we need to go one step further. HasDataT should imply SourcesChangeEvents, or maybe SourcesDataChangeEventsT. A TextBox certainly HasDataString, 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 SourcesDataChangeEventsBoolean. If you buy my argument that HasDataT needs to imply SourcesDataChangeEventsT, then I think it follows that Label should not implement HasDataT. Something like HasReadOnlyDataT (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 HasDataBoolean? To me, a collection of RadioButtons is roughly equivalent to a single-select ListBox and, as such, RadioButton implementing HasDataBoolean is somewhat nonsensical, whereas a collection of RadioButtons should probably implement HasDataString, or something similar. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
