Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] [Proposal] Locale switching

MUILabel extends MLocalizable
MCommand extends MLocalizable
...

Tom

On 03.12.13 23:17, Dirk Fauth wrote:
> Ok I see. So for the feature I think I got it.
> 
> "Yes the whole point about this is that not only stuff on MUILabled needs
> to allow localization!"
> 
> So should MUILabel extend MLocalizeable or should they be separated.
> Both are interfaces, so MUILabel extends MLocalizeable would be
> possible. But should it be that way or should the model element specify
> if it is a localizeable label?
> 
> 
> On Tue, Dec 3, 2013 at 10:55 PM, Tom Schindl
> <tom.schindl@xxxxxxxxxxxxxxx <mailto:tom.schindl@xxxxxxxxxxxxxxx>> wrote:
> 
>     On 03.12.13 21:41, Dirk Fauth wrote:
>     > 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.
> 
>     It's not a specialized the getLabel() method IS NOT delegating to the
>     localized one, how we one get the real value key e.g. in the tooling,
>     not to mention that XMI-Serialization would persit the real value on
>     shutdown instead of the key, ... .
> 
>     >
>     > 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.
> 
>     See above you can not delegate from getLabel() to the localized one!
> 
>     >
>     > 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?
>     >
> 
>     Yes the whole point about this is that not only stuff on MUILabled needs
>     to allow localization!
> 
>     Tom
>     _______________________________________________
>     e4-dev mailing list
>     e4-dev@xxxxxxxxxxx <mailto: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
> 



Back to the top