Tento oddíl popisuje změny, které jsou nutné, pokud se pokoušíte změnit svůj modul plug-in pro verzi 3.0 tak, aby adoptoval mechanizmy a rozhraní API verze 3.1.
Eclipse 3.1 poskytuje novou infrastrukturu pro definování vratných operací a sdílenou historii operací, pomocí které se sledují provedené operace, operace vrácené zpět, i operace provedené znovu. Různé rámce poskytované přídavnými moduly plug-in by časem měly být převedeny migrací do podpory operací platformou, aby se klienti těchto rámců mohli snáze integrovat do platformy a zpřístupnili své vratné operace pro funkci "zpět" v jiných pohledech a editorech modulů plug-in. Viz dokumentace Vratné operace, kde najdete základní informace o přidávání podpory pro funkci Zpět do modulů plug-in. Moduly plug-in, které již podporu pro funkci Zpět definují, nebo používají jiný rámec (framework), lze převést migrací do nové podpory funkce Zpět po etapách, jak je popsáno níže.
Moduly plug-in, které již definují třídy popisující jejich vratné operace by do svých tříd pro operace/příkazy měly přidat implementaci rozhraní IUndoableOperation. V případě potřeby mohou moduly plug-in i nadále používat starší rámce pro správu historie (zásobník příkazů), ale při poskytnutí rozhraní pro IUndoableOperation mohou klienti modulů plug-in používat stejné operace v historii operací platformy a míchat dohromady vratné operace z různých modulů plug-in. Tato strategie je podobná přístupu používanému v textových editorech SDK pro migraci na nový rámec operací. Pokud přímé mapování rozhraní není možné, lze použít obálky (wrappery) k mapování protokolu IUndoableOperation na objekty starší operace Zpět. Tuto strategii používá podpora opětovných deklarací platformy/JTD. Migrace tříd operací/příkazů na IUndoableOperation představuje důležitý krok, protože umožňuje využívat vratné operace z různých rámců (framework) jinými moduly plug-in bez nutnosti provádět migraci modulů plug-in kompletně.
Po vyjádření vratných operací či příkazů ve formě IUndoableOperation je možné moduly plug-in definující historii Zpět (zásobník příkazů) pro uchovávání vratných a znovu proveditelných operací převést migrací na historii operací platformy tím, že se definuje IUndoContext představující jejich historii Zpět. Historie operací Zpět, které byly dříve spravovány lokálně, lze sloučit do společné historie operací tak, že se nadefinuje jedinečný kontext Zpět buďto pro každou část, nebo pro každý modelový objekt, přidáním příslušného kontextu Zpět ke každé operaci a poté přidáním operace do historie operací platformy. Historie operací Zpět s globálnějším rozsahem platnosti lze implementovat definováním jedinečného kontextu Zpět představujícího daný rozsah platnosti Zpět, přiřazením tohoto kontextu ke každé operaci a poté přidáním operace do historie operací platformy. Příklady vytváření kontextů Zpět, jejich přiřazování a přidávání operací do historie operací platformy najdete v dokumentaci Vratné operace.
Moduly plug-in, které chtějí, aby jejich operace byly v pohledech pracovní plochy vratné, například v navigátoru či průzkumníku balíčků, by měly do svých operací přiřadit kontext Zpět pracovní plochy. Podrobnější informace o tomto kontextu Zpět a možnostech jeho načtení pracovní plochou či moduly plug-in bez hlavičky najdete v dokumentaci Vratné operace.
Moduly plug-in, které infrastrukturu pro akce Zpět ani vratné operace nedefinují, ale chtějí poskytovat přístup k historii Zpět platformy, by měly zvážit přesměrování globálních popisovačů akcí Zpět a Znovu na nové společné popisovače akcí Zpět a Znovu. Popisovačům akcí by se měly přiřadit kontext Zpět určující která historie operací Zpět a Znovu se má zobrazovat. Moduly plug-in mohou využívat své lokálně definované kontexty Zpět při zobrazování lokální historie operací Zpět a Znovu týkající se dané části. Kontext Zpět pracovní plochy lze použít k zobrazení historie operací Zpět a Znovu pro celou pracovní plochu. Kompletní příklad je opět v dokumentaci Vratné operace.
Migrace akcí Zpět a Znovu textového editoru se poněkud liší od jednoduchého přesměrování globálních popisovačů akcí Zpět/znovu. Rámec (framework) AbstractTextEditor definuje společné textové akce za použití parametrizovaného TextOperationAction. Tyto akce se ukládají lokálně v rámci (framework) a používají se k odbavení nejrůznějších příkazů na cíl textové operace příslušného editoru. Pro zajištění správného fungování akce Zpět u textu se rámec textového editoru spoléhá na přítomnost akcí textových operací se správnými id (ITextEditorActionConstants.REDO a ITextEditorActionConstants.UNDO).
AbstractTextEditor byl převeden migrací tak, že vytváří společné popisovače akcí, zatímco je stále přiřazuje do tabulky TextOperationAction s jejich staršími id. Takto je možné získat nové popisovače akcí Zpět a Znovu za použití starších technik pro získání akce a provedení operace. Toto chování zdědí textové editory v hierarchii AbstractTextEditor.
Editory, které toto chování z AbstractTextEditor nezdědí, by měly zvážit migraci stávajících akcí Zpět a Znovu tak, aby používaly nové popisovače. Lokální podpora Zpět u editorů se staršími tabulkami TextOperationAction akcí Zpět a Znovu bude i nadále fungovat, protože i nadále je podporováno rozhraní API správce Zpět modulu JFace Text používané těmito akcemi. Štítky akcí Zpět a Znovu však již nebudou konzistentní s novými akcemi Zpět/znovu v rámci SDK platformy Eclipse zobrazujících název dostupných operací Zpět či Znovu. Při vytváření společných popisovačů akcí Zpět a Znovu by se měl používat kontext Zpět používaný správcem Zpět textového prohlížeče při vytváření popisovačů akcí, a tyto popisovače by se měly nastavit do textového editoru pomocí vhodného id ITextEditorActionConstants. Podrobný příklad viz AbstractTextEditor.createUndoRedoActions() a AbstractTextEditor.getUndoContext(). Editory spoléhající se na podtřídu EditorActionBarContributor pro přidávání do řádků s akcemi u svých editorů mohou použít podobnou techniku vytváření popisovačů akcí Zpět a Znovu a jejich nastavení v okamžiku nastavení aktivního editoru.
Moduly plug-in které přispívají vyhledávacími stránkami do dialogu Hledat by měly zvážit portování všech operací vyhledávání informací do vyhledávačů v rámci federovaného vyhledávání. Od verze 3.1 jsou všechny operace vyhledávání informací odděleny od vyhledávání artefaktů pracovní plochy. Vyhledávače informací běží současně jako úkoly na pozadí a výsledky se shromáždí a setřídí v novém pohledu Nápověda. Další podrobnosti viz Hledání v nápovědě.
Nová dynamická nápověda bude fungovat se stávajícími ID kontextu, které se staticky přiřazují k prvkům widget v částech pracovní plochy a dialogových oknech. Pokud však událost nápovědy zachytíte sami a zobrazíte nějakou nápovědu, dynamická nápověda nebude schopna zobrazit nic užitečného.
Problém můžete vyřešit tak, že se přizpůsobíte novému rozhraní
IContextProvider
popsanému v dokumentu
Dynamická kontextová nápověda.
Počínaje verzí 3.1 je org.eclipse.jface.preference.IPreferenceStore vracené z AbstractUIPlugin.getPreferenceStore() instancí org.eclipse.ui.preferences.ScopedPreferenceStore. ScopedPreferenceStore používá ke správě předvoleb rozhraní API org.eclipse.core.runtime.preferences. Ve verzi 3.0 používal vrstvu kompatibility ke komunikaci s instancí org.eclipse.core.runtime.Preferences.
Ve verzi 3.1 jsme odstranili víceznačnost IPreferenceStore pro zvýšení konkrétnosti u typů hodnot zasílaných v rámci událostí změny předvoleb. IPreferenceStore z AbstractUIPlugin#getPreferenceStore má stejné chování jako předtím, ale je nyní specifikováno jasněji.
Typování:
org.eclipse.jface.util.IPropertyChangeListener
přidané do IPreferenceStore může případně vést na dva typy starých a nových hodnot
- typová nebo řetězcová vyjádření. Jakákoli událost generovaná voláním typového rozhraní API IPreferenceStore (např. setValue(String key, boolean value)
vygeneruje typovou událost.
Je však také možné, že události se budou šířit z běhových předvoleb modulu Core runtime, které generují netypovou událost (například při importu předvolby). Listenery předvoleb musí být připraveny na obojí. Vezměte také na vědomí, že typové události nebudou šířit primitivní typy, takže volání setValue(String key, boolean value)
skončí s výsledkem, kde oldValue a newValue budou typu Boolean.
putValue: IPreferenceStore.putValue(String key, String value) nebude generovat událost změny. Smyslem použití tohoto rozhraní API jsou soukromé předvolby, na které žádný listener nereaguje.
initializeDefaultPreferences. Toto rozhraní API bylo v Eclipse verze 3.0 označeno za nepřípustné a aktivuje se pouze v případě, že je použita vrstva kompatibility. Protože většina modulů plug-in spoléhá při získávání paměti předvolby na AbstractUIPlugin#getPreferenceStore, dříve se toto aktivovalo v okamžiku spouštění modulu plug-in. Pokud váš modul plug-in k samotné vrstvě kompatibility nepřistupuje, tato metoda se nespouští. Doporučuje se, abyste k ošetření inicializace svých předvoleb vytvořili org.eclipse.core.runtime.preferences.AbstractPreferenceInitializer.