Hi,
we're using GWT 2.6.0 and recently added the gwt-cal module. Since then some users reported that instead of the application they only saw an empty page. We debugged the issue, but now are at a loss how to "properly" fix it.
Our own .gwt.xml looks (abbreviated) like this:
The goal is to have permutations for our two supported locales: en and fr.
The gwt-cal modules support quite a few more locales, and looks (again trimmed) like this:
What happens now is that compiling our module produces permutations only for 'en' and 'fr', but the calculation of the 'locale' property value does also accept 'ar' and all other locales. As a result the permutation switching code does not select an existing permutation if a user for some reason uses one of those locales, and those users observe a completely empty page, rather than being forced into the 'en' locale.
It looks like we have the following options here:
1. modify the gwt-cal module and remove the <extend-property> parts
2. modify GWT's PropertiesUtil#generatePropertyProvider() to produce the list of values that are allowed from SelectionProperty#getAllowedValues() rather than SelectionProperty#getPossibleValues()
3. create a new PropertyProvider for locale that does an explicit check of the detected locale
The first option would be very localized, and we would get breakage again when another module starts extending the 'locale' property values. Additionally the first options make updating a lot harder. I've looked briefly in the third approach, but it seems that I would have to copy/paste most code from LocalePropertyProviderGenerator, which seems also a bit sub-optimal :)
Am I missing an approach here, or could anyone see any other option?
Best Regards,
--
Andreas
-- we're using GWT 2.6.0 and recently added the gwt-cal module. Since then some users reported that instead of the application they only saw an empty page. We debugged the issue, but now are at a loss how to "properly" fix it.
Our own .gwt.xml looks (abbreviated) like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 2.6.0//EN" "gwt-module.dtd">
<module rename-to='frontend'>
<!-- Inherit the core Web Toolkit stuff. -->
<inherits name='com.google.gwt.user.User' />
<inherits name='com.google.gwt.i18n.I18N' />
<!-- ... -->
<inherits name='com.bradrydzewski.gwt.calendar.Calendar' />
<inherits name='com.bradrydzewski.gwt.calendar.theme.google.Google' />
<inherits name='com.allen_sauer.gwt.dnd.gwt-dnd' />
<!-- ... -->
<!-- Define supported locales -->
<extend-property name="locale" values="en"/>
<extend-property name="locale" values="fr"/>
<set-property name="locale" value="en,fr" />
<set-property-fallback name="locale" value="en" />
</module>
The goal is to have permutations for our two supported locales: en and fr.
The gwt-cal modules support quite a few more locales, and looks (again trimmed) like this:
<module>
<inherits name="com.google.gwt.user.User" />
<inherits name="com.google.gwt.user.UserAgent"/>
<inherits name='com.allen_sauer.gwt.dnd.gwt-dnd'/>
<inherits name="com.google.gwt.i18n.I18N" />
<extend-property name="locale" values="ar"/>
<!-- many more -->
<extend-property name="locale" values="zh_TW"/>
<!-- ... -->
</module>
What happens now is that compiling our module produces permutations only for 'en' and 'fr', but the calculation of the 'locale' property value does also accept 'ar' and all other locales. As a result the permutation switching code does not select an existing permutation if a user for some reason uses one of those locales, and those users observe a completely empty page, rather than being forced into the 'en' locale.
It looks like we have the following options here:
1. modify the gwt-cal module and remove the <extend-property> parts
2. modify GWT's PropertiesUtil#generatePropertyProvider() to produce the list of values that are allowed from SelectionProperty#getAllowedValues() rather than SelectionProperty#getPossibleValues()
3. create a new PropertyProvider for locale that does an explicit check of the detected locale
The first option would be very localized, and we would get breakage again when another module starts extending the 'locale' property values. Additionally the first options make updating a lot harder. I've looked briefly in the third approach, but it seems that I would have to copy/paste most code from LocalePropertyProviderGenerator, which seems also a bit sub-optimal :)
Am I missing an approach here, or could anyone see any other option?
Best Regards,
--
Andreas
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+unsubscribe@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/d/optout.
No comments:
Post a Comment