[errai-dev] Errai UI i18n Approach & Questions

Eric Wittmann eric.wittmann at redhat.com
Wed Mar 27 16:00:18 EDT 2013


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 <eric.wittmann at redhat.com
> <mailto:eric.wittmann at 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 at redhat.com
>>> <mailto:csadilek at redhat.com>
>>> <mailto:csadilek at 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/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 <eric.wittmann at redhat.com
>>>> <mailto:eric.wittmann at 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 at redhat.com
>>>>>> <mailto:eric.wittmann at 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 at redhat.com <mailto:eric.wittmann at redhat.com>
>>>>>>>> <mailto:eric.wittmann at 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_Ki2nYAh9qxY/pub
>>>>>>>>
>>>>>>>>   -Eric
>>>>>>>>   _______________________________________________
>>>>>>>>   errai-dev mailing list
>>>>>>>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>>>>>>> <mailto:errai-dev at 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 at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> errai-dev mailing list
>>>>>>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> errai-dev mailing list
>>>>>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev
>>>>>>
>>>>> _______________________________________________
>>>>> errai-dev mailing list
>>>>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> errai-dev mailing list
>>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/errai-dev
>>>
>> _______________________________________________
>> errai-dev mailing list
>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/errai-dev
>
>
>
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev
>


More information about the errai-dev mailing list