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 [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
