W tej sekcji opisano zmiany wymagane do zmodyfikowania modułu dodatkowego w wersji 3.0 w celu zaadaptowania mechanizmów i interfejsów API w wersji 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 moduły dodatkowe, 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 modułów dodatkowych. Podstawowe informacje na temat dodawania obsługi funkcji cofania do modułu dodatkowego zawiera temat dokumentacji Operacje z możliwością cofania. Moduły dodatkowe, 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 modułów dodatkowych, 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, moduły dodatkowe mogą w dalszym ciągu używać starych struktur do zarządzania historią (stos komend), ale udostępnienie interfejsu IUndoableOperation umożliwia klientom modułu dodatkowego 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 modułów dodatkowych. 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 moduły dodatkowe bez konieczności pełnej migracji modułów dodatkowych.
Po wyrażeniu operacji lub komend z możliwością cofania w ramach interfejsu IUndoableOperation można migrować moduły dodatkowe, które definiują historię cofania (stos komend) w celu śledzenia operacji z możliwością cofania i przywracania. Moduły 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 modułów dodatkowych 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 modułów dodatkowych środowiska roboczego, jak i modułów nienadzorowanych, zawiera temat dokumentacji Operacje z możliwością cofania.
W przypadku modułów dodatkowych, 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. Moduły dodatkowe 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 akcji 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 modułów dodatkowych, 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.