Punkt rozszerzenia procedur obsługi jest opracowaniem eksperymentalnego elementu handlerSubmission
zdefiniowanego w platformie Eclipse 3.0. Procedura obsługi określa zachowanie komendy w konkretnym momencie.
Komenda może nie mieć powiązanych z nią procedur obsługi lub może mieć ich kilka. Jednak w każdym momencie
komenda będzie miała jedną aktywną procedurę obsługi lub nie będzie miała żadnej aktywnej. Aktywna procedura
obsługi to ta, która odpowiada w danej chwili za realizację zachowania komendy. Koncepcja procedur obsługi jest
bardzo podobna do procedur obsługi akcji oraz akcji o zmiennym celu.
Punkt rozszerzenia procedur obsługi umożliwia programiście modułu dodatkowego
określenie procedury obsługi aktywowanej i/lub włączanej w określonych warunkach.
Jeśli procedura obsługi jest nieaktywna, wówczas żadna komenda nie przekaże do niej swojego zachowania.
Jeśli procedura obsługi jest wyłączona, to nie zostanie wysłane do niej żądanie wykonania;
wykonanie procedury obsługi będzie zablokowane. Warunki są definiowane przy użyciu narzędzia
języka wyrażeń dodanego w wersji 3.0. Są one wyrażane przy użyciu klauzul activeWhen
i enabledWhen
.
Środowisko robocze udostępnia pewne zmienne, które mogą być stosowane w tych wyrażeniach. Obsługiwane zmienne to: aktywne konteksty, aktywny edytor, aktywna część oraz bieżący wybór. Mimo że w tym początkowym projekcie inne zmienne nie są obsługiwane, łatwo jest się przekonać, w jaki sposób można by je dodawać lub nawet umożliwić ich wnoszenie przez programistów modułów dodatkowych.
Procedura obsługi nieokreślająca żadnych warunków jest procedurą domyślną. Domyślna procedura obsługi jest aktywna tylko w przypadku,
gdy nie są spełnione wszystkie warunki innych procedur. Jeśli spełnione są wszystkie warunki dwóch procedur obsługi,
wówczas te warunki są porównywane. Wybierana jest wtedy procedura obsługi, której warunek jest bardziej precyzyjny lub
bardziej lokalny. W tym celu analizowane są zmienne, do których odwołuje się dany warunek. Wybierany jest warunek,
który odwołuje się do najbardziej precyzyjnej zmiennej. Porządek poziomów precyzji (od najniższego do najwyższego)
jest zdefiniowany w interfejsie org.eclipse.ui.ISources
.
Jeśli to nadal nie rozwiązuje konfliktu, wówczas żadna procedura obsługi nie będzie aktywna. Jeśli włączona jest odpowiednia opcja śledzenia, spowoduje to zapisanie komunikatu w protokole. Konflikt może wystąpić również, gdy istnieją dwie domyślne procedury obsługi. Do programistów modułów dodatkowych oraz testerów integracji należy zapewnienie, aby tak się nie stało. Omawiane warunki pozwalają uniknąć niepotrzebnego ładowania modułu dodatkowego. Definicje procedur obsługi są opakowane w serwer proxy. Aby możliwe było załadowanie bazowej procedury obsługi serwera proxy, muszą zaistnieć dwie okoliczności: spełnione muszą zostać warunki dla serwera proxy (aby stał się on aktywny) oraz wydana musi zostać komenda w celu przeprowadzenia delegowanej czynności (np. execute()).
<!ELEMENT extension (handler)>
<!ATTLIST extension
point CDATA #REQUIRED
id CDATA #IMPLIED
name CDATA #IMPLIED>
<!ELEMENT handler (activeWhen? | class? | enabledWhen?)>
<!ATTLIST handler
commandId CDATA #REQUIRED
class CDATA #IMPLIED>
<!ELEMENT activeWhen (not | and | or | instanceof | test | systemTest | equals | count | with | resolve | adapt | iterate)>
<!ELEMENT enabledWhen (not | and | or | instanceof | test | systemTest | equals | count | with | resolve | adapt | iterate)>
<!ATTLIST class
class CDATA #IMPLIED>
<!ELEMENT parameter EMPTY>
<!ATTLIST parameter
name CDATA #REQUIRED
value CDATA #REQUIRED>
<extension point=
"org.eclipse.ui.handlers"
>
<handler commandId=
"commandId"
class=
"org.eclipse.compare.Command"
>
<activeWhen>
<with variable=
"Wybór"
>
<count value=
"1"
/>
<iterate operator=
"and"
>
<adapt type=
"IResource"
/>
</iterate>
</with>
</activeWhen>
</handler>
</extension>
Aby dodatkowo uniknąć ładowania modułu dodatkowego, można określić, kiedy procedura obsługi ma być włączona. Jeśli serwer proxy nie załadował jeszcze procedury obsługi, to do określenia, czy procedura obsługi ma zostać włączona służy tylko składnia wyrażeń. Po załadowaniu procedury obsługi przez serwer proxy składnia wyrażeń jest sprawdzana w pierwszej kolejności. Jeśli składnia wyrażeń przyjmuje wartość true, to do procedury obsługi wysyłane jest pytanie, czy jest włączona (między składnią wyrażeń a stanem włączenia procedury obsługi zachodzi boolowska operacja and o niepełnym wartościowaniu).
<extension point=
"org.eclipse.ui.handlers"
>
<handler commandId=
"commandId"
class=
"org.eclipse.Handler"
>
<enabledWhen>
<with variable=
"context"
>
<property id=
"id"
value=
"debugging"
/>
</with>
</enabledWhen>
</handler>
</extension>
Wszystkie procedury obsługi implementują interfejs org.eclipse.core.commands.IHandler
.
W obrębie środowiska roboczego można aktywować oraz dezaktywować procedury obsługi przy użyciu interfejsu
org.eclipse.ui.handlers.IHandlerService
. Ten interfejs może zostać pobrany z obiektów obsługujących
środowisko robocze, takich jak sam interfejs IWorkbench
. Aby pobrać usługę, należy użyć na
przykład takiego wywołania: IWorkbench.getAdapter(IHandlerService.class)
.
Procedury obsługi można również aktywować i dezaktywować przy użyciu wcześniejszego kodu środowiska roboczego. Można to zrobić przy użyciu wcześniejszego mechanizmu przedstawionego poniżej. Ten mechanizm jest przydatny dla klientów, którzy używają akcji w celu wnoszenia do menu lub pasków narzędzi.
IWorkbenchPartSite mySite; IAction myAction; myAction.setActionDefinitionId(commandId); IKeyBindingService service = mySite.getKeyBindingService(); service.registerAction(myAction);
Copyright (c) 2005 IBM Corporation i inne podmioty.
Wszelkie prawa zastrzeżone. Program ten oraz towarzyszące mu materiały są udostępniane na warunkach
licencji EPL (Eclipse Public License), wersja 1.0, dołączonej do nich i
dostępnej pod adresem http://www.eclipse.org/legal/epl-v10.html.