Ok my bad. Still I think our stuff should live on the application level! Tom
Von meinem iPhone gesendet > Am 02.12.2013 um 21:33 schrieb Dirk Fauth <[email protected]>: > > In LocalizationHelper the nearest context is used to get the > TranslationService AFAICS. And the TranslationService resides by default in > the service context. The model itself does not lookup the locale. It's the > TranslationService. And the TranslationService does not perform a lookup, it > gets the Locale injected as field. > > >> On Mon, Dec 2, 2013 at 9:13 PM, Tom Schindl <[email protected]> >> wrote: >> If you look how the localize methods in the model they look up the locale >> you'll notice that the look at the nearest context, IIRC >> >> Tom >> >> >> >> Von meinem iPhone gesendet >> >>> Am 02.12.2013 um 21:03 schrieb Dirk Fauth <[email protected]>: >>> >> >>> For the context stuff: >>> >>> In E4Application.createDefaultHeadlessContext() the Locale value is set to >>> the service context. >>> >>> IEclipseContext serviceContext = E4Workbench.getServiceContext(); >>> ... >>> String locale = Locale.getDefault().toString(); >>> serviceContext.set(TranslationService.LOCALE, locale); >>> TranslationService bundleTranslationProvider = >>> TranslationProviderFactory.bundleTranslationService(serviceContext); >>> serviceContext.set(TranslationService.class, bundleTranslationProvider); >>> >>> If I set the value for TranslationService.LOCALE to the application >>> context, the application model is not changing the localized values. If I >>> set it to the service context, it works. >>> >>> If I understand it correctly, than the TranslationService is lying in the >>> service context. Therefore it does not know about the application context. >>> And therefore the model only knows about the Locale in the service context. >>> Does that make sense? >>> >>> >>>> On Mon, Dec 2, 2013 at 6:14 PM, Dirk Fauth <[email protected]> wrote: >>>> My understanding of the model is yet not deep enough. I guess I need some >>>> more detailed information on how to do this. :-( >>>> >>>> Am 02.12.2013 16:58 schrieb "Tom Schindl" <[email protected]>: >>>> >>>>> On 02.12.13 16:49, Dirk Fauth wrote: >>>>> > Hi, >>>>> > >>>>> > I worked on the LocaleChangeService with feedback from Tom. Several >>>>> > facts: >>>>> > >>>>> > 1. The LocaleChangeService is not a OSGi service, but will be created >>>>> > via context function. >>>>> > 2. It has additional methods for setting the Locale via String, which is >>>>> > in respect to the TranslationService.LOCALE that is represented as >>>>> > String also. >>>>> > 3. There is an event fired on Locale change. >>>>> > 4. The model update is triggered directly (so the event might not be >>>>> > necessary, but who knows all use cases a user might have). >>>>> > 5. The Locale needs to be set to the OSGi context and not the >>>>> > application context, as the model seems to only checking the OSGi >>>>> > context. >>>>> > >>>>> > I've implemented some functionality that iterates over the model below >>>>> > the MApplication and filters out all MUILabel elements. It then exectues >>>>> > EMF notifications to update the UI. So the update can be triggered via >>>>> > model and it is not necessary to listen for events in the renderers, >>>>> > which should simplify things a lot. >>>>> > >>>>> > This works fine so far, but at this point the implementation gets ... >>>>> > well ... kind of ugly. I need to determine the concrete model >>>>> > implementation as I need to specify the EMF notification feature ID >>>>> > which is tight connected to the model. For example, to execute the EMF >>>>> > notification for the label of a MPart you need to execute eNotify() on >>>>> > PartImpl like this >>>>> > >>>>> > PartImpl impl = (PartImpl) element; >>>>> > impl.eNotify(new ENotificationImpl(impl, Notification.SET, >>>>> > BasicPackageImpl.PART__LABEL, oldLabel, label)); >>>>> > >>>>> > I wouldn't need to cast directly to PartImpl. Usually UIElementImpl >>>>> > should be good enough to call eNotify(), but I need to know about the >>>>> > BasicPackageImpl.PART__LABEL feature id. >>>>> > >>>>> > This would leave me to implement a set of instanceof checks for every >>>>> > model element, so I know what feature needs to be updated in detail. >>>>> > Isn't there a more generic way to execute a notification that the label >>>>> > needs to be updated? >>>>> > >>>>> > Another idea would be to extend the MUILabel to contain a >>>>> > updateLocalization() method or something like that, that hides the >>>>> > implementation about what needs to be done for updateing such >>>>> > information. This would also allow the implementations to override, as >>>>> > for example parts also come with descriptions that are able to be >>>>> > localized and that are not specified in MUILabel. Would that make sense? >>>>> > >>>>> > What do you think? Any help or idea is appreciated. I implemented the >>>>> > locale change already for MWindow and MPart (which is easy when you only >>>>> > need to implement at one place), and it works very nice. Would love to >>>>> > finish this in the right way to get the locale change feature completely >>>>> > done for Luna. >>>>> > >>>>> >>>>> We can solve all of this with: >>>>> a) make the localize* attributes volatile, transient, derived features >>>>> b) introduce a mixin interface with your proposed method >>>>> c) make MUILabel implement the mixin >>>>> => send out events derived features >>>>> d) make the renderers listen to new volatile features >>>>> >>>>> The advantage is that people deriving from our model can implement our >>>>> mixin and do the appropriate thing. >>>>> >>>>> Tom >>>>> _______________________________________________ >>>>> e4-dev mailing list >>>>> [email protected] >>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>> >>> _______________________________________________ >>> e4-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/e4-dev >> >> _______________________________________________ >> e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/e4-dev > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
