+1 on building it as a service. +1 on keeping the switchContextLanguage. With a good javadoc to describe it I don't think it hurts to have it there.
Sopot On Wed, Nov 20, 2013 at 1:14 AM, Tom Schindl <[email protected]>wrote: > On 20.11.13 00:55, Markus Alexander Kuppe wrote: > > On 11/20/2013 12:31 AM, Tom Schindl wrote: > >> c) Language switching is provided to clients through > >> LocaleSwitchService. A first draft looks like this: > >> > >> interface LocaleSwitchService { > >> public void switchApplicationLanguage(Locale locale); > >> public void switchContextLanguage(IEclipseContext c,Locale > locale); > >> } > >> > >> I'm a bit indifferent on switchContextLanguage because I don't feel > >> comfortable exposing the IEclipseContext in any API and I'm uncertain > >> switching the language at a certain context is the 99% case. I currently > >> lean towards switchApplicationLanguage. > > > > Hi Tom & Dirk, > > > > why the need for LSS? Is it juts going to be a thin layer (without extra > > functionality) on top of the current > > anIEclipseContext.set(TranslationService.LOCALE, > "en_US")? > > We want to free the user to know that: > a) in which context he has to push the locale (in case of the > Application switch) > b) that he should send out the event > > Most people don't really bother how the locale stuff is working > internally, all they want is to switch the applications UI-Locale. > > > > > If yes, then it certainly makes sense to use variant a) to hide IEC from > > consumer API. OTOH I'm skeptical that IEC can be hidden from consumer > > API generally and will simply leak into consumer code because it is > > neither internal nor marked @noreference. > > It is ok in certain situations but it should be generally avoided in our > APIs. Most of the time people currently access the IEC is when they need > to publish stuff. I have experimental work in my workspace which frees > you from this by representing the value as an observable (IObservable / > JavaFX-ObjectProperty). > > The idea is that you can write code like this in future: > > @Inject > @ContextValue(contextKey="currentPerson") > ContextBoundValue<Person> contextValue; > > ListViewer v; > > public void binding(DatabindingContext dbc) { > dbc.bindValue( > ViewerProperties.singleSelection().observe(v), > contextValue.adapt(IObservableValue.class) > ); > } > > or maybe even > > @Inject > @ContextValue(contextKey="currentPerson") > IObservableValue contextValue; > > > > 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
