Re: [gwt-contrib] I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
On Wed, Jul 17, 2013 at 4:56 PM, Alex Epshteyn wrote: > I would like to announce that I have finally solved what I always thought > to be GWT's greatest weakness: its lack of debugging information for > client-side exceptions in production. > > With my patch, your deployed app will be able to report stack traces like > this: > > com.google.gwt.core.client.JavaScriptException: (TypeError) : a is null > > com.google.gwt.dom.client.DOMImplMozilla.$getBodyOffsetLeft(DOMImplMozilla.java:145) > > com.google.gwt.user.client.ui.PopupPanel.$setPopupPosition(Document.java:1287) > > com.google.gwt.user.client.ui.PopupPanel.setPopupPosition(PopupPanel.java:884) > com.google.gwt.user.client.ui.PopupPanel.PopupPanel(PopupPanel.java:453) > > com.typeracer.commons.client.widgets.EnhancedPopup.EnhancedPopup(EnhancedPopup.java:32) > > com.typeracer.commons.client.widgets.PopupWithIcon.PopupWithIcon(PopupWithFocusableTextBox.java:28) > > com.typeracer.main.client.controller.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.java:55) > > com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:50) > etc... :-) > > > instead of the current state of affairs that looks like this: > > lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName: > http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html > stack: @ > http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 > Rub@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 > > dSb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 > > tA@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 > Xmb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289 > > etc... :-( > > So, something like this has been used at least internally for quite a long time -- what exactly did you have to change in StackTraceDeobfuscator? -- John A. Tamplin -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: Plural forms and I18NCreator
This is not supported. The problem is the information simply isn't there to
convert from the properties file to the fully typed Java interface without
adding some convention for comments specifying that information -- if you
are going to do that, you might as well just write the Java code.
For example:
msg=They gave you a widget.
msg[FEMALE]=She gave you a widget.
msg[MALE]=He gave you a widget.
How are you supposed to get the type of the @Select parameter (assuming you
infer it)? It could be a String or an Enum, and if an Enum which one should
you use?
How do you get the argument names or types? Ie:
msg=Your total is {0}
Is argument 0 an int, double, BigDecimal, or something else?
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/k8SaGpBaVGAJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: localisation issues with DateTimeFormat.PredefinedFormat MONTH_ABBR
All of the data ultimately comes from Unicode CLDR. For both English and German, the format string used for MONTH_ABBR is "LLL", which is the standalone abbreviated form of the month. In English, all of the abbreviated names are 3 letters, as they should be. For German, the standalone form of the month (to be used when it doesn't have a day and/or year in the format, depending on the locale) used to have the varying length and punctuation you describe, but has been updated in the current CLDR to all 3-letter abbreviations. So, the updated German abbreviations will be picked up automatically when we next update the CLDR data included in GWT, which unfortunately will not be in time for the 2.4 release. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/kCG-pQ0u8d8J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Using a custom DateFormatProvider in GWT
GWT uses the data from the Unicode CLDR, and supports ta and ta_LK, so ta_IN should get the ta defaults, which should be appropriate for IN. If you believe there should be a specialization for ta in India, then I suggest filing a bug against CLDR to add it. Aside from that, search for *_ta.* under user/src/com/google/gwt/i18n and make a copy under *_ta_IN.* and edit it as needed. You could put those files in your own project and GWT will use them if they are on the classpath. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/IsYSDfFFZqIJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: override locale in datebox
GWT is only running one locale at a time -- you specify the set of locales you want to build your app with, and then only the strings / formats for that locale are downloaded to the user. See http://code.google.com/webtoolkit/doc/latest/DevGuideI18nLocale.html for more info. Once you set the locales you want, then your date box will be formatted appropriately for the locale it is running in. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/cZNcXsiKyPcJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Adding overrides to Constants/ConstantsWithLookup/Messages
BTW, I don't regularly read this group (too much traffic, I do read GWTC though), so if you have a question for me specifically you should email me directly. Regarding the @Select bug -- that was fixed in trunk a few weeks ago and will be in 2.4. Basically, you want dynamic i18n and all of this functionality is performed at compile time. You won't be able to substitute different messages at runtime, as there is no parsing of the format pattern at runtime at all. Even if you port that code, hat would then bring in all possible message format code, since you don't know what will be needed until you parse the format patterns. Also, you would have to replicate a ton of code to fully implement all of the functionality in client-side code. This is basically why we don't support String.format -- the code itself is large and winds up pulling in lots of other code. You can write your own dynamic i18n code (there may be external libraries for this already), but see the caveats above -- if you only support limited subsets, it might not be too bad. Another option would be to deploy different compiled versions for each of your clients. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/rVDWzsfG4lMJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Better XSRF protection in 2.3?
Also, you are free to use the underlying RpcToken capabilities, which solves
the hard part of the problem (transparently adding a token to every RPC
request). You can use it to build on top of whatever session mechanism you
have now, like this:
// could also add @XsrfProtect and extend RemoteService instead if you
prefer
public interface MyService extends XsrfProtectedService {
...
}
MyServiceAsync svc = GWT.create(MyService.class);
((HasRpcToken) svc).setRpcToken(getTokenFromHostPageOrWherever());
public class MyServiceImpl extends AbstractXsrfProtectedServiceServlet
implements MyService {
protected validateXsrfToken(RpcToken token, Method method) {
// throw RpcTokenException if token is not valid
}
}
You already have to extend a particular base class for GWT RPC, to get the
serialization/deserialization, so extending a different one doesn't seem
much of a burden. I don't think there is going to be a "drop-in, zero
changes" XSRF fix that works with everybody's deployment strategies.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Competitor for world's most useless JavaDoc "comment"
On Monday, May 16, 2011 1:22:43 PM UTC-4, Greg Dougherty wrote:
>
> It's too bad that there a 2 valid comments, and 34 worthless ones.
>
> Might I suggest that the GWT "Coding Standards" would do well to focus
> on requiring people to write readable and understandable code (which
> means having comments that explain what you're doing and why), rather
> than merely obsessing on whether people use tabs or spaces?
>
See the TODO at the beginning of PredefinedFormat -- patches welcome.
The *_{SHORT,MEDIUM,LONG,FULL} formats are harder to describe the other
formats like the ISO_8601 and RFC_2822 formats, since they will vary
significantly across locales. Basically, for these we just use whatever
those are defined as in CLDR. AFAIK, there is no documentation on exactly
what the criteria are for those lengths, which means the Javadoc that would
go there would be either "A short date format" or "The CLDR short date
format", which doesn't seem more useful than the name itself which is why it
hasn't been written yet.
The other predefined formats, which are also derived from CLDR data via
ICU4J, seem self-explanatory. Is there really much value in a Javadoc for
the HOUR_MINUTE_SECOND format that says "A format containing the hour,
minute, and second"?
Regarding the overall quality of doc in the GWT codebase, my personal
experience is that it is far better than most open-source projects -- of
course it can always be improved and anyone can submit such improvements.
As always, there is a limited amount of hours in the day and decisions must
be made on where to spend that time.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Competitor for world's most useless JavaDoc "comment"
On Monday, May 16, 2011 1:42:45 PM UTC-4, Christian Goudreau wrote:
>
> Well, you may be right about some missing javadoc features, but do you have
> to flame about it knowing that they work hard and give us this incredible
> tool freely ? I'm maybe to sensitive lol
>
> As for format, define your own, it's easy:
> @Provides @Named("BlogPostFormat")
> DateTimeFormat getDateTimeFormat() {
> return DateTimeFormat.getFormat(" dd, ");
> }
>
As the next post suggests, this is not going to get you the correct
localized DateTimeFormat. If you really want a customized one that is still
localized, see CustomDateTimeFormat, as in:
public interface MyFormat extends CustomDateFormat {
@Pattern("dd")
DateTimeFormat format();
}
MyFormat fmt = GWT.create(MyFormat.class);
Window.alert(fmt.format(date));
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
FF4.0 DevMode [was: Re: Update Chrome to 10.0.612.1 does not work with either 2.1.0 or 2.1.1]
On Monday, December 20, 2010 11:44:11 AM UTC-5, alanmechy wrote: > > And, of course, I'm wondering when FF4 will be supported in GWT - but > that's another story (and > thread) entirely. In August I heard it was "real soon now"... > The problem was that every new beta of FF4 broke the APIs we were using, so we stopped trying to follow them until they settled down. Supposedly the APIs are final as of 4.0b7, so Chris Conroy is working on it now. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Developer Plugin not working on Firefox 3.5.5 on Linux
Please add your details to http://code.google.com/p/google-web-toolkit/issues/detail?id=4141 -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Why History.newItem() always calls the onModuleLoad?
A couple of points: - you don't need to call History.fireCurrentState() after newItem(). - you are calling newItem() from within the history change handler A typical history-enabled app will call fireCurrentState in onModuleLoad, actions that change history state simply call newItem with the new state and do nothing else. The onValueChanged handler then does the work of actuallly changing to respond to the event, that way it just works when the user users forward/back, bookmarks a history state, etc. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Development mode crashes Safari 4.0.4 in OS X 10.4
Created http://code.google.com/p/google-web-toolkit/issues/detail?id=4413 -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RemoteDeathError in GWT 2.0 Developer Mode
RemoteDeathError is thrown when the connection to the browser is closed. Are you changing the URL in your app? If you change anything but the hash portion, it will reload the app which will drop the devmode connection. You can try increasing the log level with -logLevel SPAM and see what the last call was before the connection is lost.l -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
