Tässä osassa kuvataan muutoksia, jotka ovat pakollisia, jos yrität muuttaa 3.0-lisäosan ottamaan käyttöön 3.1-version toiminnot ja sovellusohjelmaliittymät.
Eclipse 3.1 -versiossa on uusi infrastruktuuri kumottavien toimien määrittämiseen ja yhteiskäytössä oleva toimien historiatiedot, jotka pitävät kirjaa ajetuista, kumotuista ja uudelleen tehdyistä toimista. Ylimääräisten lisäosien toimittamat erilaiset kumouskehykset tulisi siirtää ajan myötä ympäristön toimen tukeen niin, että näiden kehysten asiakkaat voivat sulautua tiiviimmin ympäristöön ja tuoda kumottavat toimensa kumottaviksi muiden lisäosien näkymissä ja muokkausohjelmissa. Perustiedot kumouksen tuen lisäämisestä lisäosaan on esitelty ohjeaiheessa Kumottavat toimet. Lisäosat, jotka määrittävät jo kumouksen tuen tai käyttävät toista kehystä, voi siirtää uuteen kumouksen tukeen alla kuvatulla tavalla.
Lisäosien, jotka määrittävät jo kumottavia toimiaan kuvaavia luokkia, tulisi lisätä rajapinnan IUndoableOperation toteutus toimi- tai komentoluokkiinsa. Lisäosat voivat tarvittaessa käyttää edelleen vanhoja kehyksiä historiatietojen (komentomuistin) hallintaan, mutta IUndoableOperation-rajapinnan toimittamisen avulla lisäosien asiakkaat voivat käyttää samoja toimia ympäristön toimien historiatiedoissa ja yhdistellä eri lisäosien kumottavissa olevia toimia. Tämä strategia on samankaltainen kuin se, jota SDK-tekstinmuokkausohjelmat käyttävät uuteen toimikehykseen siirtymisessä. Jos rajapinnan suora määritys ei ole mahdollista, voidaan käyttää liittymäobjekteja määrittämään IUndoableOperation-käytännön vastaavuus kumousobjektien periytymistä varten. Ympäristön/JDT:n koodin parannuksen tuki käyttää tätä strategiaa. Toimi- tai komentoluokkien siirto IUndoableOperation-rajapintaan on tärkeä vaihe, sillä sen avulla lisäosat voivat käyttää toisten kehysten kumottavia toimia niin, että kummankaan lisäosan ei tarvitse siirtyä kokonaan.
Kun kumottavat toimet tai komennot on ilmaistu IUndoableOperation-rajapinnan kannalta, kumottavien ja uudelleen tehtävien toimien jäljitystä varten kumouksen historiatiedot (komentomuistin) määrittävät lisäosat voivat siirtyä ympäristön toimien historiatietoihin määrittämällä IUndoContext-rajapinnan, joka kuvaa niiden kumouksen historiatietoja. Aiemmin paikallisesti hallitut kumouksen historiatiedot voi yhdistää yleisiin toimienhistoriatietoihin määrittämällä yksilöllisen kumouskontekstin joko osalle muutamalle tai kullekin malliobjektille, lisäämällä tarkoituksenmukaisen kumouskontekstin kullekin toimelle ja lisäämällä toimen sitten ympäristön toimien historiatietoihin. Kumouksen historiatiedot, joilla on yleisempi käyttöalue, voi toteuttaa määrittämällä kyseistä kumousaluetta kuvaavan yksilöllisen kumouskontekstin, määrittämällä kontekstin kullekin toimelle ja lisäämällä sen jälkeen toimen ympäristön toimien historiatietoihin. Esimerkkejä kumouskontekstien luonnista, määrityksestä ja toimien lisäyksestä ympäristön toimien historiatietoihin on esitelty ohjeaiheessa Kumottavat toimet.
Lisäosat, jotka haluavat toimiensa olevan kumottavissa työympäristön näkymistä, esimerkiksi navigaattorinäkymästä tai pakettien selausnäkymästä, tulee määrittää toimilleen työympäristön kumouskonteksti. Lisätietoja tästä kumouskontekstista ja siitä, miten sekä työympäristö että näyttöpäätteettömät lisäosat voivat noutaa sen, on ohjeaiheessa Kumottavat toimet.
Lisäosien, jotka eivät määritä kumouksen infrastruktuuria tai kumottavia toimintoja, mutta haluaisivat mahdollistaa ympäristön kumouksen historiatietojen käytön, tulisi harkita yleisten kumous- ja uudelleentekemistoimintojen käsittelytoimintojen kohdentamista uudelleen uusilla yleisillä kumous- ja uudelleentekemistoimintojen käsittelytoiminnoilla. Toimintojen käsittelytoiminnoille tulisi määrittää kumouskonteksti, joka määrittää, mitkä kumouksen ja uudelleen tekemisen historiatiedot näytetään. Lisäosat voivat käyttää paikallisesti määritettyjä kumouskontekstejaan "osalle paikallisten" kumouksen ja uudelleen tekemisen historiatietojen näyttämiseen. Työympäristön kumouskontekstia voi käyttää työympäristön laajuisten kumouksen ja uudelleen tekemisen historiatietojen näyttämiseen. Kattava esimerkki tästäkin on ohjeaiheessa Kumottavat toimet.
Tekstinmuokkausohjelman kumous- ja uudelleentekemistoimintojen siirtäminen eroaa jonkin verran yleisten kumous- ja uudelleentekemistapahtumien käsittelytoimintojen yksinkertaisesta uudelleenkohdentamisesta. AbstractTextEditor-kehys määrittää yleiset tekstitoimet parametrisoidun TextOperationAction-luokan avulla. Nämä toimet tallennetaan paikallisesti kehykseen ja niitä käytetään lähettämään eri komennot muokkausohjelman tekstitoimen kohteeseen. Jotta tekstin kumous toimisi oikein, tekstinmuokkausohjelmakehys perustuu tekstitoimien toimintoihin, joilla on kelvolliset tunnukset (ITextEditorActionConstants.REDO ja ITextEditorActionConstants.UNDO).
AbstractTextEditor on siirretty niin, että se luo yleiset toimintojen käsittelytoiminnot samalla, kun se edelleen määrittää ne TextOperationAction-taulukkoon vanhoilla tunnuksillaan. Tällä tavalla uudet kumous- ja uudelleentekemistoimintojen käsittelytoiminnot voidaan noutaa toiminnon noudon ja toimen teon vanhoilla tekniikoilla. AbstractTextEditor-hierarkiassa olevat tekstinmuokkausohjelmat perivät tämän toimintatavan.
Muokkausohjelmien, jotka eivät peri tätä toimintatapaa AbstractTextEditor-luokasta, tulisi harkita olemassa olevien kumous- ja uudelleentekemistoimien siirtoa käyttämään uusia käsittelytoimintoja. Muokkausohjelmilla, joilla on vanhoja kumouksen ja uudelleentekemisen TextOperationAction-toimintoja, on edelleen toimiva kumouksen tuki, sillä näiden toimintojen käyttämä JFace-tekstin kumouksen hallintaohjelman sovellusohjelmaliittymä on edelleen tuettu. Kumous- ja uudelleentekemistoimintojen nimiöt eivät kuitenkaan ole enää yhdenmukaisia Eclipse SDK:n kumous- ja uudelleentekemistoimintojen kanssa, jotka näyttävät käytettävissä olevan kumous- tai uudelleentekemistoiminnon nimen. Yleisten kumous- ja uudelleentekemistoimintojen käsittelytoimintojen luontia varten tulisi käyttää tekstin katseluohjelman kumouksen hallintaohjelman käyttämää kumouskontekstia toimintojen käsittelytoimintojen luonnin yhteydessä, ja nämä käsittelytoiminnot tulisi asettaa muokkausohjelmaan oikealla ITextEditorActionConstants-tunnuksella. Yksityiskohtainen esimerkki on esitetty ohjeaiheissa AbstractTextEditor.createUndoRedoActions() ja AbstractTextEditor.getUndoContext(). Muokkausohjelmat, jotka tekevät lisäyksiä muokkausohjelmiensa toimintopalkkeihin EditorActionBarContributor-aliluokan avulla, voivat käyttää samankaltaista tekniikkaa luomalla kumouksen ja uudelleentekemisen toimintojen käsittelytoiminnot ja asettamalla ne, kun aktiivinen muokkausohjelma on asetettu.
Lisäosien, jotka toimittavat hakusivuja Haku-valintaikkunaan, tulisi harkita kaikkien tietotyyppisten hakujensa siirtoa yhdistettyihin hakuohjelmiin. Versiosta 3.1 alkaen kaikki tietotyyppinen haku on erotettu työympäristön objektien hausta. Tietohakuohjelmat ajetaan rinnan taustatöinä, ja niiden tulokset lomitetaan uuteen Ohje-näkymään. Lisätietoja on ohjeaiheessa Ohjehaku.
Uusi dynaaminen ohjenäkymä toimii työympäristön osien ja valintaikkunoiden widget-objekteille staattisesti määritettävien olemassa olevien kontekstien tunnusten kanssa. Jos kuitenkin sieppaat ohjetapahtuman itse ja tuot ohjeen näyttöön, dynaaminen ohjenäkymä ei pysty näyttämään mitään hyödyllistä. Tämän ongelman ratkaisemista varten tulisi mukautua uuteen IContextProvider
-rajapintaan ohjeaiheessa Dynaaminen tilannekohtainen ohje kuvatulla tavalla.
Versiosta 3.1 alkaen org.eclipse.jface.preference.IPreferenceStore, jonka metodi AbstractUIPlugin#getPreferenceStore() palauttaa, on luokan org.eclipse.ui.preferences.ScopedPreferenceStore ilmentymä. ScopedPreferenceStore käyttää ohjelmointirajapintaa org.eclipse.core.runtime.preferences oletusasetusten ylläpitoon. Versiossa 3.0 se käytti yhteensopivuuskerrosta rajapinnassa luokan org.eclipse.core.runtime.Preferences ilmentymän kanssa.
Versiossa 3.1 IPreferenceStore määrittää entistä tarkemmin oletusarvojen muuttuneisiin tapahtumiin lähetettyjen arvojen lajit. IPreferenceStore, jonka metodi AbstractUIPlugin#getPreferenceStore palauttaa, toimii samoin kuin ennenkin - ainoa muutos on, että se on määritetty entistä selkeämmin.
Lajin määritys: IPreferenceStore-rajapintaan lisätyllä luokalla org.eclipse.jface.util.IPropertyChangeListener
voidaan hakea kahdenlaisia vanhoja ja uusia arvoja -
tyypitettyjä esityksiä tai merkkijonoesityksiä. Kaikki tapahtumat,
jotka luodaan kutsumalla tyypitettyä
IPreferenceStore-ohjelmointirajapintaa(esimerkiksi
setValue(String key, boolean value)
),
ovat tyypitettyjä tapahtumia. Tapahtumat voidaan kuitenkin myös
hakea ajonaikaisista ydinoletusasetuksista, jotka muodostavat
tyypittömän tapahtuman (esimerkiksi oletusasetuksia tuotaessa). Kummassakin tarvitaan ominaisuuksien kuuntelutoimintoja. Huomaa
myös, että tyypitetyt tapahtumat eivät aiheuta alkeistyyppejä,
joten setValue(String key, boolean value)
-kutsu aiheuttaa
tapahtuman, jossa oldValue ja newValue ovat totuusarvoja.
putValue: IPreferenceStore.putValue(String key, String value) ei luo muutostapahtumaa. Tätä sovellusohjelmaliittymää on tarkoitus käyttää yksityisissä oletusasetuksissa, joihin kuuntelutoiminnon ei haluta reagoivan.
initializeDefaultPreferences. Tämä sovellusohjelmaliittymä on vanhentunut Eclipse-versiossa 3.0, sillä se aloitetaan vain, jos käytetään yhteensopivuuskerrosta. Koska useimmat lisäosat hakevat oletusasetusvarastonsa metodilla AbstractUIPlugin#getPreferenceStore, tämä aloitettiin ennen lisäosan aloituksen yhteydessä. Jos lisäosasi ei käytä yhteensopivuuskerrosta, tätä metodia ei voi aloittaa. On suositeltavaa luoda org.eclipse.core.runtime.preferences.AbstractPreferenceInitializer oletusasetusten alustusta varten.