Re: [e4-dev] [Proposal] Locale switching

[Dirk Fauth <dirk.fauth@xxxxxxxxx>]

While implementing stuff as suggested some questions came to my mind.

Most of them are already answered by Tom. Many thanks for being so patient and helpful!!!

But why should we change the localize methods to features and extend the renderers to listen to those features? Technically a localized label is just a specialization of the label. And requesting the label is usually redirecting to request the localized label.

Wouldn't it be enough to implement the mixin interface and on locale changes the already bound features are updated? For example, if the locale is changed, notify the label of a part to be updated. As on notifying the label feature is asked for its value, which uses the localized label method.

For me it makes more sense to have a one to one connection between control and model attribute, while introducing the localizedLabel feature would mean to introduce a one to many relation as the label property of the composite would get notified on several feature changes. Also notifying the already existing features would reduce the amount of work for existing renderers.

Just some questions to get a better understanding of the e4 application model.

Another question is, should MUILabel extend the new mixin interface, so every MUILabel is automatically MLocalizable for example, or should they be separated?

On Mon, Dec 2, 2013 at 4:58 PM, Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx> wrote:

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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev