<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The [1] in my previous message was supposed to point at:<div><br></div><div>[1]: <a href="https://github.com/errai/errai/blob/master/errai-common/src/main/java/org/jboss/errai/common/metadata/ErraiPropertyScanner.java">https://github.com/errai/errai/blob/master/errai-common/src/main/java/org/jboss/errai/common/metadata/ErraiPropertyScanner.java</a></div><div><br></div><div>-Jonathan</div><div><br><div><div>On 2013-03-25, at 1:23 PM, Jonathan Fuerth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 2013-03-25, at 12:40 PM, Eric Wittmann wrote:<br><br><blockquote type="cite">Hello everyone. I'm finally putting hands to keyboard on this, and am <br></blockquote><blockquote type="cite">making some progress figuring out how a lot of the code generation works <br></blockquote><blockquote type="cite">in Errai. It's a bit slow going for me, but it gets easier every...hour. :)<br></blockquote><br>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.<br><br><blockquote type="cite">Anyway, the first aspect of this that I'm tackling is the creation and <br></blockquote><blockquote type="cite">inclusion of the message bundle file. We tentatively decided to use the <br></blockquote><blockquote type="cite">standard resource loading mechanism in GWT (the same thing the template <br></blockquote><blockquote type="cite">system uses) to load the message bundle. I'm hoping that we'll <br></blockquote><blockquote type="cite">eventually have something that will work either statically or <br></blockquote><blockquote type="cite">dynamically (giving devs that option). But for now I'm sticking with <br></blockquote><blockquote type="cite">static loading of the bundle file.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Here are some initial decisions:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">1) You active i18n support in your module by annotating your @EntryPoint <br></blockquote><blockquote type="cite">with @Bundle, providing the name of the bundle resource in the @Bundle <br></blockquote><blockquote type="cite">annotation.<br></blockquote><blockquote type="cite">2) Each GWT module has at most one i18n message bundle.<br></blockquote><blockquote type="cite">3) The bundle resource is a JSON formatted file. No one likes <br></blockquote><blockquote type="cite">Properties files, and browsers are pretty darn good at processing JSON I <br></blockquote><blockquote type="cite">imagine. That said, I'm certainly open to changing this.<br></blockquote><br>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. :)<br><br><blockquote type="cite">4) The bundle file can have any name, as long as it has a .json extension.<br></blockquote><blockquote type="cite">5) Localized versions of the bundle file look like this:<br></blockquote><blockquote type="cite"> * MyAppBundle.json<br></blockquote><blockquote type="cite"> * MyAppBundle_en_US.json<br></blockquote><blockquote type="cite"> * MyAppBundle_de_DE.json<br></blockquote><blockquote type="cite"> * MyAppBundle_zh_CN.json<br></blockquote><br>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?<br><br><blockquote type="cite">Some questions:<br></blockquote><blockquote type="cite">A) How do I locate the translation files at compile time? Logically the <br></blockquote><blockquote type="cite">package containing MyAppBundle.json should be scanned for all resources <br></blockquote><blockquote type="cite">matching MyAppBundle_*_*.json. Any thoughts on the best way to actually <br></blockquote><blockquote type="cite">accomplish that?<br></blockquote><br>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.<br><br><blockquote type="cite">I thought I had more questions than that... :)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thinking ahead (not planning on this in the short term) there's a way to <br></blockquote><blockquote type="cite">hold up app initialization until async data is pulled down, right? I <br></blockquote><blockquote type="cite">saw a voting system in there. For the optional "I want to pull down <br></blockquote><blockquote type="cite">translation files asyncronously" feature, can the EntryPoint vote "no" <br></blockquote><blockquote type="cite">to the initialization until it's done pulling down the bundle?<br></blockquote><br>Yes, anything can call InitVotes.waitFor(someClass). This will delay initialization until a corresponding InitVotes.voteFor(someClass) happens.<br><br>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.<br><br>-Jonathan<br><br><br>_______________________________________________<br>errai-dev mailing list<br><a href="mailto:errai-dev@lists.jboss.org">errai-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/errai-dev<br></div></blockquote></div><br></div></body></html>