6:23 p.m.
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