Steuerroutinen

org.eclipse.ui.handlers

3.1

Der Erweiterungspunkt 'Steuerroutinen' ist eine Weiterentwicklung des in Eclipse 3.0 definierten experimentellen Elements handlerSubmission. Eine Steuerroutine ist das Verhalten eines Befehls zu einem bestimmten Zeitpunkt. Einem Befehl können null oder mehr Steuerroutinen zugeordnet sein. ZU jedem Zeitpunkt jedoch hat ein Befehl keine aktive Steuerroutine oder eine aktive Steuerroutine. Die aktive Steuerroutine ist die, die gegenwärtig für die Ausführung des Verhaltens des Befehls verantwortlich ist. Dies ist dem Konzept einer Aktionssteuerroutine und einer neuabzielbaren Aktion sehr ähnlich.

Der Erweiterungspunkt 'Steuerroutinen' ermöglicht einem Plug-in-Entwickler die Angabe einer Steuerroutine, die unter bestimmten Bedingungen aktiviert und/oder deaktiviert werden soll. Wenn eine Steuerroutine inaktiv ist, dann wird kein Befehl sein Verhalten an die Steuerroutine delegieren. Wenn eine Steuerroutine deaktiviert ist, dann wird die Steuerroutine nicht darum gebeten zu arbeiten; die Ausführung der Steuerroutine wird geblockt. Die Bedingungen werden mit Hilfe der in 3.0 hinzugefügten Ausdruckssprachfunktion definiert. Sie werden mit Hilfe der Klauseln activeWhen und enabledWhen ausgedrückt.

Die Workbench stellt einige Variablen zur Verfügung, auf die diese Ausdrücke sich verlassen können. Die unterstützten Variablen sind: Die aktiven Kontexte, der aktive Editor, der aktive Abschnitt und die aktuelle Auswahl. Obwohl dies in diesem anfänglichen Entwurf nicht unterstützt wird, ist leicht zu erkennen, wie es möglich wäre, andere Variablen hinzuzufügen oder Plug-in-Entwicklern zu gestatten andere Variablen beizusteuern.

Eine Steuerroutine, die keine Bedingungen angibt, ist eine Standardsteuerroutine. Eine Standardsteuerroutine ist nur aktiv, wenn nicht alle Bedingungen einer anderen Steuerroutine erfüllt worden sind. Wenn zwei Steuerroutinen noch Bedingungen haben, die erfüllt sind, werden die Bedingungen verglichen. Die Idee ist es, eine Steuerroutine auszuwählen, deren Bedingung spezifischer oder lokaler ist. Dazu werden die Variablen betrachtet, auf die durch die Bedingung verwiesen wird. Die Bedingung, die sich auf die spezifischste Variable bezieht, "gewinnt". Die Reihenfolge der Spezifizität (von 'am unspezifischsten' bis 'am spezifischsten') wird in org.eclipse.ui.ISources definiert.

Sollte dies den Konflikt immer noch nicht lösen, dann ist keine Steuerroutine aktiviert. Wenn eine besondere Tracefunktionsangabe eingeschaltet ist, dann führt dies zu einer Nachricht im Protokoll. Ein Konflikt kann auch auftreten, wenn es zwei Standardsteuerroutinen gibt. Es liegt in der Verantwortung der Plug-in-Entwickler und Integrationstester sicherzustellen, dass dies nicht passiert. Diese Bedingungen werden verwendet, um unnötiges Laden von Plug-ins zu vermeiden. Diese Steuerroutinedefinitionen werden in ein Proxy eingeschlossen. Damit ein Proxy seine zu Grunde liegende Steuerroutine lädt, müssen zwei Dinge geschehen: Die Bedingungen für den Proxy müssen erfüllt sein, so dass er aktiv wird und der Befehl muss aufgefordert werden, etwas zu tun, das er delegieren muss (z.B. 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)>



<!ELEMENT class (parameter)>

<!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=

"selection"

>

<count value=

"1"

/>

<iterate operator=

"and"

>

<adapt type=

"IResource"

/>

</iterate>

</with>

</activeWhen>

</handler>

</extension>

Um das Laden von Plug-ins weiterhin zu vermeiden, ist es möglich anzugeben, wann die Steuerroutine aktiviert ist. Wenn der Proxy die Steuerroutine noch nicht geladen hat, wird nur die Ausdrucksyntax verwendet, um zu entscheiden, ob die Steuerroutine aktiviert ist. Wenn der Proxy die Steuerroutine geladen hat, wird die Ausdrucksyntax zuerst konsultiert. Wenn die Auswertung der Ausdrucksyntax 'true' ergibt, wird die Steuerroutine gefragt, ob sie aktiviert ist. (Dies ist eine Boolesche Kurzschluss-"und"-Operation zwischen der Syntax des Ausdrücke und dem Aktivierungsstatus der Steuerroutine.)

<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>

Alle Steuerroutinen implementieren org.eclipse.core.commands.IHandler. Innerhalb der Workbench ist es möglich, Steuerroutinen mit Hilfe der Schnittstelle org.eclipse.ui.handlers.IHandlerService zu aktivieren und zu deaktivieren. Diese Schnittstelle kann von unterstützenden Workbench-Objekten abgerufen werden, wie z.B. IWorkbench selbst. Um den Service abzurufen, würden Sie einen Aufruf wie IWorkbench.getAdapter(IHandlerService.class) vornehmen.

Es ist auch möglich, Steuerroutinen mit Hilfe von Codes aus früheren Versionen in der Workbench zu aktivieren und zu deaktivieren. Dies kann durch den folgenden traditionellen Produktmechanismus geschehen. Dieser Mechanismus ist nützlich für Clients, die Aktionen verwenden, um Hinzufügungen zu Menüs oder Symbolleisten durchzuführen.

 IWorkbenchPartSite mySite;
 IAction myAction;
 
 myAction.setActionDefinitionId(commandId);
 IKeyBindingService service = mySite.getKeyBindingService();
 service.registerAction(myAction);