The [1] in my previous message was supposed to point at: [1]: https://github.com/errai/errai/blob/master/errai-common/src/main/java/org/jboss/errai/common/metadata/ErraiPropertyScanner.java
-Jonathan On 2013-03-25, at 1:23 PM, Jonathan Fuerth wrote: > 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/errai-dev
_______________________________________________ errai-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/errai-dev
