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" <tom.schi...@bestsolution.at>:
> 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 > e4-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/e4-dev >
_______________________________________________ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
