Re: [e4-dev] Locale changes at runtime - update

[Jonas Helming <jonas.helming@xxxxxxxxxxxxxx>]

I personally prefer either a prefix which expresses the context (e.g.
"M" for application model elements or "E" for workbench services) or no
prefix. I do not really like the "I" prefix, IMHO, it seems to be a left
over from times, when an IDE was not able to visualize the difference
between a class and an interface itself. Just my two cents...




Am 16.12.2013 14:33, schrieb Tom Schindl:
> We've used E only i the workbench. I have no strong feelings about E/I
> (generally I have both of them!).
>
> Tom
>
> On 15.12.13 18:34, Jonas Helming wrote:
>> Hi,
>>
>> thank you Dirk for the great work and thank you Tom for warpping it up!
>> Might ELocaleSwitchService be a better name for the interface to be
>> consistent with the other e4 services?
>>
>> Best Regards
>>
>> Jonas
>>
>> Am 13.12.2013 11:46, schrieb Tom Schindl:
>>> Hi,
>>>
>>> First of all a big thank to Dirk for working through this rather complex
>>> topic which has been a lot of work!
>>>
>>> What makes me a bit proud is that the archtitecture we have in e4 allows
>>> to implement something like this with justifiable cost - imagine doing this
>>>
>>> Now let me elaborate bit what the changes are and how address them. I
>>> guess this should make it easier to understand the patch.
>>>
>>> a) The model changes
>>> --------------------
>>> Until today the localization was done through EOperations (=Methods)
>>> defined in our Ecore model. We have changed that so that those are
>>> volatile, transient, derived, unchangeable EStructuralFeatures who from
>>> an API point of view are identical to the EOperations previously defined
>>> e.g. in MUILabel hence our API is not broken!
>>>
>>> The reason we change to EStructuralFeatures is that we can now send out
>>> Notifications about the changes who are then going directly through our
>>> Event-System.
>>>
>>> To mark EClasses who hold localizable informations and to inform them
>>> externally about a changed locale we introduced a new Mixin named
>>> Localizable who has a method named updateLocalization().
>>>
>>> This allows use the generically search the model for model elements
>>> effected by a locale change and force them sending out updates. There's
>>> a very small potential that this breaks backwards compat if people have
>>> extended our Ecore in a way like this:
>>>
>>> MySpecialPart superTypes [*MySuperClass*, Part]
>>>
>>> so the generated java code will look like this:
>>>
>>> class MySpecialPartImpl extends MySuperClassImpl implements MPart {
>>> }
>>>
>>> I don't really think that we should bother with those who have extended
>>> our ecore because a similar source incompatible change was made with
>>> TrimElement - let me restate the breakage is ONLY for people who
>>> extended our Ecore (and even there those who did it in a sensible way
>>> would not be affected)
>>>
>>> b) Local change propagation
>>> ---------------------------
>>> The central point to switch the locale is ILocaleChangeService which is
>>> not implemented at the OSGi-Level but through a ContextFunction which is
>>> implemented in ui.workbench.
>>>
>>> It allows to switch the locale at the application, as well as the
>>> context level and the implemention does 2 things:
>>> - it will inform *all* model elements of an application who implement
>>>    MLocalization about the change
>>> - posts an event on the event broker
>>>
>>> c) Local change consumption:
>>> ----------------------------
>>> There are 3 ways one can get informed about a local change:
>>> - Through the event-broker by listening to the topic
>>>   org/eclipse/e4/core/NLS/LOCALE_CHANGE
>>>
>>> - By using DI and make your bean get TranslationService.LOCALE injected
>>>   => the new message system Dirk & me introduced does use this and
>>>      you'll get an update Message-Instance injected!
>>>
>>> - Attaching to the model events listening to the LOCALIZED-Features we
>>>   introduced instead of the EOperations from above
>>>   => the renderers have to be modified to listen to the LOCALIZED-
>>>      Features!
>>>
>>> I hope you followed along until this point but I felt you need to get
>>> some background on what Dirk did and why he did it this way.
>>>
>>> My plan is to get this in very early in the M5 cycle immediately after
>>> M4 has been declared unless someone speaks up. We have to file a CQ
>>> because of the size of the contribution. I guess I should go ahead with
>>> that once we managed to have consensus if this initial bits are ready to
>>> go in
>>>
>>> Like the split editors in the IDE world this has been the most requested
>>> feature in RCP applications I encountered in my past ~10 years of
>>> Eclipse RCP consulting.
>>>
>>> Tom
>>>
>>> On 13.12.13 10:08, Dirk Fauth wrote:
>>>> Hi everybody,
>>>>
>>>> with the help of Tom regarding the internals of the application model
>>>> and more, I was finally able to add the support for Locale changes at
>>>> runtime to the application model.
>>>>
>>>>
>>>> This is the ticket for the enhancement:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=423991
>>>>
>>>> These are the Gerrit changes containing my contribution:
>>>> https://git.eclipse.org/r/#/c/19743/
>>>> https://git.eclipse.org/r/#/c/19746/
>>>>
>>>> I added the ILocaleChangeService that can be injected and used to change
>>>> the Locale.
>>>> I removed all getLocalizedXxx() methods in the application model and
>>>> replaced them with corresponding attributes.
>>>> I modified the renderers to listen for the LOCALIZED events.
>>>>
>>>> I attached an example project to show the new message extension and the
>>>> locale changes at runtime in the application model. I will push this
>>>> example to GitHub if my contribution gets accepted.
>>>>
>>>> Hope you like it.
>>>>
>>>> Greez,
>>>> Dirk
>>>>
>>>>
>>>> _______________________________________________
>>>> e4-dev mailing list
>>>> e4-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>>>
>>> _______________________________________________
>>> e4-dev mailing list
>>> e4-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev