[gwt-contrib] Re: Which API for a future, modern JSON library?
Out of curiosity, why not use the org.json API? jay On Monday, December 11, 2017 at 8:13:40 AM UTC-8, Thomas Broyer wrote: > > > > On Monday, December 11, 2017 at 4:01:41 PM UTC+1, Colin Alworth wrote: >> >> Thanks Thomas, I'm excited to see where this will lead. >> >> Can you talk a little more about plans POJO support, as none of the three >> existing options have any? Would you envision a wrapping tool that looks >> like AutoBean/gwt-jackson, and where on that continuum are you thinking >> (autobean is as late as possible, and generic enough to handle xml or other >> underlying data formats, gwt-jackson parses then copies all json tree nodes >> directly to bean values)? I also know there have been some experiments >> around passing a reviver func to JSON.parse that could be interesting here. >> Any thoughts on handling collections, whether to go with java.util, or try >> for something shared js/jvm and only used within this library? >> > > No plan. at all. really. > Might even never be in scope. > > What would look the closest to a plan would be to somehow expose the "raw" > objects so you could "cast" them to jsinterop native types (collections are > an issue there). And by using an API like " T cast(Class clazz)", a > JVM adapter could use its own logic to do the mapping into new objects > (note that JS and JVM would have different behavior wrt updating the > objects) Raw objects could possibly also be fed into "wrappers" like > AutoBeans (btw, if it weren't for the –understandable– JsInterop limitation > that a native type cannot implement/extend a non-jstype interface, > AutoBeans would probably not have to be wrappers, but only native or > overlay methods and WeakMap > <https://kangax.github.io/compat-table/es6/#test-WeakMap> for reified > types; if the "schema" wasn't the Java interface you actually use in your > code, those could easily be generated). > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/26f089cc-0eca-42ea-b14d-a236bd6848aa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7.0-RC1 is available
I'll give that a try... Will the issue be handled before the final release? jay On Thursday, October 30, 2014 11:47:54 AM UTC-7, Roberto Lublinerman wrote: There seems that some assertions in UnifyAST are not being satisfied in incremental SDM but it runs fine (and correctly) if you turn off assertions. On Wed, Oct 29, 2014 at 10:53 PM, jay j...@thegindins.com javascript: wrote: I grabbed the RC and switched to use it from my IntelliJ project. When starting my run configuration using SDM, all seems well until the compiler dies (see below). What can I do to provide more information to help track this down? (Sorry, I cannot make the code available...) // Lots and lots of: // Resolving ... //Found type '' // Resolving method ... Finding entry point classes Assimilating generated source Generated source files... com.google.gwt.lang.com_00046ao_00046foo_ 00046MyGwtModule_00045DEV__EntryMethodHolder Adding '1' new generated units Compiling... Compilation completed in 0.00 seconds Added 1 units to cache since last cleanup. Removing invalidated units Wrote 1 units to persistent cache. [ERROR] Unexpected internal compiler error java.lang.AssertionError at com.google.gwt.dev.jjs.impl.UnifyAst.instantiate(UnifyAst.java:1407) at com.google.gwt.dev.jjs.impl.UnifyAst.instantiate(UnifyAst.java:1414) at com.google.gwt.dev.jjs.impl.UnifyAst.instantiate(UnifyAst.java:1414) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java: 1186) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst. java:1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java: 1595) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1733) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1747) at com.google.gwt.dev.jjs.impl.UnifyAst.flowInto(UnifyAst.java:1226) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java: 1191) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst. java:1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java: 1595) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1733) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1747) at com.google.gwt.dev.jjs.impl.UnifyAst.flowInto(UnifyAst.java:1226) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java: 1191) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst. java:1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java: 1595) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst. java:1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java: 1595) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1733) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1747) at com.google.gwt.dev.jjs.impl.UnifyAst.flowInto(UnifyAst.java:1206) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java: 1188) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst. java:1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java: 1595) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst. java:1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java: 1595) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst. java:1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java: 1595) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst. java:1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java: 1595) at com.google.gwt.dev.jjs.impl.UnifyAst.translate
[gwt-contrib] Re: GWT 2.7.0-RC1 is available
I grabbed the RC and switched to use it from my IntelliJ project. When starting my run configuration using SDM, all seems well until the compiler dies (see below). What can I do to provide more information to help track this down? (Sorry, I cannot make the code available...) // Lots and lots of: // Resolving ... //Found type '' // Resolving method ... Finding entry point classes Assimilating generated source Generated source files... com.google.gwt.lang. com_00046ao_00046foo_00046MyGwtModule_00045DEV__EntryMethodHolder Adding '1' new generated units Compiling... Compilation completed in 0.00 seconds Added 1 units to cache since last cleanup. Removing invalidated units Wrote 1 units to persistent cache. [ERROR] Unexpected internal compiler error java.lang.AssertionError at com.google.gwt.dev.jjs.impl.UnifyAst.instantiate(UnifyAst.java:1407) at com.google.gwt.dev.jjs.impl.UnifyAst.instantiate(UnifyAst.java:1414) at com.google.gwt.dev.jjs.impl.UnifyAst.instantiate(UnifyAst.java:1414) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java:1186 ) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1733) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1747) at com.google.gwt.dev.jjs.impl.UnifyAst.flowInto(UnifyAst.java:1226) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java:1191 ) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1733) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1747) at com.google.gwt.dev.jjs.impl.UnifyAst.flowInto(UnifyAst.java:1226) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java:1191 ) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1733) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1747) at com.google.gwt.dev.jjs.impl.UnifyAst.flowInto(UnifyAst.java:1206) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java:1188 ) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at
[gwt-contrib] Re: Quarterly Hangouts On Air
I'll speak up in favor! I'm sure we'd get a number of folks from my company who would be very interested in listening if not actively participating. jay On Sunday, January 26, 2014 12:41:40 PM UTC-8, James Nelson wrote: Hi all, I am just wondering if it would be possible to setup a quarterly QA hangout-on-air with steering committee members taking questions from the public, and presenting on ideas that are in the works for GWT. It would be similar to the panel held at GWT.create, except we could collect up the questions via Google Moderator over the coming months, to give panel members time to discuss and decide on answers. If possible, I would like to get a few RSVPs before mentioning it at the community hangout; we could schedule the first QA panel for the end of March, and post the moderator tomorrow to get people started on the questions. Thanks, James -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Cannot build any project since 5a972863
I'll try over the weekend to come up with a repro project. While I'm working on that, is there anything I can look for in the compiler? I'm able to build and use my locally built GWT compiler, so it's easy to stick in some debug statements and inspect what's going on. thanks, jay On Thursday, January 23, 2014 9:30:40 AM UTC-8, Roberto Lublinerman wrote: The bug in the post is not due to the issue being discussed in the thread. If you can attach a small project that repros the bug you are getting, I'll take a look. Best, Roberto. On Wed, Jan 22, 2014 at 10:30 PM, jay jay.g...@gmail.com javascript:wrote: I realize that about the only thing in common is that the GWT compiler is throwing an NPE, but I have to ask... Is there any chance that this issue has the same root cause as the NPE I reported in this posthttps://groups.google.com/forum/#!topic/google-web-toolkit-contributors/1vA7gYrCjvo and this bughttps://code.google.com/p/google-web-toolkit/issues/detail?id=8536 ? thanks, jay On Wednesday, January 22, 2014 11:43:22 AM UTC-8, Andrés Testi wrote: Thanks! - Andrés Testi El miércoles, 22 de enero de 2014 16:39:45 UTC-3, John Stalcup escribió: Yeah. It seems that CompilePermsServer doesn't have a ModuleDef instance, so it's not populating compilerContext.getModule(), which laters causes compilerContext.getModule().isMonolithic() to fail. I'm working on a fix. On Wed, Jan 22, 2014 at 11:26 AM, Andrés Testi andres@gmail.comwrote: Hi John: I'm running ant without explicit target (build by default). No explicit flags. I got the same exception in two isolated environments (ubuntu 13.10 with OpenJDK, and Windows 8 with Oracle JDK). The exception is throwed when the script tries to compile the DynaTable sample. CompilerContext.getModule() seems to return null here: https://github.com/gwtproject/gwt/blob/master/ dev/core/src/com/google/gwt/dev/jjs/UnifiedAst.java#L137 - Andrés Testi El miércoles, 22 de enero de 2014 15:45:35 UTC-3, John Stalcup escribió: Yeah that does look to be related to my commit. Which compiler entry point are you launching and with what flags? I updated Compiler.java, CompilePerms.java, etc etc to property setup the module property of the compilerContext object, but it looks like I missed somewhere. John On Wed, Jan 22, 2014 at 4:07 AM, Honza Rameš ram...@gmail.comwrote: Hello everyone, I'm using master for my projects and after I updated to commit 5a972863 (Added monolithic/separate branching to JavaToJavaScriptCompiler) suddenly I wasn't able to compile any of my GWT projects (in Eclipse, see error message bellow). I'm using jdk_1.7 and older commit (8ef35362) works just fine. Did any of you encountered build breakage recently, is there some workaround you know of? DevMode works OK with this commit. I have Eclipse 3.7 and GPE 3.5.1. While compiling simple project I noticed that some of the permutations compile just fine. Could this be caused by IE6 permutation, I do have some deferred binding rules in my module targeting the IE6. Error messge: [ERROR] Compile failed java.lang.NullPointerException at com.google.gwt.dev.jjs.Unified Ast.compilePermutation(UnifiedAst.java:137) at com.google.gwt.dev.CompilePerms.compile( CompilePerms.java:196) at com.google.gwt.dev.CompilePermsServer. compilePermutation(CompilePermsServer.java:307) at com.google.gwt.dev.CompilePermsServer.run( CompilePermsServer.java:274) at com.google.gwt.dev.CompilePermsServer.main( CompilePermsServer.java:237) [ERROR] Error from external worker java.lang.NullPointerException at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(Unified Ast.java:137) at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java: 196) at com.google.gwt.dev.CompilePermsServer.compilePermutation(Com pilePermsServer.java:307) at com.google.gwt.dev.CompilePermsServer.run(CompilePermsServer .java:274) at com.google.gwt.dev.CompilePermsServer.main(CompilePermsServe r.java:237) [ERROR] Unrecoverable exception, shutting down com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.ExternalPermutationWorkerFactory$ ExternalPermutationWorker.compile(ExternalPermutationWorkerFacto ry.java:156) at com.google.gwt.dev.PermutationWorkerFactory$Manager$ WorkerThread.run(PermutationWorkerFactory.java:73) at java.lang.Thread.run(Thread.java:744) Any help would be appreciated. Regards Honza Rames -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@ googlegroups.com. For more
Re: [gwt-contrib] Cannot build any project since 5a972863
I realize that about the only thing in common is that the GWT compiler is throwing an NPE, but I have to ask... Is there any chance that this issue has the same root cause as the NPE I reported in this posthttps://groups.google.com/forum/#!topic/google-web-toolkit-contributors/1vA7gYrCjvo and this bughttps://code.google.com/p/google-web-toolkit/issues/detail?id=8536 ? thanks, jay On Wednesday, January 22, 2014 11:43:22 AM UTC-8, Andrés Testi wrote: Thanks! - Andrés Testi El miércoles, 22 de enero de 2014 16:39:45 UTC-3, John Stalcup escribió: Yeah. It seems that CompilePermsServer doesn't have a ModuleDef instance, so it's not populating compilerContext.getModule(), which laters causes compilerContext.getModule().isMonolithic() to fail. I'm working on a fix. On Wed, Jan 22, 2014 at 11:26 AM, Andrés Testi andres@gmail.comwrote: Hi John: I'm running ant without explicit target (build by default). No explicit flags. I got the same exception in two isolated environments (ubuntu 13.10 with OpenJDK, and Windows 8 with Oracle JDK). The exception is throwed when the script tries to compile the DynaTable sample. CompilerContext.getModule() seems to return null here: https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/dev/jjs/UnifiedAst.java#L137 - Andrés Testi El miércoles, 22 de enero de 2014 15:45:35 UTC-3, John Stalcup escribió: Yeah that does look to be related to my commit. Which compiler entry point are you launching and with what flags? I updated Compiler.java, CompilePerms.java, etc etc to property setup the module property of the compilerContext object, but it looks like I missed somewhere. John On Wed, Jan 22, 2014 at 4:07 AM, Honza Rameš ram...@gmail.com wrote: Hello everyone, I'm using master for my projects and after I updated to commit 5a972863 (Added monolithic/separate branching to JavaToJavaScriptCompiler) suddenly I wasn't able to compile any of my GWT projects (in Eclipse, see error message bellow). I'm using jdk_1.7 and older commit (8ef35362) works just fine. Did any of you encountered build breakage recently, is there some workaround you know of? DevMode works OK with this commit. I have Eclipse 3.7 and GPE 3.5.1. While compiling simple project I noticed that some of the permutations compile just fine. Could this be caused by IE6 permutation, I do have some deferred binding rules in my module targeting the IE6. Error messge: [ERROR] Compile failed java.lang.NullPointerException at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation( UnifiedAst.java:137) at com.google.gwt.dev.CompilePerms.compile( CompilePerms.java:196) at com.google.gwt.dev.CompilePermsServer. compilePermutation(CompilePermsServer.java:307) at com.google.gwt.dev.CompilePermsServer.run( CompilePermsServer.java:274) at com.google.gwt.dev.CompilePermsServer.main( CompilePermsServer.java:237) [ERROR] Error from external worker java.lang.NullPointerException at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation( UnifiedAst.java:137) at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:196) at com.google.gwt.dev.CompilePermsServer.compilePermutation( CompilePermsServer.java:307) at com.google.gwt.dev.CompilePermsServer.run( CompilePermsServer.java:274) at com.google.gwt.dev.CompilePermsServer.main( CompilePermsServer.java:237) [ERROR] Unrecoverable exception, shutting down com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.ExternalPermutationWorkerFacto ry$ExternalPermutationWorker.compile(ExternalPermutationWorkerFacto ry.java:156) at com.google.gwt.dev.PermutationWorkerFactory$ Manager$WorkerThread.run(PermutationWorkerFactory.java:73) at java.lang.Thread.run(Thread.java:744) Any help would be appreciated. Regards Honza Rames -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@ googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from
[gwt-contrib] Errors building with GWT 2.6.0-rc4
We have a number of JavaScriptObject subclasses. As I'm testing out
2.6.0-rc4, I'm getting an NPE from the compiler. (GWT 2.5.1 works without
any issue on our code base.)
I've attached a file with the full error, but here's an excerpt:
Caused by: java.lang.NullPointerException
at com.google.gwt.dev.js.JsInliner.isFunction(JsInliner.java:1999)
at com.google.gwt.dev.js.JsInliner.access$300(JsInliner.java:87)
at
com.google.gwt.dev.js.JsInliner$RecursionCollector.endVisit(JsInliner.java:1608)
at com.google.gwt.dev.js.ast.JsInvocation.traverse(JsInvocation.java:73)
at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:468)
... 23 more
[ERROR] at ApplicationJSO.java(100): this.getManifest()
com.google.gwt.dev.js.ast.JsInvocation
[ERROR] at ApplicationJSO.java(100): return this.getManifest()
com.google.gwt.dev.js.ast.JsReturn
[ERROR] at ApplicationJSO.java(99): {
return this.getManifest();
}
com.google.gwt.dev.js.ast.JsBlock
[ERROR] at ApplicationJSO.java(99): function getManifest(){
return this.getManifest();
}
com.google.gwt.dev.js.ast.JsFunction
[ERROR] Unrecoverable exception, shutting down
The particular class it's failing on has JSNI methods such as:
@Override
public final native Manifest getManifest() /*-{
return this.getManifest();
}-*/;
All of these JSO classes implements interfaces, which the rest of our
application uses.
I rebuilt GWT and added a bit of debugging code. What I determined is that
on line 1999 of JsInliner, the ref.getName() is returning null. In that
same debugging code, I printed out ref.toSource(true) which shows this:
this.getManifest
I also verified that ref.getIdent() is *not* null.
I'd be quite happy to add any more debugging statements necessary, apply
patches, whatever to get this fixed *before* 2.6.0 goes out for real.
FWIW, I've tried building a small sample app to demonstrate the issue, but
I have not yet been able to narrow it down. My quick attempt worked just
fine :-(
Thanks,
Jay
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Compiling module com.gindin.foo.bar.Showcase
Computing all possible rebind results for
'com.gindin.apps.blega.client.ui.stuff.client.view.a.b.C.D'
Rebinding com.gindin.apps.blega.client.ui.stuff.client.view.a.b.C.D
Invoking generator
com.google.gwt.safehtml.rebind.SafeHtmlTemplatesGenerator
Constructing interface
com.gindin.apps.blega.client.ui.stuff.client.view.a.b.C.D
Generating method body for img()
Template with variable in URL attribute context: The template
code generator will sanitize the URL. Use SafeUri to specify arguments in a
URL attribute context that should not be sanitized.
Compiling 3 permutations
Compiling permutation 1...
Process output
Compiling
Compiling permutation 2...
Process output
Compiling
Compiling permutation 0...
[ERROR] An internal compiler exception occurred
com.google.gwt.dev.jjs.InternalCompilerException: Unexpected error during visit.
at
com.google.gwt.dev.js.ast.JsVisitor.translateException(JsVisitor.java:483)
at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:470)
at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:445)
at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:109)
at com.google.gwt.dev.js.ast.JsReturn.traverse(JsReturn.java:51)
at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:468)
at
com.google.gwt.dev.js.ast.JsVisitor.doAcceptWithInsertRemove(JsVisitor.java:462)
at
com.google.gwt.dev.js.ast.JsVisitor.acceptWithInsertRemove(JsVisitor.java:121)
at com.google.gwt.dev.js.ast.JsBlock.traverse(JsBlock.java:48)
at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:468)
at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:445)
at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:109)
at com.google.gwt.dev.js.ast.JsFunction.traverse(JsFunction.java:202)
at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:468)
at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:445)
at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:109)
at com.google.gwt.dev.js.JsInliner.execImpl(JsInliner.java:1846)
at com.google.gwt.dev.js.JsInliner.exec(JsInliner.java:1787)
at
com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimizeJs
[gwt-contrib] Re: Jetty 9
What you're describing is pretty much what we're doing. The issue comes up when we change a piece of shared code, like a DTO. What we've found is that if we don't stop, recompile from the command line (including gwt compile) the updated DTO can't be sent/received...the GWT-RPC stuff doesn't match up any more and we get failures. Maybe what you're suggesting is that we're doing something wrong? I'd *love* to just do one gwt compile *ever* and have the right bootstrap files in place. How do we handle the GWT-RPC serialization policies? thanks, jay On Wednesday, November 20, 2013 12:56:17 AM UTC-8, Thomas Broyer wrote: You only need to gwt compile once, then just run DevMode. Ideally, you'd point DevMode's -war at the location Jetty loads your webapp (so, deploy an exploded WAR, or point -war to the location Jetty exploded the WAR in the temp folder) so that all the static files it generates (ExternalTextResource; other resources when not inlined for whichever reason, ImageBundle if you still use them; and GWT-RPC serialization policies) can be found by Jetty / your webapp. In many situations, when working on client-only code (UI code, mostly), I just run DevMode in -noserver mode with -startupUrl pointing at our test server (where our CI server deploys the app). Otherwise, we use a local Jetty server and configure it to load the webapp right from our Maven's target/ folders; that way redeploying is just a matter of re-compiling the Java classes (done automatically by Eclipse anyway, but otherwise mvn package -Dgwt.compiler.skip does the job without recompiling the GWT client-side code), and with DevMode you never need to redeploy the client-side code. On Tuesday, November 19, 2013 9:39:29 PM UTC+1, jay wrote: We have some requirements which have forced us to run our own Jetty server. This means we're debugging with the --noserver flag. The problem with this is the amount of time it takes to do a command line build (and deploy) and then run the debugger. And, of course, if your command line compile doesn't include the right permutation, you get to do it all over again. My question is if someone can point us at how we can use our Jetty process, but hook up the GWT dev mode magic so we can just fire up the debugger and go. Thanks, jay -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Jetty 9
We have some requirements which have forced us to run our own Jetty server. This means we're debugging with the --noserver flag. The problem with this is the amount of time it takes to do a command line build (and deploy) and then run the debugger. And, of course, if your command line compile doesn't include the right permutation, you get to do it all over again. My question is if someone can point us at how we can use our Jetty process, but hook up the GWT dev mode magic so we can just fire up the debugger and go. Thanks, jay -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Regarding Issue 1601804: Fix leak in LayoutImplIE6
Anyone have any pointers to offer? thanks, jay On Sunday, September 16, 2012 3:14:17 PM UTC-7, jay wrote: (I seem to be unable to post this comment to the code review...) In regards to the code review posted at http://gwt-code-reviews.appspot.com/1601804, I would love to see this land in 2.5, as we have some large customers who are still using IE7. And, no surprise, we're having some memory issues... Unfortunately, when I applied this patch to our code base, part of our app failed to render. The problem seems to be in the LayoutImplIE6 class, though I'm not sure exactly what's going wrong. Clearly the DOM is generated differently, and that's expected. If someone can provide a pointer or some more details on how the layers are supposed to be used in the onAttach now vs. previously, I will try to take a look and get a better understanding of what's going wrong. Thanks, jay -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Regarding Issue 1601804: Fix leak in LayoutImplIE6
(I seem to be unable to post this comment to the code review...) In regards to the code review posted at http://gwt-code-reviews.appspot.com/1601804, I would love to see this land in 2.5, as we have some large customers who are still using IE7. And, no surprise, we're having some memory issues... Unfortunately, when I applied this patch to our code base, part of our app failed to render. The problem seems to be in the LayoutImplIE6 class, though I'm not sure exactly what's going wrong. Clearly the DOM is generated differently, and that's expected. If someone can provide a pointer or some more details on how the layers are supposed to be used in the onAttach now vs. previously, I will try to take a look and get a better understanding of what's going wrong. Thanks, jay -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] 2 questions about TabBar internals
While debugging my code I ran across two things within the TabBar class that I seemed strange... (Line numbers are from svn 8960.) 1. com.google.gwt.user.client.ui.TabBar.ClickDelegatePanel#onBrowserEvent -- There's a comment on line 149: // No need for call to super., and yet there *is* a call to super.onBrowserEvent. I assume the comment should be deleted? 2. com.google.gwt.user.client.ui.TabBar#TabBar -- Line 201 is first.setHeight(100%); and guess what's on line 206? The same thing! I'm guessing one of these is not necessary. Thanks, jay -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] GWT 2.0.3 Compiler Bug?
I have a static method which I use, periodically, to ensure that a
popup panel has a zIndex which is (practically) guaranteed to be on
top of everything else. (And yes, I'm sure there's another way, using
pure CSS to do this, but never mind that for the moment ;-)
This class looks something like this:
public class ZIndexHelpers {
private static final int
TOPMOST_Z_INDEX = 2004318071;
public static void makeTopmost( Element elem ) {
setZIndex( elem, TOPMOST_Z_INDEX );
}
public static void setZIndex(Element elem, int index) {
elem.getStyle().setZIndex( index );
}
}
By running the compiler with -style=DETAILED, I can see that where I'm
calling the makeTopmost() method, it gets turned into some inlined
code. E.g.,
this
$static.com_gindin_client_utils_ui_dropdown_DropDown_dropDown.com_google_gwt_user_client_ui_UIObject_element.style[$intern_94]
= $intern_3318;
Looking in the generated JavaScript, I can see:
* $intern_94 = 'zIndex'
* $intern_3318 = '2.004318071E9'
Putting the pieces together, this means that the resulting JavaScript
is gonig to be something like:
elem.style[ 'zIndex' ] = '2.004318071E9'
Well, this doesn't work :-(
My work-around is to:
1. Declare:
private static final String
TOPMOST_Z_INDEX_STR = + TOPMOST_Z_INDEX;
2. Change my makeTopmost() method to just the single line:
elem.getStyle().setProperty( zIndex, TOPMOST_Z_INDEX_STR );
My question is: Is this a compiler bug? Or is it just a gosh, yeah,
that's what we do, so uh...be careful ;-)
FWIW, this exact same code was working just fine with GWT 1.7...
Thanks,
jay
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
To unsubscribe, reply using remove me as the subject.
[gwt-contrib] Re: GWT 2.0.3 Compiler Bug?
I'll see if I can whittle things down to a manageable sample app. On Apr 8, 8:01 am, Lex Spoon sp...@google.com wrote: Hey, Jay, I haven't replicated the problem using your example, but I think I see the bug anyway. There is an optimization to simplify at compile time expressions like 2004318071+'', and it is converting the number part to a string using the equivalent of Double.toString. That is where the scientific notation comes from. However, a real JSVM apparently has a different algorithm for turning a number into a string. I'll work on the JsStaticEval bug. Here's an issue for it: http://code.google.com/p/google-web-toolkit/issues/detail?id=4830 Jay, if you can minimize the problem down to something I can replicate, I can test that it is in fact the problem you are seeing. Alternatively, have you ever built and used GWT from trunk? IF so, you could verify the fix once it's committed. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe, reply using remove me as the subject.
[gwt-contrib] Re: GWT Incubator compatibility policy
So...as of right now, what is the *last* version of gwt-incubator that is guaranteed to work with GWT 1.7? Is it safe to assume that it is the version immediately prior to the removal of StyleInjector? thanks, jay On Sep 10, 8:28 am, Isaac Truett itru...@gmail.com wrote: [oops - +gwtc] Hi, Ray, I appreciate the drive to move forward and I applaud jumping on opportunities to remove redundant code. The reason this policy was important, to me at least, is that it provided a baseline to work against. The code in the incubator can be very useful (I use PagingScrollTable extensively and used DatePicker from incubator before it graduated) but it's also risky because the code is still experimental and subject to change. The assurance that those changes would be compatible with a packaged and released GWT build (even just a milestone) meant that I could build incubator from trunk and pick up the latest features and bugfixes as long as my project tracked the latest GWT build. Because of the GWT policies on deprecation and backwards compatibility, this has been fairly easy in practice. As it stands now, incubator will not compile except against GWT trunk, which is also notoriously unstable (it wasn't building as recently as last night, which I see was corrected this morning). This presents a much higher risk for those of us using incubator code. It also becomes harder to work on the incubator itself when it has to compile against GWT trunk. I wanted to look into issue #267 last night and I was stymied by GWT trunk not being in a buildable state. Not an insurmountable obstacle, but one that seems unnecessary to me. - Isaac On Thu, Sep 10, 2009 at 11:03 AM, Ray Ryan rj...@google.com wrote: Hey, Isaac. That policy has proven very difficult to live with. (And to tell you the truth I forgot about it.) The reasoning here was that we have released incubator jars that work with 1.7 and no plans to issue further ones before 2.0 MS1 lands. Should it prove necessary to go back and do so we can go back and branch. In the meantime, we were faced bugs due to FastTree in particular being tied to the old StyleInjector while new development was moving to the version in GWT. We saw the opportunity to delete redundant code and took it. Is this going to cause problems for anyone? rjrjr On Wed, Sep 9, 2009 at 3:26 PM, Isaac Truett itru...@gmail.com wrote: Last year, Emily stated that it would compile against the latest gwt-milestone and gwt-trunk. There hasn't been a 2.0 milestone that I've seen, so under the policy from last year StyleInjector should not have been removed in revisions 1712-1715. So, what's the current policy for incubator trunk compatibility? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Locking Columns in PagingScrollTable
What branch and what functionality have you already added? jay On Jul 28, 1:44 am, dflorey daniel.flo...@gmail.com wrote: I'm not sure about the current status of when things will proceed and move to trunk, but I'd like to see this feature in the core table framework! If you have some patches, I can of course add them to my branch as I've already added some functionality to the tables and at least try to merge back the incubator trunk into my branch from time to time. This is how I'd implement this feature (just brainstorming): Add another table to the ScrollTable (copypaste the code from creating the header table). The width of the header table columns has to be kept in sync manually when the content of the data table changes. So you should grab the same events and sync the height of the rows of your fixedColumnTable. It would be cool if there would be a way to define the fixed property in the CoumnDefinition. The is already a bunch of classes for each column property so it does not harm to introduce another one ;-) Check for the fixed property when constructing the table and add additional tables for fixed columns not next to each other and recalc the column index to populate the proper tables when populating data. Finally we would end up with a dynamic number of data tables (think of a table with a fixed first and last column = 3 data tables) that all have to be kept in sync regarding row height. On Jul 28, 7:35 am, jay jay.gin...@gmail.com wrote: I'm about to embark on coming up with a way to lock 1 or more of the left-most columns. E.g., the locked columns will not scroll horizontally as the other columns are scrolled. I've googled around, and not found any other work towards this, so I'm hoping it's not impossible. Currently, I'm using the PagingScrollTable... My first thought is that I would create a wrapper that would internally separate the TableModel into two, and create two separate PagingScrollTable instances, smushed side-by-side. However, if I do this, one thing I really am unsure of is how to keep the height of each row in sync? I appreciate any hints, tips, and/or tricks! jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Locking Columns in PagingScrollTable
I'm about to embark on coming up with a way to lock 1 or more of the left-most columns. E.g., the locked columns will not scroll horizontally as the other columns are scrolled. I've googled around, and not found any other work towards this, so I'm hoping it's not impossible. Currently, I'm using the PagingScrollTable... My first thought is that I would create a wrapper that would internally separate the TableModel into two, and create two separate PagingScrollTable instances, smushed side-by-side. However, if I do this, one thing I really am unsure of is how to keep the height of each row in sync? I appreciate any hints, tips, and/or tricks! jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
I was under the impression (based on conversations with GWT team members) at Google I/O in May), that moving this into trunk for 2.0 was a sure thing. Has something changed? I'll live if this has changed, I'd just like to know. Please...keep us informed... thanks, jay On Jul 16, 8:07 am, Isaac Truett itru...@gmail.com wrote: Issue #188 has 40 stars, making it number seven in the issue list (when sorted appropriately). Let's shoot for number one before John gets back to working on it. ;-) So if you're anxious for PST to leave the incubator, star this issue:http://code.google.com/p/google-web-toolkit/issues/detail?id=188 - Isaac On Thu, Jul 16, 2009 at 10:58 AM, John LaBancajlaba...@google.com wrote: We probably won't decide what to move into trunk until we get closer to the next release. I'm working on improving our unit test coverage to make GWT more stable, and most of the other UI developers are busy on their own tasks. Sorry I don't have a better answer, but I'll escalate the fact that quite a few people have been asking about the table and would like to see it in trunk. Thanks, John LaBanca jlaba...@google.com On Wed, Jul 15, 2009 at 6:31 PM, jay jay.gin...@gmail.com wrote: Bump again? Any status? thanks... jay On Jul 7, 8:40 am, jay jay.gin...@gmail.com wrote: bump. Anything? On Jun 24, 10:31 am, jay jay.gin...@gmail.com wrote: Just curious if the effort has been resumed? Regardless, is there anyway for you to commit what you do have somewhere we could look and provide feedback? thanks, jay On Jun 10, 8:28 am, John LaBanca jlaba...@google.com wrote: @jay - I got side tracked with other tasks, but I'll pick up the PagingScrollTable effort within a couple of weeks. The main goal when we transfer the PagingScrollTable to GWT trunk is to separate the concept of scrolling (with three distinct tables) from the rest of the code. That way, we can bulk render a single table element that includes the header,data, and footer and have it layout naturally. @dflorey - I definitely plan to include all three of your points into the scroll table. Thanks again for all your contributions. I don't know exactly how long it will take to integrate everything into the GWT trunk, but its one of my highest priorities. Thanks, John LaBanca jlaba...@google.com On Wed, Jun 10, 2009 at 10:15 AM, dflorey daniel.flo...@gmail.com wrote: Hi, I'd like to support this effort and would be glad if some of my changes would make it into trunk: - filters - column types for most frequently used column types (numbers,dates,text) including proper filtering, editing and sorting capabilities - simplified table generation ( see http://code.google.com/p/google-web-toolkit-incubator/wiki/TreeTable ) (TreeTable is not ready for prime time yet) Daniel On 10 Jun., 05:34, jay jay.gin...@gmail.com wrote: I saw the initial commit of these classes into your branch, but I haven't seen any additional commits. I'd love to take a look at the current direction, and see what other input I can provide. jay On Jun 9, 7:12 am, John LaBanca jlaba...@google.com wrote: We'll definitely keep these things in mind when moving stuff over to GWT trunk. We've also found a lot of general usability problems, such as the fact the the table doesn't layout naturally, which means apps require active layout. During the transfer, we'll refactor quite a few things to make them more usable. Specifically, we'd like to provide a version that allows you to bulk renderer the header and footer into the same table element, eliminated the three separate tables and fixed layout. You would lose the scrolling feature, but you would not have to use active layout. When we start moving stuff into trunk or while its in my branch (as in right now), thats a good time to point out specific problems or requests. Its much harder to change the API after we make an official release. Thanks, John LaBanca jlaba...@google.com On Tue, Jun 9, 2009 at 5:01 AM, David david.no...@gmail.com wrote: Jay, We are experiencing the same ideas here. We store column ordering and widths on the server but we have no way of getting events in the UI to know when changes have been complete. wouldn't it be nice that the dnd was included as well, I could really use the DND of columns! Was it hard to implement ? We did not yet
[gwt-contrib] gen2 PagingScrollTable footer table horizontal scrolling
Is there any way, when you have a footer table associated with the PagingScrollTable, to have the horizontal scroll bar under the footer, rather than between the data table and the footer table? thanks, jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
Bump again? Any status? thanks... jay On Jul 7, 8:40 am, jay jay.gin...@gmail.com wrote: bump. Anything? On Jun 24, 10:31 am, jay jay.gin...@gmail.com wrote: Just curious if the effort has been resumed? Regardless, is there anyway for you to commit what you do have somewhere we could look and provide feedback? thanks, jay On Jun 10, 8:28 am, John LaBanca jlaba...@google.com wrote: @jay - I got side tracked with other tasks, but I'll pick up the PagingScrollTable effort within a couple of weeks. The main goal when we transfer the PagingScrollTable to GWT trunk is to separate the concept of scrolling (with three distinct tables) from the rest of the code. That way, we can bulk render a single table element that includes the header,data, and footer and have it layout naturally. @dflorey - I definitely plan to include all three of your points into the scroll table. Thanks again for all your contributions. I don't know exactly how long it will take to integrate everything into the GWT trunk, but its one of my highest priorities. Thanks, John LaBanca jlaba...@google.com On Wed, Jun 10, 2009 at 10:15 AM, dflorey daniel.flo...@gmail.com wrote: Hi, I'd like to support this effort and would be glad if some of my changes would make it into trunk: - filters - column types for most frequently used column types (numbers,dates,text) including proper filtering, editing and sorting capabilities - simplified table generation ( see http://code.google.com/p/google-web-toolkit-incubator/wiki/TreeTable ) (TreeTable is not ready for prime time yet) Daniel On 10 Jun., 05:34, jay jay.gin...@gmail.com wrote: I saw the initial commit of these classes into your branch, but I haven't seen any additional commits. I'd love to take a look at the current direction, and see what other input I can provide. jay On Jun 9, 7:12 am, John LaBanca jlaba...@google.com wrote: We'll definitely keep these things in mind when moving stuff over to GWT trunk. We've also found a lot of general usability problems, such as the fact the the table doesn't layout naturally, which means apps require active layout. During the transfer, we'll refactor quite a few things to make them more usable. Specifically, we'd like to provide a version that allows you to bulk renderer the header and footer into the same table element, eliminated the three separate tables and fixed layout. You would lose the scrolling feature, but you would not have to use active layout. When we start moving stuff into trunk or while its in my branch (as in right now), thats a good time to point out specific problems or requests. Its much harder to change the API after we make an official release. Thanks, John LaBanca jlaba...@google.com On Tue, Jun 9, 2009 at 5:01 AM, David david.no...@gmail.com wrote: Jay, We are experiencing the same ideas here. We store column ordering and widths on the server but we have no way of getting events in the UI to know when changes have been complete. wouldn't it be nice that the dnd was included as well, I could really use the DND of columns! Was it hard to implement ? We did not yet bother to investigate since we have to focus on getting functionality complete first. David On Tue, Jun 9, 2009 at 10:00 AM, jayjay.gin...@gmail.com wrote: As I see that this has begun (yeah), I'd like to throw out a few requests: * Please, please, please -- ensure that this is as extensible as possible. Here's just one example--I've integrated the gwt-dnd library to allow drag-n-drop re-ordering of columns. There are a couple of funny corner cases, though, because I have no way of knowing when a column resize has completed. Obviously, if you're resizing the column, you're not interested in dragging it to a new location. I strongly encourage you to think three, four, five times about making a method private or package protected. Liberal use of JavaDoc with strongly worded warnings to those of us who need to customize the widgets. I know this cuts down on your ability to make under-the-cover changes from release to release, but it makes it so that folks like me don't have to resort to things like JSNI trickery or copying the entire class or set of classes into our own code base. * As a direct follow up to #1, fire some more events. For example, fire an event when a column resize starts and when
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
bump. Anything? On Jun 24, 10:31 am, jay jay.gin...@gmail.com wrote: Just curious if the effort has been resumed? Regardless, is there anyway for you to commit what you do have somewhere we could look and provide feedback? thanks, jay On Jun 10, 8:28 am, John LaBanca jlaba...@google.com wrote: @jay - I got side tracked with other tasks, but I'll pick up the PagingScrollTable effort within a couple of weeks. The main goal when we transfer the PagingScrollTable to GWT trunk is to separate the concept of scrolling (with three distinct tables) from the rest of the code. That way, we can bulk render a single table element that includes the header,data, and footer and have it layout naturally. @dflorey - I definitely plan to include all three of your points into the scroll table. Thanks again for all your contributions. I don't know exactly how long it will take to integrate everything into the GWT trunk, but its one of my highest priorities. Thanks, John LaBanca jlaba...@google.com On Wed, Jun 10, 2009 at 10:15 AM, dflorey daniel.flo...@gmail.com wrote: Hi, I'd like to support this effort and would be glad if some of my changes would make it into trunk: - filters - column types for most frequently used column types (numbers,dates,text) including proper filtering, editing and sorting capabilities - simplified table generation ( see http://code.google.com/p/google-web-toolkit-incubator/wiki/TreeTable ) (TreeTable is not ready for prime time yet) Daniel On 10 Jun., 05:34, jay jay.gin...@gmail.com wrote: I saw the initial commit of these classes into your branch, but I haven't seen any additional commits. I'd love to take a look at the current direction, and see what other input I can provide. jay On Jun 9, 7:12 am, John LaBanca jlaba...@google.com wrote: We'll definitely keep these things in mind when moving stuff over to GWT trunk. We've also found a lot of general usability problems, such as the fact the the table doesn't layout naturally, which means apps require active layout. During the transfer, we'll refactor quite a few things to make them more usable. Specifically, we'd like to provide a version that allows you to bulk renderer the header and footer into the same table element, eliminated the three separate tables and fixed layout. You would lose the scrolling feature, but you would not have to use active layout. When we start moving stuff into trunk or while its in my branch (as in right now), thats a good time to point out specific problems or requests. Its much harder to change the API after we make an official release. Thanks, John LaBanca jlaba...@google.com On Tue, Jun 9, 2009 at 5:01 AM, David david.no...@gmail.com wrote: Jay, We are experiencing the same ideas here. We store column ordering and widths on the server but we have no way of getting events in the UI to know when changes have been complete. wouldn't it be nice that the dnd was included as well, I could really use the DND of columns! Was it hard to implement ? We did not yet bother to investigate since we have to focus on getting functionality complete first. David On Tue, Jun 9, 2009 at 10:00 AM, jayjay.gin...@gmail.com wrote: As I see that this has begun (yeah), I'd like to throw out a few requests: * Please, please, please -- ensure that this is as extensible as possible. Here's just one example--I've integrated the gwt-dnd library to allow drag-n-drop re-ordering of columns. There are a couple of funny corner cases, though, because I have no way of knowing when a column resize has completed. Obviously, if you're resizing the column, you're not interested in dragging it to a new location. I strongly encourage you to think three, four, five times about making a method private or package protected. Liberal use of JavaDoc with strongly worded warnings to those of us who need to customize the widgets. I know this cuts down on your ability to make under-the-cover changes from release to release, but it makes it so that folks like me don't have to resort to things like JSNI trickery or copying the entire class or set of classes into our own code base. * As a direct follow up to #1, fire some more events. For example, fire an event when a column resize starts and when it ends. * Flexibility is great, but often I'm just interested in the simple cases...simple. My example here is the multiple-row header stuff. It's GREAT! I LOVE it! (And better yet, our customers have been screaming for this!) But, I don't always need/want
[gwt-contrib] Re: I've implemented Java stack trace support for web mode
Did anything come of this? Alex -- does your approach work with GWT 1.6? And, have you decided to contribute this anywhere? I'll understand if you aren't willing, but I figured it can't hurt to ask. jay On May 7, 1:24 pm, Alex Epshteyn alexander.epsht...@gmail.com wrote: Hi Bob, Could you provide some numbers in terms of raw and gzipped before/after bytes? This is the OBF compiled js size of a TypeRacer module before and after instrumentation (raw/gz): 382/118 vs. 505/142 which can be further reduced by using shortened identifiers instead of method name strings (it doesn't make much difference when gzipped, though). In terms of inlining, I've implemented the optimization of not instrumenting simple getters and setters, which are guaranteed not to raise an exception. Everything else will probably not be eligible for inlining. But I do provide an annotation which you can use to exclude your hot methods from instrumentation. I looked at implementing perfect stack traces as an AST visitor, but decided that the size cost, speed cost for inlining, and potential data-leakage for large apps would outweigh the marginal gain of having line-level resolution in deployed apps. I'm not sure if that's necessarily the case. However, the capability you've implemented may very well be sufficient. I'm looking forward to testing out your code when I have more time. Those tradeoffs do make sense for development and QA versions of an app, but there was only a limited amount of time allocated for implementing stack traces. Yes, I can tell you from experience that what I did was pretty hairy and definitely took a good amount of time. There are lots of corner cases to consider when rewriting a Java AST, as you probably know. Just to give a tiny example - you can't insert anything before a super() statement. But at this point I have them all covered. I'm not yet sure if I'll be open-sourcing my code. I need to support my business, which isn't making much from online ad revenue, and I was hoping some of the enterprises using GWT might be happy to pay for my stack trace system. There are a few commercial tools in the GWT space, such aswww.instantiations.com/GWTDesigner, but I'm not sure how successful they are. I'd love to get some feedback from you guys about this idea. I can go both ways at this point. Your approach sounds complementary to the existing implementation. That's what I was hoping. Thanks, Alex On Thu, May 7, 2009 at 9:50 AM, BobV b...@google.com wrote: On Wed, May 6, 2009 at 4:49 PM, Alex Epshteyn alexander.epsht...@gmail.com wrote: I'm using static code rewriting at the Java source level to maintain a virtual stack. It's actually working out very well so far. Getting surprisingly good results for code size, efficiency, and correctness. Could you provide some numbers in terms of raw and gzipped before/after bytes? Also, how does this interact with method and function inlining? I want to decide whether it's worth the effort to continue developing my system. So my questions are does StackTraceCreator work with all browsers and is your symbol translation system ready to be used? Are there any limitations with your approach? Perhaps there is some area where my technique could provide better information to the programmer? StackTraceCreator is invoked in Throwable's initalizer and will extract as much data as the browser provides. On Mozilla, you'll get a full stack trace. On other browsers it crawls the caller chain, but since the caller chain isn't a proper series of activation records, and there's a limitation on reentrant functions. In the end, it provides method-level resolution. The symbol map file has enough data to cook a respectable StackTraceElement that makes IDE integration not unreasonable. I looked at implementing perfect stack traces as an AST visitor, but decided that the size cost, speed cost for inlining, and potential data-leakage for large apps would outweigh the marginal gain of having line-level resolution in deployed apps. Those tradeoffs do make sense for development and QA versions of an app, but there was only a limited amount of time allocated for implementing stack traces. Your approach sounds complementary to the existing implementation. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] gen2 PagingScrollTable: programmatic cell editing
Another piece of feedback on the incubator paging scroll table... I've got a case where I need to programmatically change the value in some cells (based on other input from the user). However, since the method used as the cell editor's callback is an anonymous, inline inner class, I have to replicate that code. (I'm referring to the inner class which starts on line 882 of SVN rev 1640 of PagingScrollTable.) Perhaps the contents of the callback's onComplete() implementation could be pulled out to a protected method, available for subclasses to use? Thanks!!! jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] gen2 PagingScrollTable column headers
Here's another thought to please keep in mind during the transition from the incubator to trunk... I've got a subclass of AbstractColumnDefinition (call it TheUsualColumnDefinition), which I use in most every place. It does all the stuff I normally need, like setting the right kind of cell renderer, making sure the width is setup properly, sets the visibility of the column, etc... And, of course, it sets the header with setHeader( 0, ... ). Now, I've got a subclass of TheUsualColumnDefinition where I actually need to add a second header row. My first inclination (despite reading the JavaDoc ;-) is to call setHeader( 1, ... ) to have this 2nd row show up underneath the first. I don't know what the original reasoning behind the definition of the header row index to be: The row index starts with the bottom row, which is reverse of a normal table. I have no doubt it is for a good reason, I'm just not sure what it is :-) My proposal would be that setting the header should work just like everywhere else...zero is the top-most row, one comes below that, two below one, etc... Besides adhering to the principle of least surprise, it makes my use case much simpler--a subclass can simply find out how many headers there are, and add its header as the next one. Otherwise, either the base class has to know that there are cases where it can be subclassed and other headers added, or else the subclass is going to have to do some fancy footwork shuffling headers around. Thanks for your consideration on this... jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
Just curious if the effort has been resumed? Regardless, is there anyway for you to commit what you do have somewhere we could look and provide feedback? thanks, jay On Jun 10, 8:28 am, John LaBanca jlaba...@google.com wrote: @jay - I got side tracked with other tasks, but I'll pick up the PagingScrollTable effort within a couple of weeks. The main goal when we transfer the PagingScrollTable to GWT trunk is to separate the concept of scrolling (with three distinct tables) from the rest of the code. That way, we can bulk render a single table element that includes the header,data, and footer and have it layout naturally. @dflorey - I definitely plan to include all three of your points into the scroll table. Thanks again for all your contributions. I don't know exactly how long it will take to integrate everything into the GWT trunk, but its one of my highest priorities. Thanks, John LaBanca jlaba...@google.com On Wed, Jun 10, 2009 at 10:15 AM, dflorey daniel.flo...@gmail.com wrote: Hi, I'd like to support this effort and would be glad if some of my changes would make it into trunk: - filters - column types for most frequently used column types (numbers,dates,text) including proper filtering, editing and sorting capabilities - simplified table generation ( see http://code.google.com/p/google-web-toolkit-incubator/wiki/TreeTable ) (TreeTable is not ready for prime time yet) Daniel On 10 Jun., 05:34, jay jay.gin...@gmail.com wrote: I saw the initial commit of these classes into your branch, but I haven't seen any additional commits. I'd love to take a look at the current direction, and see what other input I can provide. jay On Jun 9, 7:12 am, John LaBanca jlaba...@google.com wrote: We'll definitely keep these things in mind when moving stuff over to GWT trunk. We've also found a lot of general usability problems, such as the fact the the table doesn't layout naturally, which means apps require active layout. During the transfer, we'll refactor quite a few things to make them more usable. Specifically, we'd like to provide a version that allows you to bulk renderer the header and footer into the same table element, eliminated the three separate tables and fixed layout. You would lose the scrolling feature, but you would not have to use active layout. When we start moving stuff into trunk or while its in my branch (as in right now), thats a good time to point out specific problems or requests. Its much harder to change the API after we make an official release. Thanks, John LaBanca jlaba...@google.com On Tue, Jun 9, 2009 at 5:01 AM, David david.no...@gmail.com wrote: Jay, We are experiencing the same ideas here. We store column ordering and widths on the server but we have no way of getting events in the UI to know when changes have been complete. wouldn't it be nice that the dnd was included as well, I could really use the DND of columns! Was it hard to implement ? We did not yet bother to investigate since we have to focus on getting functionality complete first. David On Tue, Jun 9, 2009 at 10:00 AM, jayjay.gin...@gmail.com wrote: As I see that this has begun (yeah), I'd like to throw out a few requests: * Please, please, please -- ensure that this is as extensible as possible. Here's just one example--I've integrated the gwt-dnd library to allow drag-n-drop re-ordering of columns. There are a couple of funny corner cases, though, because I have no way of knowing when a column resize has completed. Obviously, if you're resizing the column, you're not interested in dragging it to a new location. I strongly encourage you to think three, four, five times about making a method private or package protected. Liberal use of JavaDoc with strongly worded warnings to those of us who need to customize the widgets. I know this cuts down on your ability to make under-the-cover changes from release to release, but it makes it so that folks like me don't have to resort to things like JSNI trickery or copying the entire class or set of classes into our own code base. * As a direct follow up to #1, fire some more events. For example, fire an event when a column resize starts and when it ends. * Flexibility is great, but often I'm just interested in the simple cases...simple. My example here is the multiple-row header stuff. It's GREAT! I LOVE it! (And better yet, our customers have been screaming for this!) But, I don't always need/want it. And, it can make things more complex. One idea would be to overload methods like getHeader() on AbstractColumnDefinition...add a version that doesn't take a 'row' parameter, and so just assumes there's
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
I'd definitely like to see the paging ability as an extension (read that as you will: interface implementation, derived class, plug-in behavior, whatever) to the scrolling behavior. I don't really like how the incubator has two totally separate, unrelated classes. I wonder if some performance enhancements could be made by having a TableModel interface which is just read-only, and then only if you need editing would you use a MutableTableModel. I'm just wondering here...I really don't know. Though I'm sure it would have other implications, like a change to the ColumnDefinition (e.g., making it read-only, and having a MutableColumnDefinition?) jay On Jun 10, 9:55 am, Isaac Truett itru...@gmail.com wrote: Re: Bruce's point about expectations and features vs. performance. Has there been (or should we start) discussion for the public record of different facets/features of tables, their impact on performance, and their possible class structure? What I'm thinking of specifically is bulk rendering vs. dynamic model-backed tables, scrolling, paging, and all the combinatorial permutations thereof. Will supported features be part of a single class hierarchy as they are in Incubator (i.e., PagingScrollTable extends ScrollTable; paging code is bound to scrolling code, although scrolling can be disabled it would still add code to the compiled app)? Or will they be pluggable features into a base Table class (like MonthSelectors for DatePickers)? Or separate implementations of a common Table interface? - Isaac On Wed, Jun 10, 2009 at 11:27 AM, Bruce Johnson br...@google.com wrote: I'll be the bad guy and try to lower expectations: whatever we end up doing, it has to be fast. We've seen some *horrible* usability problems with fancy tables -- even at a small number of rows -- and so don't be surprised if we have to pare back features and reduce API flexibility to ensure that a few key use cases are sufficiently high performance. -- Bruce On Tue, Jun 9, 2009 at 10:12 AM, John LaBanca jlaba...@google.com wrote: We'll definitely keep these things in mind when moving stuff over to GWT trunk. We've also found a lot of general usability problems, such as the fact the the table doesn't layout naturally, which means apps require active layout. During the transfer, we'll refactor quite a few things to make them more usable. Specifically, we'd like to provide a version that allows you to bulk renderer the header and footer into the same table element, eliminated the three separate tables and fixed layout. You would lose the scrolling feature, but you would not have to use active layout. When we start moving stuff into trunk or while its in my branch (as in right now), thats a good time to point out specific problems or requests. Its much harder to change the API after we make an official release. Thanks, John LaBanca jlaba...@google.com On Tue, Jun 9, 2009 at 5:01 AM, David david.no...@gmail.com wrote: Jay, We are experiencing the same ideas here. We store column ordering and widths on the server but we have no way of getting events in the UI to know when changes have been complete. wouldn't it be nice that the dnd was included as well, I could really use the DND of columns! Was it hard to implement ? We did not yet bother to investigate since we have to focus on getting functionality complete first. David On Tue, Jun 9, 2009 at 10:00 AM, jayjay.gin...@gmail.com wrote: As I see that this has begun (yeah), I'd like to throw out a few requests: * Please, please, please -- ensure that this is as extensible as possible. Here's just one example--I've integrated the gwt-dnd library to allow drag-n-drop re-ordering of columns. There are a couple of funny corner cases, though, because I have no way of knowing when a column resize has completed. Obviously, if you're resizing the column, you're not interested in dragging it to a new location. I strongly encourage you to think three, four, five times about making a method private or package protected. Liberal use of JavaDoc with strongly worded warnings to those of us who need to customize the widgets. I know this cuts down on your ability to make under-the-cover changes from release to release, but it makes it so that folks like me don't have to resort to things like JSNI trickery or copying the entire class or set of classes into our own code base. * As a direct follow up to #1, fire some more events. For example, fire an event when a column resize starts and when it ends. * Flexibility is great, but often I'm just interested in the simple cases...simple. My example here is the multiple-row header stuff. It's GREAT! I LOVE it! (And better yet, our customers have been screaming for this!) But, I don't always need/want it. And, it can make things more complex. One idea would be to overload methods like getHeader
[gwt-contrib] Moving PagingScrollTable Friends to Trunk
As I see that this has begun (yeah), I'd like to throw out a few requests: * Please, please, please -- ensure that this is as extensible as possible. Here's just one example--I've integrated the gwt-dnd library to allow drag-n-drop re-ordering of columns. There are a couple of funny corner cases, though, because I have no way of knowing when a column resize has completed. Obviously, if you're resizing the column, you're not interested in dragging it to a new location. I strongly encourage you to think three, four, five times about making a method private or package protected. Liberal use of JavaDoc with strongly worded warnings to those of us who need to customize the widgets. I know this cuts down on your ability to make under-the-cover changes from release to release, but it makes it so that folks like me don't have to resort to things like JSNI trickery or copying the entire class or set of classes into our own code base. * As a direct follow up to #1, fire some more events. For example, fire an event when a column resize starts and when it ends. * Flexibility is great, but often I'm just interested in the simple cases...simple. My example here is the multiple-row header stuff. It's GREAT! I LOVE it! (And better yet, our customers have been screaming for this!) But, I don't always need/want it. And, it can make things more complex. One idea would be to overload methods like getHeader() on AbstractColumnDefinition...add a version that doesn't take a 'row' parameter, and so just assumes there's only 1 row. * More use of generics, less casting (for me). Some examples: o AbstractColumnDefinition returns Object for the getHeader() method. Why not declare this as class AbstractColumnDefinitionRowType, ColType, HeaderType? o Rather than: public TableDefinitionRowType getTableDefinition (), how about adding a TABLE_DEFINITION type to the class (e.g., class PagingScrollTableTABLE_DEFINITION extends TableDefinitionRowType, so that the method could be declared as public TABLE_DEFINITION getTableDefinition()? I apologize if I'm being overly simplistic or if I'm asking too much. I definitely apologize for not following up my suggestions with proposed patches. And I sincerely hope that my suggestions are taken only as the most positive form of feedback possible. I LOVE GWT. We've bet our company on the fact that GWT is *the* best way for writing the kind of interactive and rich apps our users are demanding. I want to do whatever I can (with my limited time outside of my job) to help make this toolkit even better. Thanks! jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk
I saw the initial commit of these classes into your branch, but I haven't seen any additional commits. I'd love to take a look at the current direction, and see what other input I can provide. jay On Jun 9, 7:12 am, John LaBanca jlaba...@google.com wrote: We'll definitely keep these things in mind when moving stuff over to GWT trunk. We've also found a lot of general usability problems, such as the fact the the table doesn't layout naturally, which means apps require active layout. During the transfer, we'll refactor quite a few things to make them more usable. Specifically, we'd like to provide a version that allows you to bulk renderer the header and footer into the same table element, eliminated the three separate tables and fixed layout. You would lose the scrolling feature, but you would not have to use active layout. When we start moving stuff into trunk or while its in my branch (as in right now), thats a good time to point out specific problems or requests. Its much harder to change the API after we make an official release. Thanks, John LaBanca jlaba...@google.com On Tue, Jun 9, 2009 at 5:01 AM, David david.no...@gmail.com wrote: Jay, We are experiencing the same ideas here. We store column ordering and widths on the server but we have no way of getting events in the UI to know when changes have been complete. wouldn't it be nice that the dnd was included as well, I could really use the DND of columns! Was it hard to implement ? We did not yet bother to investigate since we have to focus on getting functionality complete first. David On Tue, Jun 9, 2009 at 10:00 AM, jayjay.gin...@gmail.com wrote: As I see that this has begun (yeah), I'd like to throw out a few requests: * Please, please, please -- ensure that this is as extensible as possible. Here's just one example--I've integrated the gwt-dnd library to allow drag-n-drop re-ordering of columns. There are a couple of funny corner cases, though, because I have no way of knowing when a column resize has completed. Obviously, if you're resizing the column, you're not interested in dragging it to a new location. I strongly encourage you to think three, four, five times about making a method private or package protected. Liberal use of JavaDoc with strongly worded warnings to those of us who need to customize the widgets. I know this cuts down on your ability to make under-the-cover changes from release to release, but it makes it so that folks like me don't have to resort to things like JSNI trickery or copying the entire class or set of classes into our own code base. * As a direct follow up to #1, fire some more events. For example, fire an event when a column resize starts and when it ends. * Flexibility is great, but often I'm just interested in the simple cases...simple. My example here is the multiple-row header stuff. It's GREAT! I LOVE it! (And better yet, our customers have been screaming for this!) But, I don't always need/want it. And, it can make things more complex. One idea would be to overload methods like getHeader() on AbstractColumnDefinition...add a version that doesn't take a 'row' parameter, and so just assumes there's only 1 row. * More use of generics, less casting (for me). Some examples: o AbstractColumnDefinition returns Object for the getHeader() method. Why not declare this as class AbstractColumnDefinitionRowType, ColType, HeaderType? o Rather than: public TableDefinitionRowType getTableDefinition (), how about adding a TABLE_DEFINITION type to the class (e.g., class PagingScrollTableTABLE_DEFINITION extends TableDefinitionRowType, so that the method could be declared as public TABLE_DEFINITION getTableDefinition()? I apologize if I'm being overly simplistic or if I'm asking too much. I definitely apologize for not following up my suggestions with proposed patches. And I sincerely hope that my suggestions are taken only as the most positive form of feedback possible. I LOVE GWT. We've bet our company on the fact that GWT is *the* best way for writing the kind of interactive and rich apps our users are demanding. I want to do whatever I can (with my limited time outside of my job) to help make this toolkit even better. Thanks! jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] gen2 PagingScrollTable: Editing cell values
I just realized that when you have a cell editor defined for a column, after the cell edit is complete, the setCellValue() method is called. This method does not have enough information, however, for me to update my table! It passes the value of the row (which, in my case is String[]) and the new value. It seems that to use this method, I'd have to search the entire table for a row that matches the passed-in rowValue. Then, when I have that row index, I'd be able to update my actual data structure. If I'm wrong about this, please let me know. Otherwise, as this widget is moved into trunk, please change the signature to pass in the CellEditInfo which does contain this information. Thanks, jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: gen2 PagingScrollTable: Editing cell values
Just a thought here... Perhaps the CellEditInfo class could be enhanced to add: * The original value (before the edit started) * The proposed new value This would give the setCellValue() method access to the complete information about the edit. thanks again, jay On Jun 4, 12:09 pm, jay jay.gin...@gmail.com wrote: I just realized that when you have a cell editor defined for a column, after the cell edit is complete, the setCellValue() method is called. This method does not have enough information, however, for me to update my table! It passes the value of the row (which, in my case is String[]) and the new value. It seems that to use this method, I'd have to search the entire table for a row that matches the passed-in rowValue. Then, when I have that row index, I'd be able to update my actual data structure. If I'm wrong about this, please let me know. Otherwise, as this widget is moved into trunk, please change the signature to pass in the CellEditInfo which does contain this information. Thanks, jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] gen2 PagingScrollTable: Hiding a column
I allow my users to change which columns are hidden, and which are
visible.
When the table is initially created, I'm calling setColumnVisible() on
the DefaultTableDefinition, according to the last saved state. Now,
when the user changes the visibility setting for a column, I need to
show or hide that column. Simply calling
DefaultTableDefinition::setColumnVisible() doesn't actually do
anything.
Here's what I've done...please let me know if there's a better way:
In a PST subclass I have created a refresh() method:
public void refresh() {
ListRowType rows = new ArrayListRowType( getRowValues() );
setData( getAbsoluteFirstRowIndex(), rows.iterator() );
}
This does the trick (especially as it does not require that I go back
to the server for the data!). However, is this the best way?
Thanks,
jay
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: gen2 PagingScrollTable column widths
But if I set the min and max sizes, then the user cannot resize the
columns. And...well, my users need to be able to resize the columns...
So, I guess I should enter a feature request (or else provide a
patch ;-) that there some way for the table to set the initial column
width to the preferred width.
jay
On May 7, 6:08 pm, John LaBanca jlaba...@google.com wrote:
If you want the columns to be an exact size, set the minimum and maximum
column widths and call resetColumnWidths() or set the resize policy to
FIXED.
The preferred width is exactly that, the width that the columns should
attempt to maintain if they can. When the resize policy is set to
FILL_WIDTH, the table will update the column widths on every page load.
When it is set to anything else, you must update the width manually
(although that is probably a bug). Either way, the preferred width is not
guaranteed, but the minimum and maximum widths are.
Thanks,
John LaBanca
jlaba...@google.com
On Thu, May 7, 2009 at 7:11 PM, jay jay.gin...@gmail.com wrote:
I've set my table resize policy to UNCONSTRAINED. I then very
carefully setup my ColumnDefinitions to have the right preferred size
(because the user may have previously resized the columns, and I need
to honor that size).
What I've noticed, though, is that out-of-the-box, my columns are
*always* 80px wide (which seems to correspond to
FixedWidthGrid.DEFAULT_COLUMN_WIDTH.
It seems to me (and please...correct me if I'm misusing/abusing the
PagingScrollTable) that when I set the table definition, it should be
setting the column widths to their preferred size, rather than
allowing the default size to kick in.
FWIW, my work-around is to override setTableDefinition() as follows:
�...@override
public void setTableDefinition(
TableDefinitionRowType tableDefinition
) {
super.setTableDefinition( tableDefinition );
refreshVisibleColumnDefinitions();
ListColumnDefinitionRowType, ? columns =
getVisibleColumnDefinitions();
for ( int index = 0, numCols = columns.size(); index numCols;
index++ ) {
setColumnWidth( index, columns.get
( index ).getPreferredColumnWidth() );
}
}
Would problems be caused if this behavior was in the base class? (My
goal is to have the PagingScrollTable just work. I'll be the first
to admit that what I consider just working may not work for
others...)
thanks,
jay
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: gen2 PagingScrollTable column widths
I've entered issue #3648 --
http://code.google.com/p/google-web-toolkit/issues/detail?id=3648.
thanks!
jay
On May 11, 1:30 pm, Isaac Truett itru...@gmail.com wrote:
Yep, that is what you're doing. Sorry for my failure at reading
comprehension. :)
I can certainly see why you would have that expectation for an
unconstrained table. And if I'm reading John's probably a bug
comment correctly, then it sounds like that might be a good thing to
enter in the issue tracker.
And your comments are certainly welcome. Feedback is always needed,
especially in the incubator.
On Mon, May 11, 2009 at 4:11 PM, jay jay.gin...@gmail.com wrote:
Yes! When the table width is unconstrained, I want it to honor the
preferred width of every column.
If you glance back at my original post, you'll see that I'm doing
exactly what you suggest :-) It's just that this was surprising to me,
and required more work than I think ought to be needed.
(I understand that this widget is still in the incubator... I hope
that my comments are coming across as helpful, because I really am
trying to be helpful, and not critical. I chalk all of this up to
hey...let's throw something out there, and see what else needs to be
done.)
thanks!
jay
On May 11, 11:31 am, Isaac Truett itru...@gmail.com wrote:
Jay,
Am I right in understanding that you're expecting the table, when
unconstrained, to grow until each column can occupy its preferred
width? It should be possible to achieve that, although just setting
preferred size may not be enough. There used to be a setColumnWidth()
method that would set a column's size, but still allow it to be
resized later. I don't know what the gen2 PST equivalent would be, but
I can dig around a bit later if I get some time.
On Mon, May 11, 2009 at 1:14 PM, jay jay.gin...@gmail.com wrote:
But if I set the min and max sizes, then the user cannot resize the
columns. And...well, my users need to be able to resize the columns...
So, I guess I should enter a feature request (or else provide a
patch ;-) that there some way for the table to set the initial column
width to the preferred width.
jay
On May 7, 6:08 pm, John LaBanca jlaba...@google.com wrote:
If you want the columns to be an exact size, set the minimum and maximum
column widths and call resetColumnWidths() or set the resize policy to
FIXED.
The preferred width is exactly that, the width that the columns should
attempt to maintain if they can. When the resize policy is set to
FILL_WIDTH, the table will update the column widths on every page load.
When it is set to anything else, you must update the width manually
(although that is probably a bug). Either way, the preferred width is
not
guaranteed, but the minimum and maximum widths are.
Thanks,
John LaBanca
jlaba...@google.com
On Thu, May 7, 2009 at 7:11 PM, jay jay.gin...@gmail.com wrote:
I've set my table resize policy to UNCONSTRAINED. I then very
carefully setup my ColumnDefinitions to have the right preferred size
(because the user may have previously resized the columns, and I need
to honor that size).
What I've noticed, though, is that out-of-the-box, my columns are
*always* 80px wide (which seems to correspond to
FixedWidthGrid.DEFAULT_COLUMN_WIDTH.
It seems to me (and please...correct me if I'm misusing/abusing the
PagingScrollTable) that when I set the table definition, it should be
setting the column widths to their preferred size, rather than
allowing the default size to kick in.
FWIW, my work-around is to override setTableDefinition() as follows:
�...@override
public void setTableDefinition(
TableDefinitionRowType tableDefinition
) {
super.setTableDefinition( tableDefinition );
refreshVisibleColumnDefinitions();
ListColumnDefinitionRowType, ? columns =
getVisibleColumnDefinitions();
for ( int index = 0, numCols = columns.size(); index numCols;
index++ ) {
setColumnWidth( index, columns.get
( index ).getPreferredColumnWidth() );
}
}
Would problems be caused if this behavior was in the base class? (My
goal is to have the PagingScrollTable just work. I'll be the first
to admit that what I consider just working may not work for
others...)
thanks,
jay
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] gen2 PagingScrollTable scroll indicator
I'm starting to use the gen2 incubator table widgets. I hope I can provide some valuable feedback in the days and weeks to come... The first issue I've run into that I cannot seem to work around: When I load my data into the PagingScrollTable, it is already sorted (in fact, all of our data uses server-side sorting). I worked out that in order to get the sorting indicator displayed, I should call: ColumnSortList sortList = ...; getDataTable().setColumnSortList( sortList, true ); I can see that this fires the event which PagingScrollTable listens for. However, when PagingScrollTable gets the event, it checks to see if the sortedColumnTrigger member is null. In this case, it is, because the only way for that (private) member to be set is in reaction to a ONMOUSEUP event. What's the best way to resolve this? Should I file a bug? Submit a patch? Something else? thanks, jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: gen2 PagingScrollTable scroll indicator
Ah. I will look at doing both :-)
In the mean time, here's the solution I just stumbled upon. In my
derived class:
int index = ...; // figure out the column that we're sorted by.
Element headerElem = getHeaderTable().getFlexCellFormatter
().getElement( 0, index );
applySortedColumnIndicator( headerElem,
tableReportComponentDTO.sortAscending );
I'd suggest adding the following method to PagingScrollTable:
public void setColumnSortList(
TableModelHelper.ColumnSortList sortList
) {
getDataTable().setColumnSortList( sortList, true );
Element headerElem = getHeaderTable().getFlexCellFormatter
().getElement( 0, sortList.getPrimaryColumn() );
applySortedColumnIndicator( headerElem, sortList.isPrimaryAscending
() );
}
jay
On May 7, 12:10 pm, Isaac Truett itru...@gmail.com wrote:
Hi Jay,
That does sound like a bug. Opening an issue in the tracker is a good
idea. Issues with patches attached are even better.
- Isaac
On Thu, May 7, 2009 at 3:02 PM, jay jay.gin...@gmail.com wrote:
I'm starting to use the gen2 incubator table widgets. I hope I can
provide some valuable feedback in the days and weeks to come...
The first issue I've run into that I cannot seem to work around: When
I load my data into the PagingScrollTable, it is already sorted (in
fact, all of our data uses server-side sorting). I worked out that in
order to get the sorting indicator displayed, I should call:
ColumnSortList sortList = ...;
getDataTable().setColumnSortList( sortList, true );
I can see that this fires the event which PagingScrollTable listens
for. However, when PagingScrollTable gets the event, it checks to see
if the sortedColumnTrigger member is null. In this case, it is,
because the only way for that (private) member to be set is in
reaction to a ONMOUSEUP event.
What's the best way to resolve this? Should I file a bug? Submit a
patch? Something else?
thanks,
jay
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] gen2 PagingScrollTable column widths
I've set my table resize policy to UNCONSTRAINED. I then very
carefully setup my ColumnDefinitions to have the right preferred size
(because the user may have previously resized the columns, and I need
to honor that size).
What I've noticed, though, is that out-of-the-box, my columns are
*always* 80px wide (which seems to correspond to
FixedWidthGrid.DEFAULT_COLUMN_WIDTH.
It seems to me (and please...correct me if I'm misusing/abusing the
PagingScrollTable) that when I set the table definition, it should be
setting the column widths to their preferred size, rather than
allowing the default size to kick in.
FWIW, my work-around is to override setTableDefinition() as follows:
@Override
public void setTableDefinition(
TableDefinitionRowType tableDefinition
) {
super.setTableDefinition( tableDefinition );
refreshVisibleColumnDefinitions();
ListColumnDefinitionRowType, ? columns =
getVisibleColumnDefinitions();
for ( int index = 0, numCols = columns.size(); index numCols;
index++ ) {
setColumnWidth( index, columns.get
( index ).getPreferredColumnWidth() );
}
}
Would problems be caused if this behavior was in the base class? (My
goal is to have the PagingScrollTable just work. I'll be the first
to admit that what I consider just working may not work for
others...)
thanks,
jay
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Incubator Questions
Is this the best forum for providing feedback on these widgets? (I've looked high low, and found nothing better, but it's entirely possible I've managed to miss the obvious ;-) thanks! jay On May 1, 7:03 am, Bruce Johnson br...@google.com wrote: We do expect to start moving a cluster of the most popular widgets from the incubator into the GWT trunk this quarter, so things like the paging table, etc. will almost certainly be in the next GWT major release. On Fri, May 1, 2009 at 1:53 AM, Gilles B gilles.broch...@gmail.com wrote: I am currently using gen2 tables. It's realy a good stuff and this part realy miss in GWT widgets with paging (or not), columns sort and such cool mechanisms. I have tried other tables implementations but this one is not so big and work fine for me. As example, Smart GWT offers a realy good and more beautifull component but I doesn't want to include such full framework implying some js library extra dependance (half commercial). The gwt as a toolkit approach seems better and its avoid the big library syndrom (Including hundred of script, css, resources, javacode in your app if you only want a single component) As 1.6 only provide an additionnal calendar I was a little bit disappointed expected more widgets in this version. Is there a plan to add such widgets in future releases or is it a choice to provide a basic set and opening the field to third party libraries ? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Incubator Questions
I'm curious as to how it is decided a new drop of incubator should be made available? Is it based on a new GWT drop? Or maybe, there is no real release cycle? How about testing? Is there any official testing on the incubator widgets? Is it just the unit tests, plus whatever bug reports that may come in? Being an incubator, I'd expect breaking changes to roll through periodically. Is there usually a hey...we're going to break this tomorrow email that comes through the list before these things happen? Finally, I've not seen any good description of how it is decided when an incubator widget graduates. I guess, more particularly, what is holding back the current set of table widgets from graduating into the trunk? Thanks, jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Commits Code Reviews
As a lurker, I have to say I really like seeing the commit messages come across...it makes me feel like I can see what's coming down the pipe, and what I ought to be thinking about / getting ready to take advantage of. To save my time, though, I follow this group with Google Reader... I was wondering if there is any way that the synopsis which gets produced for the RSS feed could be expanded? For commit messages, it'd be nice to see some (all?) of the diff. For code reviews, it'd be nice to just have the complete text. thanks, jay --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: 1.6 Event handler proposal
Does this proposal mean that if I want to receive the equivilant of
todays Event.MOUSEEVENTS, that I have to call:
widget.addMouseDownHandler( new MouseDownHandler() { ... } );
widget.addMouseUpHandler( new MouseUpHandler() { ... } );
widget.addMouseMoveHandler( new MouseMoveHandler() { ... } );
widget.addMouseOverHandler( new MouseOverHandler() { ... } );
widget.addMouseOutHandler( new MouseOutHandler() { ... } );
If that's the case, then it seems that users of this new API will have
a larger burden... Perhaps there should be a general MouseHandler
that could be used like:
public class MouseHandler implements FiresMouseDownEvents,
FiresMouseUpEvents, ... { }
widget.addMouseHandler( new MouseHandler() { ... } );
This MouseHandler would, internally, add the 6 different types of
mouse event handlers.
I'd expect a similar sort of construct for keyboard events, etc...
If, by some chance, I'm totally off on my understanding, or if what
I'm saying is just completely obvious to everyone else, then please
accept my apologies ahead of time...
And, thanks to all of you working so hard to make the lives of folks
like me so much better! (I would never attempt to write the kind of
application I'm working on in pure JavaScript. That'd suck!)
jay
This comment really isn't a big deal. It would just suck (in my
opinion) to have a whole bunch of people writing the same little
classes all the time...
On Sep 22, 1:02 pm, Emily Crutcher [EMAIL PROTECTED] wrote:
A more complete implementation of the event handlers has been added to
the gwt-incubator
gen2.event
packagehttp://code.google.com/p/google-web-toolkit-incubator/source/browse/#
The next step is to declare the design final, take the code from prototype
to production and submit it to GWT trunk for inclusion in GWT 1.6, so this
may be the last time any of you get a chance to holler if you don't like the
system. The up-to-date design doc is
here.http://code.google.com/p/google-web-toolkit-incubator/wiki/ProposedEv...
For those of you who have been following the discussion already, the main
changes are summarized below. Note, the design doc contains the actual
design, this list is only for the convenience of those who have been closely
following this thread:
1. Added a default Widget.onBrowserEvent
2. subscribeTo mechanism replaced by addAndSinkHandler mechanism
3. For each event type(ClickEvent used as an example)
- ClickEvent.Source -- HasClickEvents
- ClickEvent.fireEvent(Handler) -- ClickEvent.KEY.fire(Event,Handler)
--
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
-~--~~~~--~~--~--~---
