+1 to aggregating the bundles. When generating the i18n key, how about I use the name of the template as the prefix (without the .html)?
I'm ambivalent towards a convention for the bundle. Sounds like a reasonable thing to do. :) Since we won't have a notion of a module bundle, is i18n simply always active? Every template will be processed at runtime? This means the template DOM will get visited but not processed in any way. I can optimize the case where there are *no* bundles available (check the aggregate for # of keys - if zero, do not process). That seems fine. I like it. It shall be done. -Eric On 03/27/2013 05:05 PM, Christian Sadilek wrote: > I am starting to believe a slight deviation of the proposal will avoid this > problem. > > - We could introduce a convention for the module's bundle name (e.g. > errai-constants or errai-i18n) > > - The name can be overwritten using the @Bundle annotation on the EntryPoint > but that would be optional then > > - We'd aggregate these module bundles > > - In the templates it makes sense to prefix the keys anyways which will avoid > duplicates (e.g. orderform.customer.name instead of just name) > > - In case of duplicates we can fail at compile time (when processing a > template and finding an actual name clash) > > - We'd also allow the @Bundle annotation on templates to specify a > template-specific bundle. This makes sense for templates having tons of > fields. So, one wouldn't end up with a huge bundle file which is hard to > maintain. It will also solve the problem where duplicates can't be avoided > (e.g. 2 different order forms). > > So, we'd still have one bundle per module by default but add the flexibility > to specify template-specific bundles if needed. We'd aggregate the module > bundles of all inherited modules, so the lookup doesn't have to worry about > finding the bundle in the corresponding module (or super module). This also > allows for the introduction of a super bundles that define values like OK, > Cancel etc. in multiple languages. > > Does that make sense? > > Cheers, > Christian > > On 2013-03-27, at 4:00 PM, Eric Wittmann <[email protected]> wrote: > >> Ok great, thanks! Of course, we can decide against the One Bundle Per >> Module approach. But I think it makes sense. >> >> -Eric >> >> On 03/27/2013 03:06 PM, Christian Sadilek wrote: >>> About the other 2 :). Both seem to boil down to the same type of >>> problem. How do I, for a given MetaClass instance, find out which module >>> they were defined in. >>> >>> I don't know the answer. I am currently digging into the GWT internals. >>> >>> If there's no way to do it we'd need to implement something ourselves. >>> We already scan all module xml files for source paths (see >>> RebindUtils::getOuterTranslatablePackages): >>> https://github.com/errai/errai/blob/3.0/errai-common/src/main/java/org/jboss/errai/common/metadata >>> <https://github.com/errai/errai/blob/3.0/errai-common/src/main/java/org/jboss/errai/common/metadata/RebindUtils.java>/RebindUtils.java >>> <https://github.com/errai/errai/blob/3.0/errai-common/src/main/java/org/jboss/errai/common/metadata/RebindUtils.java> >>> >>> Combined with the MetaDataScanner that knows where the @Templated class >>> is, we should be able to come up with a solution. >>> >>> I am still digging though…. >>> >>> Christian >>> >>> On 2013-03-27, at 2:12 PM, Eric Wittmann <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> Ah ha. That makes sense. In any case, all @ApplicationScoped beans by >>>> definition (I assume) would be loaded and available by the time any >>>> templates were being rendered (regardless of the presence of @LoadAsync). >>>> >>>> I think this question is put to bed. :) Thanks. >>>> >>>> Now what about the other 2? :) >>>> >>>> -Eric >>>> >>>> On 03/27/2013 02:09 PM, Christian Sadilek wrote: >>>>> However, only a bean annotated with @LoadAsync can possibly be loaded >>>>> asynchronously. So, if you just look up your own bean within >>>>> TemplateUtil and that bean is not annotated with @LoadAsync, you should >>>>> be fine. The callback will always be invoked synchronously then. >>>>> >>>>> Christian >>>>> >>>>> On 2013-03-27, at 1:44 PM, Christian Sadilek <[email protected] >>>>> <mailto:[email protected]> >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>>> If async IOC is active, the callback will be invoked asynchronously >>>>>> (at least when it first downloads the source for the corresponding >>>>>> bean). You can take a look at the new ListWidget implementation which >>>>>> needs to wait until all callbacks have been executed as well: >>>>>> https://github.com/errai/errai/blob/master/errai-ui/src/main/java/org/jboss/errai/ui/client/widget/ListWidget.java >>>>>> >>>>>> Another option is to make use of the InitVotes system: >>>>>> https://github.com/errai/errai/blob/master/errai-common/src/main/java/org/jboss/errai/common/client/api/extension/InitVotes.java >>>>>> >>>>>> This is unfortunate but there seems to be no way around it when >>>>>> supporting async bean management. >>>>>> >>>>>> Cheers, >>>>>> Christian >>>>>> >>>>>> On 2013-03-27, at 1:29 PM, Eric Wittmann <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>>> Is the bean lookup going to be done synchronously though (regardless of >>>>>>> the impl)? That's very important in this case. The TemplateUtil is >>>>>>> going to be invoked several times in sequence (different methods). If >>>>>>> one of the TemplateUtil methods does something asynchronously that's a >>>>>>> problem. If not, is there a wait-notify pattern that should be used? >>>>>>> >>>>>>> -Eric >>>>>>> >>>>>>> On 03/27/2013 01:24 PM, Christian Sadilek wrote: >>>>>>>> Actually we have just abstracted that. When you ask for the async >>>>>>>> bean manager IOC.getAsyncBeanManager() it will work in either case. >>>>>>>> If synchronous bean management is enabled it will return an adapter >>>>>>>> where the callback will just immediately be invoked. >>>>>>>> >>>>>>>> So, just always use the async bean manager API. That code can of >>>>>>>> course also be generated, if you wanted/needed to. >>>>>>>> >>>>>>>> On 2013-03-27, at 1:19 PM, Eric Wittmann <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>>> I think the advent of the async bean manager may have complicated >>>>>>>>> this >>>>>>>>> though, right? I don't *think* I can simply get the bean manager and >>>>>>>>> ask it for the bean (there are a couple of different getters now >>>>>>>>> - one >>>>>>>>> to get the sync bean manager and one to get the async bean manager). >>>>>>>>> >>>>>>>>> One thing I tried that worked but that I don't like: turn the >>>>>>>>> @ApplicationScoped bean into a singleton and reference it using a >>>>>>>>> static >>>>>>>>> method. Ugly but worked. Ideally I think TemplateUtil should >>>>>>>>> itself be >>>>>>>>> an injected bean, rather than a class with some static methods. >>>>>>>>> >>>>>>>>> But that just moves the problem to "how do I reference an >>>>>>>>> injected bean >>>>>>>>> in code generated by a Decorator/Extension?" :) >>>>>>>>> >>>>>>>>> On 03/27/2013 01:13 PM, Lincoln Baxter, III wrote: >>>>>>>>>> To answer Question #3, this would either need to be coded into the >>>>>>>>>> call >>>>>>>>>> to TemplateUtil from the BootstrapperImpl code (done in >>>>>>>>>> DecoratorTemplated.java) or I believe there is a convenience >>>>>>>>>> utility to >>>>>>>>>> get the BeanManager in Errai: >>>>>>>>>> >>>>>>>>>> CDI.current() or something like that. Mike? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Mar 26, 2013 at 12:20 PM, Eric Wittmann >>>>>>>>>> <[email protected] <mailto:[email protected]> >>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>> >>>>>>>>>> Hey guys. I've sketched out a proposed approach (not 100% >>>>>>>>>> compete but >>>>>>>>>> ok to start) for i18n. Would appreciate it if you could take a >>>>>>>>>> look >>>>>>>>>> at it. >>>>>>>>>> >>>>>>>>>> At the bottom you will find 3 questions that I would (in >>>>>>>>>> particular) >>>>>>>>>> love your thoughts on. >>>>>>>>>> >>>>>>>>>> https://docs.google.com/document/d/1BapD4FHMNur0OYdIg-vwXYHWW_2Mhra_Ki2nYAh9qxY/pub >>>>>>>>>> >>>>>>>>>> -Eric >>>>>>>>>> _______________________________________________ >>>>>>>>>> errai-dev mailing list >>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>> <mailto:[email protected]> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Lincoln Baxter, III >>>>>>>>>> http://ocpsoft.org <http://ocpsoft.org/> >>>>>>>>>> "Simpler is better." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> errai-dev mailing list >>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> errai-dev mailing list >>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> errai-dev mailing list >>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> errai-dev mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> errai-dev mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>> >>>> _______________________________________________ >>>> errai-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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
