Verplichte wijzigingen bij het toepassen van 3.1-methoden en -API's

Deze sectie bevat de wijzigingen die u moet doorvoeren voordat de 3.0-plugins geschikt zijn voor de 3.1-methoden en API's.

Platform-ondersteuning voor ongedaan maken/opnieuw uitvoeren

Eclipse 3.1 levert een nieuwe infrastructuur voor het definiėren van Bewerkingen die ongedaan kunnen worden gemaakt en een gedeelde bewerkingshistorie die de bewerkingen bijhoudt die zijn uitgevoerd, ongedaan gemaakt en opnieuw uitgevoerd. De verschillende frameworks voor ongedaan maken die worden geleverd door de toegevoegde plugins moeten van tijd tot tijd naar de bewerkingsondersteuning van het platform worden gemigreerd zodat de clients van deze frameworks dieper kunnen integreren in het platform en hun bewerkingen die ongedaan kunnen worden gemaakt beschikbaar kunnen stellen voor bewerkingen Ongedaan maken in andere pluginviews en -editors. Raadpleeg de documentatie over Bewerkingen die ongedaan kunnen worden gemaakt voor de basisinformatie over het toevoegen van ondersteuning aan een plugin voor Ongedaan maken. Plugins die al ondersteuning definiėren voor Ongedaan maken of een ander framework gebruiken, kunnen stapsgewijs op de volgende manier worden gemigreerd naar de nieuwe ondersteuning voor Ongedaan maken.

Pluginspecifieke bewerkings(opdracht)-klassen naar IUndoableOperation migreren

Plugins die al klassen definiėren die de bewerkingen die Ongedaan kunnen worden gemaakt, beschrijven, moeten aan de bewerkings/opdracht-klassen een implementatie toevoegen voor de interface IUndoableOperation. De plugins kunnen nog steeds oudere frameworks gebruiken voor het indien nodig beheren van de historie (opdrachtstack), maar door het leveren van een interface voor IUndoableOperation wordt het mogelijk voor de clients van een plugin om dezelfde bewerkingen te gebruiken in de platformbewerkingenhistorie en om de bewerkingen die ongedaan kunnen worden gemaakt uit andere plugins te mengen en op elkaar af te stemmen. Deze strategie is vergelijkbaar met de strategie die wordt gebruikt door SDK-teksteditors om naar het nieuwe bewerkingsframework te migreren. Als het direct toewijzen van de interface niet mogelijk is, kunnen wrappers worden gebruikt om het IUndoableOperation-protocol toe te wijzen aan de verouderde objecten voor ongedaan maken. Deze strategie wordt gebruikt door de Platform/JDT-herstructureringsondersteuning. Migratie van de bewerkings/opdrachtklassen naar IUndoableOperation is een belangrijke stap, omdat deze het mogelijk maakt dat de bewerkingen uit andere frameworks die ongedaan kunnen worden gemaakt, kunnen worden gebruikt door andere plugins zonder dat een van deze plugins volledig hoeft te worden gemigreerd.

Opdrachtstacks met IOperationHistory migreren

Als de bewerkingen of opdrachten die ongedaan kunnen worden gemaakt, eenmaal zijn uitgedrukt in termen van IUndoableOperation, kunnen de plugins die een historie Ongedaan maken (opdrachtstack) definiėren voor het bijhouden van de bewerkingen die ongedaan kunnen worden gemaakt en die opnieuw kunnen worden uitgevoerd, migreren naar de platformbewerkingenhistorie door middel van het definiėren van een IUndoContext die hun historie van Ongedaan maken weerspiegelt. De histories van Ongedaan maken die eerder lokaal werden beheerd, kunnen worden samengevoegd in de gemeenschappelijke bewerkingshistorie door een unieke context voor Ongedaan maken te definiėren, ofwel voor elk onderdeel ofwel voor elk modelobject, waarbij de geschikte context voor Ongedaan maken wordt toegevoegd aan elke bewerking en vervolgens de bewerking wordt toegevoegd aan de platformbewerkingshistorie. Histories Ongedaan maken met een meer algemeen bereik kunnen worden geļmplementeerd door een unieke context voor Ongedaan maken te definiėren die dit bereik voor Ongedaan maken weerspiegelt, deze context toewijst aan elke bewerking en vervolgens de bewerking toevoegt aan de platformbewerkingshistorie. Raadpleeg de documentatie Bewerkingen die ongedaan kunnen worden gemaakt voor voorbeelden van het maken van contexten voor ongedaan maken, deze toewijzen en van het toevoegen van bewerkingen aan de platformbewerkingenhistorie.

Bewerkingen die ongedaan kunnen worden gemaakt en die algemeen zijn voor de workbench definiėren

Plugins waarvoor geldt dat de bewerkingen ongedaan moeten kunnen worden gemaakt uit de workbenchviews, bijvoorbeeld de Navigator of de Pakketverkenner, moeten de workbenchcontext voor ongedaan maken toewijzen aan hun bewerkingen. Zie de documentatie Bewerkingen die ongedaan kunnen worden gemaakt voor meer informatie over deze context voor ongedaan maken en hoe deze kan worden opgehaald door zowel de workbenchplugins als door headless-plugins.

Afhandelingsroutines van het Platform voor acties ongedaan maken/opnieuw uitvoeren

Voor plugins die geen infrastructuur voor ongedaan maken of bewerkingen die ongedaan kunnen worden gemaakt, definiėren, maar wel toegang leveren aan de platformhistorie van Ongedaan maken, kan worden overwogen de algemene afhandelingsroutines voor de acties Ongedaan maken en Opnieuw uitvoeren opnieuw te richten met de nieuwe algemene afhandelingsroutines voor de acties Ongedaan maken en Opnieuw uitvoeren. De afhandelingsroutines voor de acties moeten een context voor ongedaan maken toegewezen krijgen, waarin wordt opgegeven welke historie voor ongedaan maken en opnieuw uitvoeren moet worden afgebeeld. Voor de plugins kunnen de lokaal gedefinieerde contexten voor ongedaan maken, worden gebruikt voor het afbeelden van "gedeelte lokale" historie ongedaan maken en opnieuw uitvoeren. De workbenchcontext voor ongedaan maken, kan worden gebruikt voor het afbeelden van de historie Ongedaan maken en Opnieuw uitvoeren voor de gehele workbench. De documentatie Bewerkingen die ongedaan kunnen worden gemaakt bevat een volledig voorbeeld.

Tekstbewerkingen migreren naar de algemene actieafhandelingsroutines

Het migreren van teksteditoracties ongedaan maken en opnieuw uitvoeren, verschilt enigszins van het eenvoudige opnieuw richten van de algemene actieafhandelingsroutines voor ongedaan maken/opnieuw uitvoeren. Het AbstractTextEditor-framework definieert algemene tekstacties met behulp van een TextOperationAction met parameters. Deze acties worden lokaal opgeslagen in het framework en worden gebruikt voor het snel afhandelen van verschillende opdrachten aan het tekstbewerkingsdoel van een editor. Voor het juist functioneren van een tekstbewerking ongedaan maken, moet het teksteditorframework kunnen rekenen op de aanwezigheid van tekstbewerkingsacties met de juiste ID's (ITextEditorActionConstants.REDO en ITextEditorActionConstants.UNDO).

AbstractTextEditor is zodanig gemigreerd dat het de algemene actieafhandelingsroutines maakt, terwijl deze nog steeds worden toegewezen aan de TextOperationAction-tabel met de legacy-ID's. Op deze manier kunnen de nieuwe actieafhandelingsroutines voor Ongedaan maken/Opnieuw uitvoeren, worden opgehaald met behulp van de verouderde technieken voor het ophalen van de actie en voor het uitvoeren van de bewerking. Teksteditors in de AbstractTextEditor-hiėrarchie nemen dit gedragspatroon over.

De editors die dit gedragspatroon niet overnemen van AbstractTextEditor, kunnen eventuele bestaande acties voor Ongedaan maken/Opnieuw uitvoeren migreren, zodat deze de nieuwe afhandelingsroutines gebruiken. De editors met verouderde TextOperationActions voor ongedaan maken en opnieuw uitvoeren, hebben nog steeds actieve ondersteuning voor lokaal ongedaan maken, omdat de JFace Text undo manager API die door deze acties wordt gebruikt, nog steeds wordt ondersteund. De labels van de acties ongedaan maken en opnieuw uitvoeren, zijn echter niet dezelfde als die van de nieuwe Eclipse SDK-acties ongedaan maken en opnieuw uitvoeren, die de namen van de beschikbare bewerkingen afbeelden. Om algemene actieafhandelingsroutines voor ongedaan maken en opnieuw uitvoeren te maken, moet de undo-context die wordt gebruikt door de tekstviewermanager voor Ongedaan maken, worden gebruikt bij het maken van de actieafhandelingsroutines en deze afhandelingsroutines moeten worden ingesteld op de editor die het geschikte ITextEditorActionConstants-ID gebruikt. Zie AbstractTextEditor.createUndoRedoActions() en AbstractTextEditor.getUndoContext() voor een gedetailleerd voorbeeld. De editors die een EditorActionBarContributor-subklasse nodig hebben om toe te voegen aan de actiebalken van de editors, kunnen een vergelijkbare techniek gebruiken door actieafhandelingsroutines te maken en deze te installeren wanneer de actieve editor wordt geļnstalleerd.

Help-uitbreidingen

Informatie zoeken

De plugins die zoekpagina's bijdragen aan het dialoogvenster Zoeken kunnen alle informatiezoekopdrachten overdragen aan verenigde zoekmachines. Vanaf versie 3.1 worden alle zoekopdrachten voor informatie gescheiden van de zoekopdrachten voor workbenchartefacten. De informatiezoekmachines worden parallel uitgevoerd als achtergrondtaken en de resultaten worden gesorteerd in de nieuwe Helpview. Zie Zoeken in Help voor meer details hierover.

Dynamische Help

De nieuwe dynamische Helpview werkt met bestaande context-ID's die statisch worden gekoppeld aan widgets in de workbenchonderdelen en de dialoogvensters. Als u zelf een Helpevent afvangt en Help afbeeldt, is de dynamische Helpview niet in staat iets bruikbaars af te beelden. Om het probleem te verhelpen, kunt u de nieuwe IContextProvider-interface ingebruiknemen, zoals beschreven staat in Dynamische specifieke Help.

JFace-voorkeurenverzamelingen

Vanaf versie 3.1 is org.eclipse.jface.preference.IPreferenceStore dat een resultaat is van AbstractUIPlugin.getPreferenceStore() een instance van org.eclipse.ui.preferences.ScopedPreferenceStore. De ScopedPreferenceStore gebruikt de org.eclipse.core.runtime.preferences-API voor het beheren van de voorkeuren. In 3.0 werd de compatibiliteitslaag gebruikt om een interface te bieden aan een instance van org.eclipse.core.runtime.Preferences.

Vanaf 3.1 heeft IPreferenceStore niet langer een dubbelzinnige betekenis, zodat specifiekere gegevens over de typen van de waarden in de wijzigingsevents van de voorkeuren kunnen worden gebruikt. De werking van de interface IPreferenceStore uit AbstractUIPlugin#getPreferenceStore is onveranderd, maar de specificatie ervan is nu verduidelijkt.

Typen. Als u org.eclipse.jface.util.IPropertyChangeListener aan IPreferenceStore toevoegt, bestaat de kans dat er twee typen van oude en nieuwe waarden ontstaan: waarden met een type en String-waarden. Er wordt een type toegewezen aan events die het gevolg zijn van een aanroep van een IPreferenceStore-API met een type (zoals setValue(String key, boolean value)). Als de events echter voortkomen uit de kernruntime-voorkeuren, hebben ze geen type (zoals een voorkeurenimportering). U moet in beide gevallen eigenschappenlisteners instellen. Primitieve typen worden door events met een type niet gedistribueerd. Als u dus setValue(String key, boolean value) aanroept, is het resultaat een event waarbij de oude en de nieuwe waarde van het type boolean zijn.

putValue. Met IPreferenceStore.putValue(String key, String value) wordt geen wijzigingsevent gegenereerd. Deze API dient voor besloten voorkeuren waarop niet gereageerd moet worden door listeners.

initializeDefaultPreferences. Deze API is gedeprecieerd vanaf Eclipse 3.0, omdat deze alleen wordt geļnitieerd als de compatibiliteitslaag wordt gebruikt. De meeste plugins halen de voorkeuren op met AbstractUIPlugin#getPreferenceStore, en daarom werd deze methode bij het starten van de plugin geļnitieerd. Deze methode wordt mogelijk niet geļnitieerd als de plugin niet met de compatibiliteitslaag werkt. Het wordt aanbevolen een org.eclipse.core.runtime.preferences.AbstractPreferenceInitializer te maken voor de initialisatie van de voorkeuren.