W tej sekcji opisano zmiany, jakie należy wprowadzić we wtyczce w wersji 3.0, aby wykorzystać mechanizmy i interfejsy API oferowane przez wersję 3.1.
Platforma Eclipse 3.1 udostępnia nową infrastrukturę definiowania operacji z możliwością cofania i współużytkowanej historii operacji, która śledzi operacje wykonywane, cofane i przywracane. Różne struktury cofania, które są zapewniane przez wtyczki, powinny być migrowane w miarę upływu czasu w celu obsługi operacji platformy, dzięki czemu możliwe będzie lepsze zintegrowanie klientów tych struktur z platformą, a także zapewnienie możliwości cofania operacji tych struktur również w innych widokach i edytorach wtyczek. Podstawowe informacje na temat dodawania obsługi funkcji cofania do wtyczki zawiera temat dokumentacji Operacje z możliwością cofania. Wtyczki, które już definiują obsługę funkcji cofania lub używają innej struktury, mogą być migrowane w celu zapewnienia obsługi nowej funkcji cofania. Odbywa się to etapowo w sposób opisany poniżej.
W przypadku wtyczek, które już definiują klasy dla operacji z możliwością cofania, należy dodać implementację interfejsu IUndoableOperation do ich klas operacji/komend. Jeśli to konieczne, wtyczki mogą w dalszym ciągu używać starych struktur do zarządzania historią (stos komend), ale udostępnienie interfejsu IUndoableOperation umożliwia klientom wtyczki użycie tych samych operacji w historii operacji platformy, a także mieszanie i dopasowywanie operacji z możliwością cofania pochodzących z różnych wtyczek. Ta strategia przypomina migrację edytorów tekstu SDK do nowego środowiska operacji. Jeśli bezpośrednie odwzorowanie interfejsu nie jest możliwe, do odwzorowania protokołu IUndoableOperation na wcześniejsze obiekty cofania można użyć opakowań. Taka strategia jest stosowana przez funkcję obsługi refaktoryzacji Platform/JDT. Migracja klas operacji/komend do interfejsu IUndoableOperation stanowi ważny krok, ponieważ umożliwia wykorzystanie operacji z możliwością cofania pochodzących z różnych struktur przez inne wtyczki bez konieczności pełnej migracji wtyczek.
Po wyrażeniu operacji lub komend z możliwością cofania w ramach interfejsu IUndoableOperation można migrować wtyczki, które definiują historię cofania (stos komend) w celu śledzenia operacji z możliwością cofania i przywracania. Wtyczki te są migrowane do historii operacji platformy poprzez zdefiniowanie interfejsu IUndoContext, który reprezentuje historię dla opcji cofania. Historie dla opcji cofania, które wcześniej były zarządzane lokalnie, można scalić ze wspólną historią operacji poprzez zdefiniowanie unikalnego kontekstu cofania dla każdej części lub dla każdego obiektu modelu, dodając odpowiedni kontekst cofania do każdej operacji, a następnie dodając operację do historii operacji platformy. Historie dla opcji cofania o bardziej globalnym zasięgu można zaimplementować poprzez zdefiniowanie unikalnego kontekstu cofania reprezentującego ten zasięg cofania, przypisanie tego kontekstu do każdej operacji, a następnie dodanie operacji do historii operacji platformy. Przykłady tworzenia kontekstów cofania, przypisywania ich oraz dodawania operacji do historii operacji platformy znajdują się w temacie dokumentacji Operacje z możliwością cofania.
Aby możliwe było cofanie operacji wtyczek w widokach środowiska roboczego, takich jak Nawigator lub Eksplorator pakietów, należy przypisać do tych operacji kontekst cofania środowiska roboczego. Więcej informacji na temat tego kontekstu cofania i sposobu jego wydobycia zarówno dla wtyczek środowiska roboczego, jak i wtyczek nienadzorowanych, zawiera temat dokumentacji Operacje z możliwością cofania.
W przypadku wtyczek, które nie definiują infrastruktury cofania ani operacji z możliwością cofania, ale które powinny zapewniać dostęp do historii dla opcji cofania platformy, należy rozważyć zmianę celu globalnych procedur obsługi akcji cofania i przywracania za pomocą nowych procedur obsługi akcji. Do procedur obsługi akcji należy przypisać kontekst cofania określający, która historia dla opcji cofania i przywracania powinna zostać wyświetlona. Wtyczki mogą używać zdefiniowanych lokalnie własnych kontekstów cofania w celu wyświetlania "częściowo lokalnej" historii dla opcji cofania i przywracania. Kontekst cofania środowiska roboczego może zostać użyty do wyświetlania historii dla opcji cofania i przywracania dla całego środowiska roboczego. Również w tym przypadku temat dokumentacji Operacje z możliwością cofania zawiera kompletny przykład.
Migrowanie akcji cofania i przywracania edytora tekstu różni się w pewnym stopniu od prostej procedury zmiany celu globalnych procedur obsługi akcji cofania i przywracania. Struktura AbstractTextEditor definiuje wspólne akcje tekstowe korzystające ze sparametryzowanej metody TextOperationAction. Akcje te są przechowywane lokalnie w strukturze i służą do rozsyłania różnych komend do celu operacji edytora na tekście. Aby akcja cofania tekstu działała poprawnie, struktura edytora tekstu opiera się na akcjach operacji tekstowych o właściwych identyfikatorach (ITextEditorActionConstants.REDO i ITextEditorActionConstants.UNDO).
Przeprowadzona została migracja klasy AbstractTextEditor, dzięki czemu tworzy ona wspólne procedury obsługi akcji, ciągle przypisując je jednak do tabeli TextOperationAction wraz z ich wcześniejszymi identyfikatorami. W ten sposób możliwe jest wydobycie nowych procedury obsługi akcji cofania i przywracania za pomocą wcześniejszych technik służących do wydobywania akcji i wykonywania operacji. Edytory tekstu w hierarchii klasy AbstractTextEditor dziedziczą to zachowanie.
W przypadku edytorów, które nie dziedziczą tego zachowania z klasy AbstractTextEditor, należy rozważyć dokonanie migracji istniejących akcji cofania i przywracania w celu użycia nowych procedur obsługi. Edytory z wcześniejszymi akcjami cofania i przywracania TextOperationActions zapewniają obsługę lokalnej funkcji cofania, ponieważ ciągle jest obsługiwany interfejs API menedżera cofania JFace Text, który jest używany przez te akcje. Jednak etykiety akcji cofania i przywracania nie będą spójne z nowymi akcjami cofania i przywracania pakietu SDK dla platformy Eclipse, które wyświetlają nazwę dostępnej operacji cofania lub przywracania. Aby utworzyć wspólne procedury obsługi akcji cofania i przywracania, w czasie tworzenia tych procedur należy użyć kontekstu cofania, który jest używany przez menedżera cofania przeglądarki tekstu. Te procedury obsługi należy ustawić w edytorze za pomocą odpowiedniego identyfikatora ITextEditorActionConstants. Szczegółowo pokazują to metody AbstractTextEditor.createUndoRedoActions() i AbstractTextEditor.getUndoContext(). Edytory korzystające z podklasy EditorActionBarContributor w celu dodania pasków działań edytorów mogą zastosować podobną technikę poprzez utworzenie procedur obsługi akcji cofania i przywracania oraz ustawienie ich, kiedy ustawiany jest aktywny edytor.
W przypadku wtyczek, które dodają strony wyszukiwania do okna dialogowego Wyszukiwanie, należy rozważyć przeniesienie wszystkich funkcji wyszukiwania informacji do stowarzyszonych mechanizmów wyszukiwania. Począwszy od wersji 3.1 wszystkie funkcje wyszukiwania informacji zostały oddzielone od wyszukiwania artefaktów środowiska roboczego. Mechanizmy wyszukiwania informacji działają równolegle jako zadania w tle, a ich wyniki są zestawiane w nowym widoku pomocy. Więcej informacji na ten temat zawiera sekcja Wyszukiwanie w systemie pomocy.
Nowy widok pomocy dynamicznej będzie działał z istniejącymi identyfikatorami kontekstu,
które są statycznie powiązane z widgetami w częściach i oknach dialogowych środowiska roboczego.
Jeśli jednak zdarzenie pomocy zostanie przechwycone przez użytkownika i zostanie wyświetlona pomoc,
widok pomocy dynamicznej nie będzie mógł wyświetlić żadnych przydatnych informacji. Aby rozwiązać
ten problem, należy zaadoptować nowy interfejs IContextProvider
w sposób opisany
w dokumencie Dynamiczna pomoc kontekstowa.
Począwszy od wersji 3.1 element org.eclipse.jface.preference.IPreferenceStore zwracany przez metodę AbstractUIPlugin.getPreferenceStore() jest instancją klasy org.eclipse.ui.preferences.ScopedPreferenceStore. W ramach klasy ScopedPreferenceStore interfejs API org.eclipse.core.runtime.preferences jest wykorzystywany do zarządzania preferencjami. W wersji 3.0 jako interfejs z instancją pakietu org.eclipse.core.runtime.Preferences używana była warstwa zgodności.
W wersji 3.1 interfejs IPreferenceStore jest bardziej jednoznaczny i konkretny w kwestii typów wartości wysyłanych w zdarzeniach związanych ze zmianą preferencji. Interfejs IPreferenceStore metody AbstractUIPlugin#getPreferenceStore działa tak samo, jak dotychczas. Uściślono jedynie specyfikację.
Określanie typu: Interfejs org.eclipse.jface.util.IPropertyChangeListener
dodany do interfejsu IPreferenceStore może potencjalnie otrzymać dwa typy starych i nowych wartości
- reprezentacje określonego typu lub reprezentacje łańcuchowe. Dowolne zdarzenie wygenerowane przez wywołanie interfejsu API IPreferenceStore
określonego typu, takie jak metoda setValue(String key, boolean value)
wygeneruje zdarzenie określonego typu.
Istnieje jednak również możliwość, że zdarzenia będą propagowane na podstawie podstawowych preferencji środowiska wykonawczego, które służą do generowania zdarzeń o nieokreślonym typie (na przykład podczas importu preferencji). Funkcje nasłuchiwania właściwości muszą być przygotowane na obie możliwości.
Należy również zwrócić uwagę, że zdarzenia określonego typu nie będą propagowały typów podstawowych,
więc wywołanie metody setValue(String key, boolean value)
wygeneruje zdarzenie, gdzie stara i nowa wartość będą typu Boolean.
putValue: Metoda IPreferenceStore.putValue(String key, String value) nie wygeneruje zdarzenia związanego ze zmianą. Ta funkcja API jest przeznaczona dla prywatnych preferencji, na które nie zareagowałaby żadna funkcja nasłuchiwania.
initializeDefaultPreferences. Ten interfejs API stał się nieaktualny w środowisku Eclipse 3.0, ponieważ jest on wyzwalany jedynie w przypadku używania warstwy zgodności. Ponieważ większość wtyczek uzyskuje swoje składnice preferencji z metody AbstractUIPlugin#getPreferenceStore, we wcześniejszej wersji była ona wyzwalana przy uruchamianiu wtyczki. Jeśli dana wtyczka nie uzyskuje dostępu do warstwy zgodności, to ta metoda może nie zostać wyzwolona. Do obsługi procesu inicjowania preferencji zaleca się utworzenie klasy org.eclipse.core.runtime.preferences.AbstractPreferenceInitializer.