[errai-dev] Errai UI i18n Approach & Questions

Lincoln Baxter, III lincolnbaxter at gmail.com
Thu Mar 28 09:52:42 EDT 2013 

I really like that approach. Yes. I think it makes a lot of sense to do
aggregation in combination with a template-specific @Bundle annotation.
Actually, if we are going this far, we *could* actually re-use the
@Templated annotation itself, merely with an annotation and default value.
Note that there is one down-side.

@Templated("layouts/template.html")
@Templated(value="layouts/mytemplate.html", bundle="i18n/mytemplate.txt")

The benefit of @Bundle is that you do not need to specify a value=""
attribute in order to be able to access the bundle="" attribute.

@Bundle("i18n/mytemplate.txt")
@Templated("layouts/template.html")



On Thu, Mar 28, 2013 at 7:34 AM, Eric Wittmann <eric.wittmann at redhat.com>wrote:

> +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 at redhat.com>
> 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 <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
> >>>
> >> _______________________________________________
> >> errai-dev mailing list
> >> 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
> >
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130328/a037dc3a/attachment-0001.html

More information about the errai-dev mailing list