[gwt-contrib] Re: Remove caching of style sheets in IE6 (cache may be invalid when there are multiple modules)
On 2010/03/08 19:43:13, Dan Rice wrote:
I added a new patch that caches the lengths but not the actual style
sheet
contents. In the worst case, if the lengths are wrong we will just
append in a
suboptimal way, but not lose any data. Benchmarking shows that the
performance
difference is minor -- still just 2-3 ms per injection in my
particular
benchmark.
On 2010/03/05 17:19:51, jlabanca wrote:
http://gwt-code-reviews.appspot.com/159804/diff/1/3
File user/src/com/google/gwt/dom/client/StyleInjector.java (right):
http://gwt-code-reviews.appspot.com/159804/diff/1/3#newcode101
Line 101: private static native int getDocumentStyleSheetLength(int
idx) /*-{
I don't know for sure if reading cssText.length is slow, but I'm
worried that
we
had a reason to cache the length originally. I agree that there is
no way to
cache the info because we can't control what happens outside of GWT,
so we
wouldn't even know if external code modified the style sheets.
Can you just try injecting 40 large style sheets and compare the
performance
before and after the change? At the very least, we should warn
people if its
going to get really slow.
LGTM.
http://gwt-code-reviews.appspot.com/159804
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Changes for crawling:
Reviewers: amtimanjhi_google.com, Description: Changes for crawling: - CrawlableHyperlink - client-side changes to Showcase sample Review at http://gwt-code-reviews.appspot.com/161801 Please review this at http://gwt-code-reviews.appspot.com/163802 Affected files: M samples/showcase/src/com/google/gwt/sample/showcase/client/Showcase.java M samples/showcase/war/Showcase.html A user/src/com/google/gwt/user/client/ui/CrawlableHyperlink.java A user/test/com/google/gwt/user/client/ui/CrawlableHyperlinkTest.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Changes for crawling:
http://gwt-code-reviews.appspot.com/161801/diff/1/3 File samples/showcase/war/Showcase.html (right): http://gwt-code-reviews.appspot.com/161801/diff/1/3#newcode4 Line 4: script language='javascript' The reason I add the title programmatically is because it changes to reflect the widget that is being shown off. This makes for more descriptive titles, which is especially important for indexing. [As an aside, I personally feel there should be nothing or close to nothing in the html file. I see your point, but if your browser doesn't run JS, this title isn't going to help you a whole lot, either... But if you feel strongly about it, I'll put it back in, but it will just be overridden if the browser does run JS.] On 2010/03/08 23:29:44, amitmanjhi wrote: Any disadvantage to leaving the title here (even though you are setting it later)? At least, browsers that can't run JS can see the title. http://gwt-code-reviews.appspot.com/161801/diff/1/4 File user/src/com/google/gwt/user/client/ui/CrawlableHyperlink.java (right): http://gwt-code-reviews.appspot.com/161801/diff/1/4#newcode58 Line 58: } I'm not sure I understand. Because constructors aren't inherited, I wouldn't be able to do Hyperlink link = new CrawlableHyperlink(Click Me, myToken); if I didn't override them. Do you have a specific suggestion? Great point about the more descriptive javadoc. I hope I've improved it. On 2010/03/08 23:29:44, amitmanjhi wrote: Why override these constructors if the override is not doing anything useful? Shouldn't over-riding just the setTargetHistoryToken method and having a more descriptive Javadoc for this class suffice? http://gwt-code-reviews.appspot.com/161801/diff/1/5 File user/test/com/google/gwt/user/client/ui/CrawlableHyperlinkTest.java (right): http://gwt-code-reviews.appspot.com/161801/diff/1/5#newcode28 Line 28: } On 2010/03/08 23:29:44, amitmanjhi wrote: change to com.google.gwt.user.DebugTest, as in HyperLinkTest. Done. http://gwt-code-reviews.appspot.com/161801/diff/1/5#newcode36 Line 36: Thanks! Done. On 2010/03/08 23:29:44, amitmanjhi wrote: Arguments of assertEquals must be swapped. It is assertEquals(expected, actual). http://gwt-code-reviews.appspot.com/161801/diff/1/5#newcode41 Line 41: assertEquals(historyToken, !myToken); On 2010/03/08 23:29:44, amitmanjhi wrote: historyToken can be inlined everywhere. Done. http://gwt-code-reviews.appspot.com/161801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Issue 4586: DOMImpl.g/setInnerText() use unnecessarily expensive node manipulation
LGTM http://gwt-code-reviews.appspot.com/160805 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] 3 PopupPanel related bugs
Thanks, George. I'll put these on our schedule to look at as soon as we can. On Fri, Mar 5, 2010 at 9:41 AM, ggeorg georgopoulos.georg...@gmail.comwrote: Hi, please have a look at: - http://code.google.com/p/google-web-toolkit/issues/detail?id=4720can=4 - http://code.google.com/p/google-web-toolkit/issues/detail?id=4664can=4 - http://code.google.com/p/google-web-toolkit/issues/detail?id=4662can=4 the patch for the last one is not valid. Thanks, George. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: supporting java.io.InputStream/Reader in GWT's JRE
Hi Ray. Thanks for the pointer. That was exactly what I needed. Took about 20 minutes of work to get InputStream and Reader working in GWT. Also, my coworkers and I are wondering if GWT is single. eric On Mar 8, 5:18 pm, Ray Cromwell cromwell...@gmail.com wrote: Look at the user/super/com/google/gwt/emul source for the GWT JRE emulation, e.g.http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/... super-source/ is what you want. It allows Web mode and Hosted Mode to see different source code. -Ray On Mon, Mar 8, 2010 at 12:54 PM, Eric B. Ridge eeb...@gmail.com wrote: Please don't laugh (at least not out loud). I've run into a situation where I really need to use a JavaCC generated parser on the client-side. The generated code is all simple Java, except for its use of java.io.InputStream and java.io.Reader. Is it possible to implement additional GWT JRE objects as maybe a GWT module, or through various .gwt.xml directives? Basically, could support for those base classes be added without modifying the GWT source directly? If yes, is there a starting documentation page somewhere on the intertubes? ISTM that translating java.io.InputStream would be stupid simple, and then I could roll my own lame implementation that uses a java.lang.String as the backing store. In my case, I just need to parse user-typed strings. I've got no need to tie the InputStream to an HTTP response, for example. java.io.Reader might be a bit more difficult since it references stuff in java.nio, but I could probably work around that (even if I have to manually/programmatically hack the JavaCC generated parser source at build time). Anyways, any advice on where to begin implementing an additional GWT JRE object will be greatly appreciated. eric -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: supporting java.io.InputStream/Reader in GWT's JRE
Also, my coworkers and I are wondering if GWT is single.? I am not an English native (so I might have read smth you didn't mean :)), but this is very funny. I love her too. Andi On Tue, Mar 9, 2010 at 11:24 AM, Eric B. Ridge eeb...@gmail.com wrote: Hi Ray. Thanks for the pointer. That was exactly what I needed. Took about 20 minutes of work to get InputStream and Reader working in GWT. Also, my coworkers and I are wondering if GWT is single. eric On Mar 8, 5:18 pm, Ray Cromwell cromwell...@gmail.com wrote: Look at the user/super/com/google/gwt/emul source for the GWT JRE emulation, e.g. http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/... super-source/ is what you want. It allows Web mode and Hosted Mode to see different source code. -Ray On Mon, Mar 8, 2010 at 12:54 PM, Eric B. Ridge eeb...@gmail.com wrote: Please don't laugh (at least not out loud). I've run into a situation where I really need to use a JavaCC generated parser on the client-side. The generated code is all simple Java, except for its use of java.io.InputStream and java.io.Reader. Is it possible to implement additional GWT JRE objects as maybe a GWT module, or through various .gwt.xml directives? Basically, could support for those base classes be added without modifying the GWT source directly? If yes, is there a starting documentation page somewhere on the intertubes? ISTM that translating java.io.InputStream would be stupid simple, and then I could roll my own lame implementation that uses a java.lang.String as the backing store. In my case, I just need to parse user-typed strings. I've got no need to tie the InputStream to an HTTP response, for example. java.io.Reader might be a bit more difficult since it references stuff in java.nio, but I could probably work around that (even if I have to manually/programmatically hack the JavaCC generated parser source at build time). Anyways, any advice on where to begin implementing an additional GWT JRE object will be greatly appreciated. eric -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RFC : Soft permutations for the GWT compiler
As a more complicated example, an internal app has different translations for Latin-American Spanish from the rest of the Spanish translations, so they have es and es_419 as deferred binding properties. Then they inherit CldrLocales, and automatically get the right set of runtime locales in the es_419 permutation (es_MX, es_AR, etc but not es_ES etc). If they had to manually specify this, and alter the complete set of collapsed properties each time they added a new deferred-binding locale it would be a real hassle. This sounds like an orthogonal capability in the module syntax that involves conditionally defining new property values. Based on your description, would you expect to write something similar to the following in the CldrLocales.gwt.xml file? extend-property name=locale values=es_MX, es_AR when-property-is name=locale value=es / /extend-property -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: supporting java.io.InputStream/Reader in GWT's JRE
On Tue, Mar 9, 2010 at 11:29 AM, Andi Mullaraj andimulla...@gmail.comwrote: Also, my coworkers and I are wondering if GWT is single.? I am not an English native (so I might have read smth you didn't mean :)), but this is very funny. I love her too. ha ha -- i'm totally stealing that joke. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RFC : Soft permutations for the GWT compiler
On Tue, Mar 9, 2010 at 11:29 AM, BobV b...@google.com wrote: As a more complicated example, an internal app has different translations for Latin-American Spanish from the rest of the Spanish translations, so they have es and es_419 as deferred binding properties. Then they inherit CldrLocales, and automatically get the right set of runtime locales in the es_419 permutation (es_MX, es_AR, etc but not es_ES etc). If they had to manually specify this, and alter the complete set of collapsed properties each time they added a new deferred-binding locale it would be a real hassle. This sounds like an orthogonal capability in the module syntax that involves conditionally defining new property values. Based on your description, would you expect to write something similar to the following in the CldrLocales.gwt.xml file? extend-property name=locale values=es_MX, es_AR when-property-is name=locale value=es / /extend-property The problem is that I would have to encode the relationships into the file, and therefore have to remember to update them when the locale inheritance rules are updated, plus I can't write it for arbitrary sets of locales being collapsed. For example, the way runtime locales works today is that I can just inherit CldrLocales and define the compile-time permutations I want and things just works. My app might use some text that is different in Argentina from other Latin American countries, so I might have es (European Spanish), es_419 (Latin American Spanish), and es_AR (Argentine Spanish) as deferred-bound locales, and the rest would be runtime locales. That happens automatically without having to hack the CldrLocales file to change which locales are combined together. If later I find I need a different translation for Mexico, I just add a locale value of es_MX to my module, and everything works as before. I suppose an app developer can just be made responsible for picking all the locales they want combined together, but that seems like an unnecessary burden on them to start with (check out how many there are in CldrLocales), and a maintenance nightmare as the set of locales change (which happens pretty much with every CLDR update). It seems the current way is much better, where all they do is define the locales they need compiled separately, import CLDR locales, and then they automatically get the rest of them customized as GWT gains the information about a particular sublocale. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix for KeyPressEvent.getCharCode and overall key events improvements
On 2010/03/03 16:47:02, jlabanca wrote: LGTM. http://gwt-code-reviews.appspot.com/154812 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RFC : Soft permutations for the GWT compiler
What does runtime locales do, exactly? -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RFC : Soft permutations for the GWT compiler
On Tue, Mar 9, 2010 at 12:04 PM, BobV b...@google.com wrote: What does runtime locales do, exactly? Essentially what soft permutations do, for number/date/time formatting rules, currency details, and the default currency for a locale. They are implemented by doing a switch on the runtime locale to select among implementations that inherit from a given deferred-bound locale. The selected implementation is cached so it is only computed on the first call. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: supporting java.io.InputStream/Reader in GWT's JRE
On Mar 9, 11:29 am, Andi Mullaraj andimulla...@gmail.com wrote: Also, my coworkers and I are wondering if GWT is single.? I am not an English native (so I might have read smth you didn't mean :)), but this is very funny. I love her too. You read it correctly! eric -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Changes for crawling:
Reviewers: amitmanjhi, Description: Changes for crawling: - CrawlableHyperlink - client-side changes to Showcase sample Review at http://gwt-code-reviews.appspot.com/161801 Please review this at http://gwt-code-reviews.appspot.com/165801 Affected files: M samples/showcase/src/com/google/gwt/sample/showcase/client/Showcase.java M samples/showcase/war/Showcase.html A user/src/com/google/gwt/user/client/ui/CrawlableHyperlink.java A user/test/com/google/gwt/user/client/ui/CrawlableHyperlinkTest.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Give a better error message when RunAsyncCode.runAsyncCode is passed something
Mostly LGTM, and a definitely improvement. That being said, there's an inconsistency between this and the the existing error reporting architecture. The general paradigm is that all potential user-errors are caught by the time GenerateJavaAST finishes. These lines in JavaToJavaScriptCompiler are meant to be the last chance. // GenerateJavaAST can uncover semantic JSNI errors; report abort checkForErrors(logger, goldenCuds, true); After this point, all errors are essentially compiler bugs. There are basically two routes for early error detection: 1) You write a Checker, like ArtificialRescueChecker or BinaryTypeReferencesRestrictionsChecker. 2) The older way of doing it that preceded Checkers is WebModeCompilerFrontEnd.doFindAdditionalTypesUsingRebinds() + FindDeferredBindingSitesVisitor. Since GWT.create() has much the same constraints as RunAsync, that might be really easy. http://gwt-code-reviews.appspot.com/161802/diff/1/2 File dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java (right): http://gwt-code-reviews.appspot.com/161802/diff/1/2#newcode265 Line 265: TreeLogger fileLogger = logger.branch(TreeLogger.ERROR, Errors in ' Might as well include the line number? The source info should give the exact problem line with precision, e.g. Error at Hello.java(38): blah Otherwise methodDescription I think just gives the line of the start of the method. http://gwt-code-reviews.appspot.com/161802 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Give a better error message when RunAsyncCode.runAsyncCode is passed something
I should have mentioned.. one of the important reasons to do the error checking early (and on the JDT AST rather than the GWT AST) is that at some point we want to share all user-error validation code with the Google Eclipse Plugin, and it'd be good if that migration is as painless as possible. http://gwt-code-reviews.appspot.com/161802 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RFC : Soft permutations for the GWT compiler
Here's what John and I worked out over IM to get the existing runtime locales support migrated to soft permutations: - The existing locale property continues to work as it currently does. - The runtime.locales configuration property is eliminated in favor of a runtimeLocale deferred-binding property. - The runtimeLocale property is defined and collapsed by a ModuleDefMutator which also defines additional rebind rules based on the defined locale values. - One or more ModuleDefMutators are installed by a module-mutator class=Foo / which are called before ModuleDef.normalize() - The SelectionProperty interface gains a getCollapsedValues() which gives the values that are equivalent to the value returned by getCurrentValue(). - This allows the runtime performance of the Generators to be optimized. - The locale generators are simplified, removing the runtime locale factory and instead relying on the soft rebind rules created by the ModuleDefMutator. This will increase the size of the permutation-selection matrix, but this could be mitigated by using property-value extensions. In the same way that es_AR extends es, we might have chrome extends safari, iphone extends safari. The value extension work is separate and orthogonal, but plays nicely with the two techniques in http://code.google.com/p/google-web-toolkit/wiki/ControllingPermutationExplosion. Thoughts? -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7688 committed - Fix the escaping of a String used in one of test methods of JsonpReque...
Revision: 7688
Author: amitman...@google.com
Date: Tue Mar 9 09:29:14 2010
Log: Fix the escaping of a String used in one of test methods of
JsonpRequestTest
Patch by: amitmanjhi
Review by: jat
http://code.google.com/p/google-web-toolkit/source/detail?r=7688
Modified:
/trunk/user/test/com/google/gwt/jsonp/client/JsonpRequestTest.java
===
--- /trunk/user/test/com/google/gwt/jsonp/client/JsonpRequestTest.java Thu
Feb 25 06:57:14 2010
+++ /trunk/user/test/com/google/gwt/jsonp/client/JsonpRequestTest.java Tue
Mar 9 09:29:14 2010
@@ -184,7 +184,7 @@
public void testCancel() {
delayTestFinish(2000);
// setup a server request that will delay for 500ms
-JsonpRequestString req = jsonp.requestString(echoDelayed(A, 500),
+JsonpRequestString req = jsonp.requestString(echoDelayed('A', 500),
new AssertFailureCallbackString(A));
// cancel it before it comes back
req.cancel();
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RFC : Soft permutations for the GWT compiler
Since module-mutator amounts to an API change (and sounds pretty weird from a distance), please update the (nice) design doc and get unanimous consent from the SDK team (after getting contributor feedback from the group here). On Tue, Mar 9, 2010 at 3:31 PM, BobV b...@google.com wrote: Here's what John and I worked out over IM to get the existing runtime locales support migrated to soft permutations: - The existing locale property continues to work as it currently does. - The runtime.locales configuration property is eliminated in favor of a runtimeLocale deferred-binding property. - The runtimeLocale property is defined and collapsed by a ModuleDefMutator which also defines additional rebind rules based on the defined locale values. - One or more ModuleDefMutators are installed by a module-mutator class=Foo / which are called before ModuleDef.normalize() - The SelectionProperty interface gains a getCollapsedValues() which gives the values that are equivalent to the value returned by getCurrentValue(). - This allows the runtime performance of the Generators to be optimized. - The locale generators are simplified, removing the runtime locale factory and instead relying on the soft rebind rules created by the ModuleDefMutator. This will increase the size of the permutation-selection matrix, but this could be mitigated by using property-value extensions. In the same way that es_AR extends es, we might have chrome extends safari, iphone extends safari. The value extension work is separate and orthogonal, but plays nicely with the two techniques in http://code.google.com/p/google-web-toolkit/wiki/ControllingPermutationExplosion . Thoughts? -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RFC : Soft permutations for the GWT compiler
On Tue, Mar 9, 2010 at 3:31 PM, BobV b...@google.com wrote: - The runtimeLocale property is defined and collapsed by a ModuleDefMutator which also defines additional rebind rules based on the defined locale values. - One or more ModuleDefMutators are installed by a module-mutator class=Foo / which are called before ModuleDef.normalize() - The SelectionProperty interface gains a getCollapsedValues() which gives the values that are equivalent to the value returned by getCurrentValue(). - This allows the runtime performance of the Generators to be optimized. - The locale generators are simplified, removing the runtime locale factory and instead relying on the soft rebind rules created by the ModuleDefMutator. To clarify the need for ModuleDefMutator -- the way runtime locales work currently is that you just define the locales you want to be compile-time properties, say en, es, and es_419 (Latin American Spanish) and inherit CldrLocales. The runtime locales will automatically pickup every locale that inherits from the current compile-time locale, for example picking up es_AR, es_CO, es_MX, etc for the es_419 permutations. If I later added an es_AR locale value (which I might do if I needed a separate translation for Argentina), then nothing else has to be be changed -- es_AR will no longer be picked up via the es_419 permutation. Having to specify the set of locales and inheritance/aliases between them (which may change with each CLDR release) seems like a real pain for a developer, so the idea is to allow code to generate the proper collapse-property entries given the set of locale values and the inheritance hierarchy among locales. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RFC : Soft permutations for the GWT compiler
Thanks for the explanation. Would be really useful to add to the design doc with enough formatting to make it easy to understand. It just seems like a very powerful feature that could interact in very hard-to-understand ways with various build systems, IDEs, etc. So it would need a lot of vetting. On Tue, Mar 9, 2010 at 3:48 PM, John Tamplin j...@google.com wrote: On Tue, Mar 9, 2010 at 3:31 PM, BobV b...@google.com wrote: - The runtimeLocale property is defined and collapsed by a ModuleDefMutator which also defines additional rebind rules based on the defined locale values. - One or more ModuleDefMutators are installed by a module-mutator class=Foo / which are called before ModuleDef.normalize() - The SelectionProperty interface gains a getCollapsedValues() which gives the values that are equivalent to the value returned by getCurrentValue(). - This allows the runtime performance of the Generators to be optimized. - The locale generators are simplified, removing the runtime locale factory and instead relying on the soft rebind rules created by the ModuleDefMutator. To clarify the need for ModuleDefMutator -- the way runtime locales work currently is that you just define the locales you want to be compile-time properties, say en, es, and es_419 (Latin American Spanish) and inherit CldrLocales. The runtime locales will automatically pickup every locale that inherits from the current compile-time locale, for example picking up es_AR, es_CO, es_MX, etc for the es_419 permutations. If I later added an es_AR locale value (which I might do if I needed a separate translation for Argentina), then nothing else has to be be changed -- es_AR will no longer be picked up via the es_419 permutation. Having to specify the set of locales and inheritance/aliases between them (which may change with each CLDR release) seems like a real pain for a developer, so the idea is to allow code to generate the proper collapse-property entries given the set of locale values and the inheritance hierarchy among locales. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Testing new GWT RPC implementation (aka deRPC)
On Jul 24 2009, 10:22 pm, BobV b...@google.com wrote:
The deRPC code went into trunk a week or so ago, and no initial fires
have been reported. I'd like to get folks on GWTC to give it a
shakedown.
snip
I'm mainly looking for the following kinds of feedback:
- If it doesn't work, please tell me how it breaks:
- Run your JVM with -Dgwt.rpc.dumpPayload=true to have RpcServlet
emit the incoming and outgoing payloads to System.out.
I realize it is roughly 8 months later, but I just got around to
checking out deRPC today with GWT 2.0.1.
It seems to work great until a remote service throws an Exception.
What I get back on the client-side is an instance of
com.google.gwt.user.client.rpc.StatusCodeException.
Our remote services set the HTTP response code to 500 when they catch
an Exception. We do this so access.log will indicate when a request
fails.
The legacy RPC mechanism didn't honor the response code in the face of
an Exception (very annoying). deRPC does (I see the 500's in
access.log), but RpcCallbackAdapter.java:83 does this:
if (statusCode != Response.SC_OK) {
caught = new StatusCodeException(statusCode, encodedResponse);
}
The actual exception is tucked away inside encodedResponse, never to
be decoded.
Could this somehow be rearranged such that the response is decoded,
checked for instanceof Throwable and then assigned to caught,
otherwise construct a new StatusCodeException() that takes the decoded
response object as an argument rather than the encodedResponse string
(along with API additions for StatusCodeException.getResponseObject()
or whatever).
Or set the decoded object (if instanceof Throwable) as the cause of
the new StatusCodeException.
ISTM that the string form of encodedResponse is pretty darn useless to
anyone outside of RpcCallbackAdapter.
Otherwise, deRPC seems to work great (limited testing thus far), and
is significantly faster in at least Safari for OS X.
Thanks for your consideration.
eric
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7689 committed - Get rid of the jars in bikeshed/war/WEB_INF/lib, and fix style of Stor...
Revision: 7689
Author: rj...@google.com
Date: Tue Mar 9 10:30:26 2010
Log: Get rid of the jars in bikeshed/war/WEB_INF/lib, and fix style of
Storage
Desk review by amitmanjhi
No rietvled review due to upload script problemsb
Review by: amitman...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=7689
Deleted:
/trunk/bikeshed/war/WEB-INF/lib
Modified:
/trunk/bikeshed/.classpath
/trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/Currency.java
/trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/Employee.java
/trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/Report.java
/trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/ReportItem.java
/trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/Storage.java
===
--- /trunk/bikeshed/.classpath Mon Mar 8 13:39:42 2010
+++ /trunk/bikeshed/.classpath Tue Mar 9 10:30:26 2010
@@ -1,12 +1,11 @@
?xml version=1.0 encoding=UTF-8?
classpath
- classpathentry kind=lib
path=war/WEB-INF/lib/com.springsource.javax.validation-1.0.0.GA.jar/
classpathentry kind=src path=src/
classpathentry kind=src path=test/
- classpathentry kind=con
path=com.google.gwt.eclipse.core.GWT_CONTAINER/
classpathentry kind=con
path=org.eclipse.jdt.launching.JRE_CONTAINER/
classpathentry kind=lib path=war/WEB-INF/lib/gwt-servlet.jar/
classpathentry kind=con
path=org.eclipse.jdt.junit.JUNIT_CONTAINER/3/
- classpathentry kind=lib path=war/WEB-INF/lib/json.jar/
+ classpathentry kind=var
path=GWT_TOOLS/redist/json/r2_20080312/json.jar/
+ classpathentry kind=con
path=com.google.gwt.eclipse.core.GWT_CONTAINER/
classpathentry kind=output path=war/WEB-INF/classes/
/classpath
===
--- /trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/Currency.java
Thu Mar 4 12:59:01 2010
+++ /trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/Currency.java
Tue Mar 9 10:30:26 2010
@@ -20,10 +20,10 @@
*/
// @javax.persistence.Entity
public class Currency implements Entity {
- @javax.validation.constraints.Size(min = 3, max = 3)
+// @javax.validation.constraints.Size(min = 3, max = 3)
private String code;
- @javax.validation.constraints.Size(min = 2, max = 30)
+// @javax.validation.constraints.Size(min = 2, max = 30)
private String name;
private final Long id;
===
--- /trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/Employee.java
Thu Mar 4 14:11:39 2010
+++ /trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/Employee.java
Tue Mar 9 10:30:26 2010
@@ -34,10 +34,10 @@
private final Integer version;
- @javax.validation.constraints.Size(min = 2, max = 30)
+// @javax.validation.constraints.Size(min = 2, max = 30)
private String userName;
- @javax.validation.constraints.Size(min = 2, max = 30)
+// @javax.validation.constraints.Size(min = 2, max = 30)
private String displayName;
// @javax.persistence.ManyToOne(targetEntity =
===
--- /trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/Report.java
Thu Mar 4 14:11:39 2010
+++ /trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/Report.java
Tue Mar 9 10:30:26 2010
@@ -25,22 +25,22 @@
private final Long id;
private final Integer version;
- @javax.validation.constraints.NotNull
- @javax.validation.constraints.Past
+// @javax.validation.constraints.NotNull
+// @javax.validation.constraints.Past
// @javax.persistence.Temporal(javax.persistence.TemporalType.TIMESTAMP)
private java.util.Date created = new Date();
- @javax.validation.constraints.NotNull
+// @javax.validation.constraints.NotNull
// @javax.persistence.Enumerated
private Status status;
- @javax.validation.constraints.NotNull
+// @javax.validation.constraints.NotNull
// @javax.persistence.ManyToOne(targetEntity =
// com.google.io.expenses.server.domain.Employee.class)
// @javax.persistence.JoinColumn
private Employee reporter;
- @javax.validation.constraints.Size(min = 3, max = 100)
+// @javax.validation.constraints.Size(min = 3, max = 100)
private String purpose;
// @javax.persistence.ManyToOne(targetEntity =
===
---
/trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/ReportItem.java
Thu Mar 4 12:59:01 2010
+++
/trunk/bikeshed/src/com/google/gwt/sample/expenses/domain/ReportItem.java
Tue Mar 9 10:30:26 2010
@@ -24,26 +24,26 @@
private Integer version;
- @javax.validation.constraints.NotNull
+// @javax.validation.constraints.NotNull
// @javax.persistence.ManyToOne(targetEntity = Report.class)
// @javax.persistence.JoinColumn
private Report report;
- @javax.validation.constraints.NotNull
- @javax.validation.constraints.Past
+// @javax.validation.constraints.NotNull
+// @javax.validation.constraints.Past
//
Re: [gwt-contrib] RFC : Soft permutations for the GWT compiler
On Tue, Mar 9, 2010 at 4:26 PM, Bruce Johnson br...@google.com wrote: Thanks for the explanation. Would be really useful to add to the design doc with enough formatting to make it easy to understand. It just seems like a very powerful feature that could interact in very hard-to-understand ways with various build systems, IDEs, etc. So it would need a lot of vetting. The upshot at least to all of this discussion about the locale stuff is that it hasn't invalidated the current patch. The discussion seems to be centered around what needs to be added in order to allow this to subsume runtime locales. I need to digest today's conversations and will have a breakout document tomorrow to recap the different possible solutions. -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [google-web-toolkit] r7690 committed - Gflow framework with some local CFG-based optimizations....
w00t! That's a lot of work that just landed! -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Test upload for soft permutations
(Just adding myself as a reviewer.) http://gwt-code-reviews.appspot.com/160801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] First request factory call with params
Reviewers: amitmanjhi, Description: Pick an employee from the select, and see his expenses. Please review this at http://gwt-code-reviews.appspot.com/168801 Affected files: bikeshed/.classpath bikeshed/src/com/google/gwt/requestfactory/shared/Slot.java bikeshed/src/com/google/gwt/sample/expenses/client/EmployeeList.java bikeshed/src/com/google/gwt/sample/expenses/client/Expenses.java bikeshed/src/com/google/gwt/sample/expenses/client/Shell.java bikeshed/src/com/google/gwt/sample/expenses/client/Shell.ui.xml bikeshed/src/com/google/gwt/sample/expenses/client/ValuesImpl.java bikeshed/src/com/google/gwt/sample/expenses/domain/CreationVisitor.java bikeshed/src/com/google/gwt/sample/expenses/domain/NullFieldFiller.java bikeshed/src/com/google/gwt/sample/expenses/domain/RelationshipRefreshingVisitor.java bikeshed/src/com/google/gwt/sample/expenses/domain/RelationshipValidationVisitor.java bikeshed/src/com/google/gwt/sample/expenses/domain/Report.java bikeshed/src/com/google/gwt/sample/expenses/domain/ReportItem.java bikeshed/src/com/google/gwt/sample/expenses/domain/Storage.java bikeshed/src/com/google/gwt/sample/expenses/server/ExpensesDataServlet.java bikeshed/src/com/google/gwt/sample/expenses/shared/Employee.java bikeshed/src/com/google/gwt/sample/expenses/shared/EmployeeRequests.java bikeshed/src/com/google/gwt/sample/expenses/shared/ExpenseRequestFactory.java bikeshed/src/com/google/gwt/sample/expenses/shared/MethodName.java bikeshed/src/com/google/gwt/sample/expenses/shared/Report.java bikeshed/src/com/google/gwt/sample/expenses/shared/ReportRequests.java bikeshed/test/com/google/gwt/sample/expenses/domain/NullFieldFillerTest.java bikeshed/test/com/google/gwt/sample/expenses/domain/StorageTest.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: First request factory call with params
Code review, please http://gwt-code-reviews.appspot.com/168801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [google-web-toolkit] r7690 committed - Gflow framework with some local CFG-based optimizations....
very exciting! nice work. On Tue, Mar 9, 2010 at 7:20 PM, Scott Blum sco...@google.com wrote: w00t! That's a lot of work that just landed! -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix escaping
On 2010/03/09 02:56:39, jat wrote: LGTM Thanks. Commited http://code.google.com/p/google-web-toolkit/source/detail?r=7688 http://gwt-code-reviews.appspot.com/163801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Changes for crawling:
On 2010/03/09 18:27:31, kathrin wrote: Continuing the code review here. The only remaining issue I have is with the 3 constructors in CrawlableHyperlink that don't do anything. Do you need to override all 3? Also, while you are at it, perhaps you can deprecate/refactor/cleanup some of the constructor code in Hyperlink. Thanks! http://gwt-code-reviews.appspot.com/165801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Fix JsDuplicateFunctionRemover to handle non-empty ctor/seed funcs
Reviewers: Lex, scottb, Description: Scott's new ctor patch violates some assumptions of the old duplicate remover. This new one uses a more general purpose mechanism for avoiding removal where it's not warranted, the algorithm, as Scott invented it: Any JsNameRef JsName that is *not* the immediate LHS of a JsInvocation is blacklisted, and therefore, cannot be replaced nor replace another ref. For example, defineSeed(ctor1, ctor2) would stop ctor1 or ctor2 from being considered, and so would ctor1.prototype = ... . It looks like JsNameOf nodes can refer to functions as well, so these are blacklisted too. Also added: unit tests. Please review this at http://gwt-code-reviews.appspot.com/169801 Affected files: dev/core/src/com/google/gwt/dev/js/JsDuplicateFunctionRemover.java dev/core/test/com/google/gwt/dev/js/JsDuplicateFunctionRemoverTest.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
