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 <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>> 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_Ki2nY... -Eric _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/errai-dev -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev

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 <eric.wittmann(a)redhat.com&gt; 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 >> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>> 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_Ki2nY... >> >> -Eric >> _______________________________________________ >> errai-dev mailing list >> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/errai-dev >> >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> >> >> _______________________________________________ >> errai-dev mailing list >> errai-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/errai-dev >> > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/errai-dev _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev

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/jbo... Another option is to make use of the InitVotes system: https://github.com/errai/errai/blob/master/errai-common/src/main/java/org... 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 <eric.wittmann(a)redhat.com&gt; 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 <eric.wittmann(a)redhat.com&gt; 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 >>>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>> 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_Ki2nY... >>>> >>>> -Eric >>>> _______________________________________________ >>>> errai-dev mailing list >>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>> >>>> >>>> >>>> >>>> -- >>>> Lincoln Baxter, III >>>> http://ocpsoft.org >>>> "Simpler is better." >>>> >>>> >>>> _______________________________________________ >>>> errai-dev mailing list >>>> errai-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>> >>> _______________________________________________ >>> errai-dev mailing list >>> errai-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/errai-dev >> >> >> _______________________________________________ >> errai-dev mailing list >> errai-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/errai-dev >> > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/errai-dev

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 <csadilek(a)redhat.com > <mailto:csadilek@redhat.com>> 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/jbo... >> >> Another option is to make use of the InitVotes system: >> https://github.com/errai/errai/blob/master/errai-common/src/main/java/org... >> >> 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 <eric.wittmann(a)redhat.com >> <mailto:eric.wittmann@redhat.com>> 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 <eric.wittmann(a)redhat.com >>>> <mailto:eric.wittmann@redhat.com>> 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 >>>>>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >>>>>> <mailto:eric.wittmann@redhat.com>> 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_Ki2nY... >>>>>> >>>>>> -Eric >>>>>> _______________________________________________ >>>>>> errai-dev mailing list >>>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>>> <mailto:errai-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Lincoln Baxter, III >>>>>> http://ocpsoft.org <http://ocpsoft.org/> >>>>>> "Simpler is better." >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> errai-dev mailing list >>>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>> >>>>> _______________________________________________ >>>>> errai-dev mailing list >>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>> >>>> >>>> _______________________________________________ >>>> errai-dev mailing list >>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>> >>> _______________________________________________ >>> errai-dev mailing list >>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/errai-dev >> > > > > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/errai-dev > _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev

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/jb... > <https://github.com/errai/errai/blob/3.0/errai-common/src/main/java/org/jb... > <https://github.com/errai/errai/blob/3.0/errai-common/src/main/java/org/jb... > > 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 <eric.wittmann(a)redhat.com > <mailto:eric.wittmann@redhat.com>> 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 <csadilek(a)redhat.com >>> <mailto:csadilek@redhat.com> >>> <mailto:csadilek@redhat.com>> 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/jbo... >>>> >>>> Another option is to make use of the InitVotes system: >>>> https://github.com/errai/errai/blob/master/errai-common/src/main/java/org... >>>> >>>> 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 <eric.wittmann(a)redhat.com >>>> <mailto:eric.wittmann@redhat.com>> 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 <eric.wittmann(a)redhat.com >>>>>> <mailto:eric.wittmann@redhat.com>> 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 >>>>>>>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >>>>>>>> <mailto:eric.wittmann@redhat.com>> 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_Ki2nY... >>>>>>>> >>>>>>>> -Eric >>>>>>>> _______________________________________________ >>>>>>>> errai-dev mailing list >>>>>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>>>>> <mailto:errai-dev@lists.jboss.org> >>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Lincoln Baxter, III >>>>>>>> http://ocpsoft.org <http://ocpsoft.org/> >>>>>>>> "Simpler is better." >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> errai-dev mailing list >>>>>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> errai-dev mailing list >>>>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> errai-dev mailing list >>>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>> >>>>> _______________________________________________ >>>>> errai-dev mailing list >>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> errai-dev mailing list >>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >> _______________________________________________ >> errai-dev mailing list >> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/errai-dev > > > > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/errai-dev > _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev

+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 <eric.wittmann(a)redhat.com&gt; 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/jb... >>> < https://github.com/errai/errai/blob/3.0/errai-common/src/main/java/org/jb... >/RebindUtils.java >>> < https://github.com/errai/errai/blob/3.0/errai-common/src/main/java/org/jb... > >>> >>> 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 <eric.wittmann(a)redhat.com >>> <mailto:eric.wittmann@redhat.com>> 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 <csadilek(a)redhat.com >>>>> <mailto:csadilek@redhat.com> >>>>> <mailto:csadilek@redhat.com>> 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/jbo... >>>>>> >>>>>> Another option is to make use of the InitVotes system: >>>>>> https://github.com/errai/errai/blob/master/errai-common/src/main/java/org... >>>>>> >>>>>> 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 <eric.wittmann(a)redhat.com >>>>>> <mailto:eric.wittmann@redhat.com>> 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 < eric.wittmann(a)redhat.com >>>>>>>> <mailto:eric.wittmann@redhat.com>> 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 >>>>>>>>>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >>>>>>>>>> <mailto:eric.wittmann@redhat.com>> 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_Ki2nY... >>>>>>>>>> >>>>>>>>>> -Eric >>>>>>>>>> _______________________________________________ >>>>>>>>>> errai-dev mailing list >>>>>>>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>>>>>>> <mailto:errai-dev@lists.jboss.org> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Lincoln Baxter, III >>>>>>>>>> http://ocpsoft.org <http://ocpsoft.org/> >>>>>>>>>> "Simpler is better." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> errai-dev mailing list >>>>>>>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> errai-dev mailing list >>>>>>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> errai-dev mailing list >>>>>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> errai-dev mailing list >>>>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> errai-dev mailing list >>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>>> >>>> _______________________________________________ >>>> errai-dev mailing list >>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >>> >>> >>> _______________________________________________ >>> errai-dev mailing list >>> errai-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >> _______________________________________________ >> errai-dev mailing list >> errai-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/errai-dev > > > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/errai-dev > _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev