Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] [Proposal] Locale switching
+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 <tom.schindl@xxxxxxxxxxxxxxx> 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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev

Back to the top