Ändringar som krävs när du inför 3.1-mekanismer och -API:er

I det här avsnittet beskrivs de ändringar som krävs när du ändrar ditt insticksprogram från version 3.0 till mekanismerna och API:erna i version 3.1.

Plattformsstöd för ångra/gör om

I Eclipse 3.1 finns en ny infrastruktur som definierar åtgärder som går att ångra och en delad åtgärdshistorik som håller reda på åtgärder som har utförts, ångrats och gjorts om. De olika ramverken för ångrafunktioner som finns i tilläggsinsticksprogram bör migreras för att ge åtgärdsstöd på plattformen så att klienter till dessa ramverk kan integreras djupare i plattformen. På så sätt blir ångraåtgärderna tillgängliga i andra insticksprogramvyer och redigerare. I dokumentet om åtgärder som kan ångras finns grundläggande information om hur du lägger till stöd för ångraåtgärder i ett insticksprogram. Insticksprogram som redan har stöd för ångraåtgärder eller använder ett annat ramverk, kan migreras stegvis till det nya ångrastödet. Detta beskrivs nedan.

Migrera insticksprogramsspecifika åtgärdsklasser (kommando) till IUndoableOperation

Insticksprogram som redan definierar klasser som beskriver ångraåtgärderna bör lägga till en implementering för gränssnittet IUndoableOperation i sina åtgärds-/kommandoklasser. Insticksprogram kan, om det behövs, fortfarande använda äldre ramverk för hantering av historiken (kommandostack), men om de tillhandahåller ett gränssnitt för IUndoableOperation kan klienterna till ett insticksprogram använda samma åtgärder i plattformens åtgärdshistorik. De kan även blanda ångraåtgärder från olika insticksprogram. Denna strategi liknar den som används av SDK-textredigerare när de migreras till det nya åtgärdsramverket. Om det inte går att avbilda gränssnittet rakt av kan du använda paketmoduler för att avbilda IUndoableOperation-protokollet på äldre ångraobjekt. Denna strategi används av omfaktoriseringsstödet i plattform/JDT. Migrering av åtgärds-/kommandoklasserna till IUndoableOperation är ett viktigt steg eftersom det tillåter ångraåtgärderna från olika ramverk att användas av andra insticksprogram, utan att något av insticksprogrammen måste migreras fullständigt.

Migrera kommandostackar med IOperationHistory

När ångraåtgärder eller -kommandon uttrycks som IUndoableOperation, kan insticksprogram som definierar en ångrahistorik (kommandostack) över vilka åtgärder som kan ångras och göras om migreras till plattformens åtgärdshistorik genom att du definierar en IUndoContext som representerar deras ångrahistorik. Ångrahistorik som tidigare hanterades lokalt kan slås samman med gemensam åtgärdshistorik genom att ett unikt ångrakontext definieras, antingen för varje part eller för varje modellobjekt. Ångrakontext läggs till i varje åtgärd och därefter läggs åtgärden till i plattformens åtgärdshistorik. Ångrahistorik med ett mer globalt omfång kan implementeras genom att ett unikt ångrakontext som representerar det ångraomfånget definieras. Kontexten tilldelas till varje åtgärd och sedan läggs åtgärden till i plattformens åtgärdshistorik. I dokumentet om åtgärder som kan ångras finns exempel på hur du skapar ångrakontext, tilldelar och lägger till åtgärder i plattformens åtgärdshistorik.

Definiera ångraåtgärder som är globala till arbetsytan

Insticksprogram som ska ha sina åtgärder ångringsbara från arbetsytans vy, till exempel Navigatorvy eller Paketutforskaren, måste tilldela arbetsytans ångrakontext till sina åtgärder. I dokumentet om åtgärder som kan ångras finns mer information om denna ångrakontext och hur den kan hämtas av både arbetsytan och konsollösa insticksprogram.

Plattformsåtgärdshanterare för ångra/gör om

Insticksprogram som inte definierar en ångrainfrastruktur eller åtgärder som kan ångras men som vill tillhandahålla access till plattformens ångrahistorik, bör överväga att omarbeta de globala åtgärdshanterarna för ångra- och gör om-åtgärder med de nya gemensamma åtgärdshanterarna för ångra/gör om. Åtgärdshanterarna bör tilldelas ett ångrakontext som specificerar vilken ångra- och gör om-historik som ska visas. Insticksprogram kan använda sin lokalt definierade ångrakontext för att visa "dellokal" ångra- och gör om-historik. Arbetsytans ångrakontext kan användas till att visa ångra- och gör om-historik på arbetsytenivå. I dokumentationen finns ett komplett exempel som visar vilka åtgärder som kan ångras.

Migrera textåtgärder till de gemensamma åtgärdshanterarna

Migrering av ångra- och gör om-åtgärder från textredigerare skiljer sig lite från att på ett enkelt sätt peka om globala åtgärdshanterare för ångra/gör om. Ramverket AbstractTextEditor definierar gemensamma textåtgärder genom att använda en parameterbaserad TextOperationAction. Åtgärderna sparas lokalt i ramverket och skickar ut olika kommandon till en redigerares textåtgärdsmål. För att text ska kunna ångras på rätt sätt förlitar sig redigerarramverket på närvaron av textåtgärder med giltiga ID (ITextEditorActionConstants.REDO och ITextEditorActionConstants.UNDO).

AbstractTextEditor har migrerats så att den skapar gemensamma åtgärdshanterare samtidigt som de tilldelas till TextOperationAction-tabellen med sina gamla ID. På så sätt kan de nya åtgärdshanterarna för ångra- och gör om-åtgärder hämtas med äldre teknik, som hämtar åtgärden och utför den. Textredigerare i AbstractTextEditor-hierarkin ärver detta beteende.

Redigerare som inte ärver beteendet från AbstractTextEditor bör migrera alla befintliga ångra- och gör om-åtgärder så att de använder de nya hanterarna. Redigerare med äldre TextOperationActions för ångra och gör om kommer fortfarande att ha kvar sitt lokala ångrastöd eftersom ångrahanterar-API:et i JFace-text som används av dessa åtgärder fortfarande stöds. Åtgärdsetiketterna för ångra och gör om kommer dock inte vara konsekventa med de nya ångra- och gör om-åtgärderna i Eclipse SDK. I Eclipse SDK visas namnet på de tillgängliga ångra- och gör om-åtgärderna. Om du vill skapa de gemensamma åtgärdshanterarna för ångra och gör om bör du använda ångrakontextet som används av textvisarnas ångringshanterare när du skapar åtgärdshanterarna. Åtgärdshanterarna ska anges i redigeraren med passande ITextEditorActionConstants-ID. I AbstractTextEditor.createUndoRedoActions() och AbstractTextEditor.getUndoContext() finns ett detaljerat exempel. Redigerare som är beroende av en EditorActionBarContributor-underklass för att kunna infoga på åtgärdsfälten i redigerarna kan använda en liknande teknik genom att skapa åtgärdshanterare för ångra och gör om och ange dem när den aktiva redigeraren har angivits.

Hjälpförbättringar

Informationssökning

Insticksprogram som bidrar med söksidor i dialogrutan Sök bör porta alla sina informationssökningar till förenade sökmotorer. Från och med version 3.1 har all informationssökning separerats från arbetsytans testobjektssökning. Informationssökningsmotorer körs parallellt som bakgrundsjobb och deras resultat visas i den nya hjälpvyn. I Hjälpsökning finns mer information.

Dynamisk hjälp

Den nya dynamiska hjälpvyn fungerar med befintliga kontext-ID som är statiskt associerade till gränssnittskontroller på arbetsytan och i dialogrutor. Om du fångar hjälphändelser själv och visar hjälp kommer den dynamiska hjälpvyn inte att visa något användbart. Du rättar till problemet genom att använda det nya IContextProvider-gränssnittet som beskrivs i dokumentet om dynamisk kontexthjälp.

JFace-inställningslager

Från och med version 3.1 är org.eclipse.jface.preference.IPreferenceStore som returneras från AbstractUIPlugin.getPreferenceStore() en förekomst av org.eclipse.ui.preferences.ScopedPreferenceStore. ScopedPreferenceStore använder org.eclipse.core.runtime.preferences-API:t till att hantera inställningar. I 3.0 använde det kompatibilitetslagret som gränssnitt till en förekomst av org.eclipse.core.runtime.Preferences.

I 3.1 har vi tagit bort tvetydigheter för IPreferenceStore så att det är mer specifikt beträffande de typer av värden som skickas i händelser för inställningsändringar. IPreferenceStore från AbstractUIPlugin#getPreferenceStore har samma funktion som tidigare, men det är tydligare specificerat.

Typing: org.eclipse.jface.util.IPropertyChangeListener tillagt i ett IPreferenceStore kan potentiellt ge två typer av gamla och nya värden - typdefinierade representationer och strängrepresentationer. En händelse som genereras av ett anrop till ett skrivet IPreferenceStore-API (till exempel setValue(String key, boolean value) genererar en typdefinierad händelse. Det är dock även möjligt att händelser överförs från de kärnruntimeinställningar som genererar en ej typdefinierad händelse (till exempel vid en inställningsimport). Egenskapslyssnare måste vara förberedda på båda. Lägg även märke till att typdefinierade händelser inte överför primitiva typer så ett anrop till setValue(String key, boolean value) resulterar i en händelser där oldValue och newValue är booleska värden.

putValue: IPreferenceStore.putValue(String key, String value) genererar inte en ändringshändelse. Det här API:t är avsett att användas för privata inställningar som ingen lyssnare bör reagera på.

initializeDefaultPreferences. Det här API:t utkommenterades i Eclipse 3.0 eftersom det aktiveras endast om kompatibilietslagret används. Eftersom de flesta insticksprogram är beroende av AbstractUIPlugin#getPreferenceStore för att få tillgång till sitt inställningslager aktiverades det här tidigare när insticksprogrammet startades. Om insticksprogrammet inte använder själva kompatibilitetslagret aktiveras inte den här metoden. Du bör skapa en org.eclipse.core.runtime.preferences.AbstractPreferenceInitializer för att hantera inställningsinitieringen.