On 2013-03-25, at 12:40 PM, Eric Wittmann wrote: > Hello everyone. I'm finally putting hands to keyboard on this, and am > making some progress figuring out how a lot of the code generation works > in Errai. It's a bit slow going for me, but it gets easier every...hour. :) Yeah. If you find any particular part of errai-codegen especially opaque, please call it out and we'll try to clean up and/or javadoc it more thoroughly. We've all been chipping away at this, but the API has quite a large surface area and I know many rough edges remain. > Anyway, the first aspect of this that I'm tackling is the creation and > inclusion of the message bundle file. We tentatively decided to use the > standard resource loading mechanism in GWT (the same thing the template > system uses) to load the message bundle. I'm hoping that we'll > eventually have something that will work either statically or > dynamically (giving devs that option). But for now I'm sticking with > static loading of the bundle file. > > Here are some initial decisions: > > 1) You active i18n support in your module by annotating your @EntryPoint > with @Bundle, providing the name of the bundle resource in the @Bundle > annotation. > 2) Each GWT module has at most one i18n message bundle. > 3) The bundle resource is a JSON formatted file. No one likes > Properties files, and browsers are pretty darn good at processing JSON I > imagine. That said, I'm certainly open to changing this. I'm definitely ready to try JSON for this. In my imagination, it's going to be cumbersome to quote each key and each value, but in reality, I bet it will be fine. And as you say, this is optimal from a parsing-in-the-browser perspective. Finally, the mere fact that the file will be UTF-8 is going to make up for a lot when compared with .properties files. :) > 4) The bundle file can have any name, as long as it has a .json extension. > 5) Localized versions of the bundle file look like this: > * MyAppBundle.json > * MyAppBundle_en_US.json > * MyAppBundle_de_DE.json > * MyAppBundle_zh_CN.json Sounds good. Will the country/dialect code be optional? If so, will it form a hierarchy, where the non-region-specific message bundle is extended by the region-specific bundle? Is this even a good idea in practice? > Some questions: > A) How do I locate the translation files at compile time? Logically the > package containing MyAppBundle.json should be scanned for all resources > matching MyAppBundle_*_*.json. Any thoughts on the best way to actually > accomplish that? You can use Reflections for this. It scans all the classes and resources at rebind time. You may have to add a Scanner implementation that remembers the location/existence of each "*.json" file during the scan. ErraiPropertyScanner[1] is an example of such a beast. > I thought I had more questions than that... :) > > Thinking ahead (not planning on this in the short term) there's a way to > hold up app initialization until async data is pulled down, right? I > saw a voting system in there. For the optional "I want to pull down > translation files asyncronously" feature, can the EntryPoint vote "no" > to the initialization until it's done pulling down the bundle? Yes, anything can call InitVotes.waitFor(someClass). This will delay initialization until a corresponding InitVotes.voteFor(someClass) happens. The only constraint is that you have to call waitFor() early enough that there are still some outstanding votes from the other components. GWT module entry point methods should always be safe, as would the constructor or @PostConstruct method of a @Singleton or @ApplicationScoped client bean. -Jonathan _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev