Erforderliche Änderungen bei der Übernahme der 3.0-Mechanismen und -APIs

In diesem Abschnitt werden die Änderungen beschrieben, die erforderlich sind, wenn Sie versuchen, Ihre 3.0-Plug-ins für die Übernahme von 3.1-Mechanismen und -APIs zu verändern.

Unterstützung der Plattform für Widerrufen/Wiederholen

Eclipse 3.1 stellt eine neue Infrastruktur für die Definition von Widerrufbaren Unternehmensaktivitäten und ein gemeinsam genutztes Unternehmensaktivitäten-Protokoll zur Verfügung, das Unternehmensaktivitäten, die ausgeführt, widerrufen und wiederholt wurden, protokolliert. Die verschiedenen Widerrufsgerüste, die durch Add-on-Plug-ins zur Verfügung gestellt werden, sollten im Laufe der Zeit zu der Plattformbetriebsunterstützung migriert werden, so dass Clients dieser Gerüste tiefer mit der Plattform integriert werden können und ihre widerrufbaren Operationen für das Rückgängig machen in anderen Plug-in-Sichten und Editoren zur Verfügung stellen können. Grundlegende Informationen über das Hinzufügen der Widerrufsunterstützung zu einem Plug-in finden Sie in der Dokumentation Widerrufbare Unternehmensaktivitäten. Plug-ins, die die Widerrufsunterstützung bereits definieren oder ein anderes Gerüst verwenden, können schrittweise in die neue Widerrufsunterstützung migriert werden, wie in folgendem Beispiel gezeigt wird.

Migrieren plug-in-spezifischer Unternehmensaktivitäten-(Befehls-)-Klassen in IUndoableOperation

Plug-ins, die bereits Klassen definieren, die ihre widerrufbaren Unternehmensaktivitäten beschreiben, sollten eine Implementierung für die Schnittstelle IUndoableOperation in ihre Unternehmensaktivitäten-(Befehls-)-Klassen zur verfügung stellen. Plug-ins können, falls erforderlich, weiterhin ältere Gerüste für die Verwaltung des Protokolls (Befehls-Stack) verwenden, aber die Bereitstellung einer Schnittstelle für IUndoableOperation ermöglicht es den Clients eines Plug-in's, dieselben Unternehmensaktivitäten in dem Unternehmensaktivitäten-Protokoll der Plattform zu verwenden und widerrufbare Unternehmensaktivitäten von anderen Plug-ins zu mischen und abzugleichen. Diese Strategie ähnelt der, die durch SDK-Texteditoren verwendet wird, um in das neue Unternehmensaktivitätengerüst zu migrieren. Wenn eine direkte Zuordnung der Schnittstelle nicht möglich ist, können Wrapper verwendet werden, um das IUndoableOperation-Protokoll älteren Widerrufsobjekten zuzuordnen. Diese Strategie wird durch die Plattform/JDT-Refactoringunterstützung verwendet. Die Migration der Unternehmensaktivitäten-/Befehlsklassen in IUndoableOperation ist ein wichtiger Schritt, da er ermöglicht, dass die widerrufbaren Unternehmensaktivitäten ande rer Gerüste durch andere Plug-ins verwendet werden können, ohne dass jedes Plug-in vollständig migriert werden muss.

Befehlsstacks mit IOperationHistory migrieren

Nachdem widerrufbare Unternehmensaktivitäten oder Befehle in Form von IUndoableOperation ausgedrückt worden sind, können Plug-ins, die ein Widerrufsprotokoll (Befehlsstack) für die Protokollierung widerrufbarer und wiederholbarer Unternehmensaktivitäten definieren, in das Unternehmensaktivitätenprotokoll der Plattform migrieren, indem ein IUndoContext definiert wird, der ihr Widerrufsprotokoll darstellt. Widerrufsprotokolle, die zuvor lokal verwaltet worden sind, können in das gemeinsame Unternehmensaktivitätenprotokoll gemischt werden, indem entweder für jeden Abschnitt oder für jedes Modellobjekt ein eindeutiger Widerrufskontext definiert wird, der den entsprechenden Widerrufskontext einer jeden Unternehmensaktivität hinzufügt und dann die Unternehmensaktivität dem Unternehmensaktivitäten-Protokoll der Plattform hinzufügt. Widerrufsprotokolle mit globalerem Umfang können implementiert werden, indem ein eindeutiger Widerrufskontext definiert wird, der den Widerrufsumfang darstellt, der diesen Kontext einer jeden Unternehmensaktivität zuordnet, und der dann die Unternehmensaktivität dem Unternehmensaktivitätenprotokoll der Plattform hinzufügt. Beispiele für die Erstellung von Widerrufskontexten, deren Zuordnung und das Hinzufügen von Unternehmensaktivitäten zu dem Unternehmensaktivitäten-Protokoll der Plattform finden Sie in der Dokumentation Widerrufbare Unternehmensaktivitäten.

Widerrufbare Unternehmensaktivitäten global für die Workbench definieren

Plug-ins, die ihre Unternehmensaktivitäten aus den Workbench-Sichten, wie z.B. der Sicht 'Navigator' oder 'Paket-Explorer' widerrufbar machen möchten, sollten den Widerrufskontext der Workbench ihren Unternehmensaktivitäten zuordnen. Weitere Informationen über diesen Widerrufskontext und deren Abruf durch Workbench- und automatische Plug-ins finden Sie in der Dokumentation Widerrufbare Unternehmensaktivitäten.

Steuerroutinen für Widerrufs- und Wiederholaktionen

Plug-ins, die keine Widerrufsinfrastruktur oder widerrufbare Unternehmensaktivitäten definieren, die aber Zugang zu dem Widerrufsprotokoll der Plattform zur Verfügung stellen möchten, sollten eine Umlenkung der globalen Steuerroutinen für Widerrufs- und Wiederholaktionen zu den neuen allgemeinen Steuerroutinen für Widerrufs- und Wiederholaktionen in Betracht ziehen. Die Steuerroutinen sollten einem Widerrufskontext zugeordnet werden, der angibt, welches Widerrufs- und Wiederholprotokoll zu zeigen ist. Plug-ins können ihre lokal definierten Widerrufskontexte verwenden, um 'teillokale' Widerrufs- und Wiederholprotokoll zu zeigen. Der Widerrufskontext der Workbench kann verwendet werden, um das die gesamte Workbench umfassende Widerrufs- und Wiederholprotokoll zu zeigen. Ein vollständiges Beispiel finden Sie wiederum in der Dokumentation Widerrufbare Unternehmensaktivitäten.

Textoperationsaktionen in die allgemeinen Steuerroutinen für Aktionen migrieren

Das Migrieren von Widerrufs- und Wiederholaktionen eines Texteditors ist etwas anders, als das einfache Umlenken der globalen Steuerroutinen für Widerrufs- und Wiederholaktionen. Das Gerüst AbstractTextEditor definiert allgemeine Textaktionen unter Verwendung einer TextOperationAction mit Parameterangabe. Diese Aktionen werden lokal in dem Gerüst gespeichert und verwendet, um verschiedene Befehle an das Textoperationsziel eines Editors zu senden. Damit der Textwiderruf korrekt funktioniert, verlässt sich das Texteditorgerüst auf die Anwesenheit von Textoperationsaktionen mit den richtigen IDs (ITextEditorActionConstants.REDO und ITextEditorActionConstants.UNDO).

AbstractTextEditor wurde migriert, so dass die allgemeinen Steuerroutinen erstellt werden, während sie mit ihren alten IDs weiterhin der Tabelle 'TextOperationAction' zugeordnet werden. Auf diese Weise können die neuen Steuerroutinen für Widerrufs- und Wiederholaktionen unter Verwendung der alten Techniken für den Abruf der Aktion und die Durchführung einer Operation abgerufen werden. Texteditoren in der Hierarchie AbstractTextEditor übernehmen dieses Verhalten.

Editoren, die dieses Verhalten nicht vom AbstractTextEditor übernehmen, sollten die Migration aller vorhandenen Widerrufs- und Wiederholaktionen zur Verwendung der neuen Steuerroutinen in Betracht ziehen. Editoren mit alten TextOperationActions für Widerruf und Wiederholung verfügen weiterhin über lokale Widerrufsunterstützung, da die JFace-Textwiderrufsmanager-API, die durch diese Aktionen verwendet wird, weiterhin unterstützt wird. Jedoch sind die Bezeichnungen für Widerrufs- und Wiederholaktionen nicht konsistent mit den neuen Widerrufs- und Wiederholaktionen von Eclipse SDK, die den Namen der verfügbaren Widerrufs- und Wiederholoperation anzeigen. Um die allgemeinen Steuerroutinen für Widerrufs- und Wiederholaktionen zu erstellen, sollte der Widerrufskontext, der durch den Widerrufsmanager der Textanzeigefunktion verwendet wird, verwednet werden, wenn die Steuerroutinen erstellte werden, und diese Steuerroutinen sollten unter Verwendung der entsprechenden ITextEditorActionConstants-ID im Editor gesetzt werden. Ein ausführliches Beispiel finden Sie unter AbstractTextEditor.createUndoRedoActions() und AbstractTextEditor.getUndoContext(). Editoren, die sich auf eine EditorActionBarContributor-Unterklasse stützen, um zu den Aktionsleisten ihrer Editoren hinzugefügt zu werden, können eine ähnliche Technik zur Erstellung von Steuerroutinen für Widerrufs- und Wiederholaktionen und deren Einstellung, wenn der aktive Editor eingestellt ist, verwenden.

Funktionale Erweiterungen der Hilfe

Informationssuche

Plug-ins, die Suchseiten zu dem Dialog Suchen beisteuern, sollten die Portierung all ihrer informationsartigen Suchvorgänge in zusammengeschlossenen Suchmaschinen in Betracht ziehen. Ab 3.1 ist die informationsartige Suche von der Workbench-Artefakt-Suche getrennt. Informationssuchmaschinen werden parallel als Hintergrundjobs ausgeführt und ihre Ergebnisse werden in der neuen Sicht 'Hilfe' zusammengestellt. Weitere Informationen finden Sie unter Hilfe durchsuchen.

Dynamische Hilfe

Die neue Sicht 'Dynamische Hilfe' arbeitet mit vorhandenen Kontext-IDs, die den Fensterobjekten in Workbenchabschnitten und -dialogen statisch zugeordnet sind. Wenn Sie jedoch ein Hilfeereignis selbst abfangen und die Hilfe anzeigen, ist die Sicht 'Dynamsiche Hilfe' nicht in der Lage, sinnvolle Informationen anzuzeigen. Um dieses Problem zu beheben, sollten Sie die neue Schnittstelle IContextProvider anpassen, wie in dem Dokument Dynamische Kontexthilfe beschrieben wird.