Nødvendige endringer når 3.1-mekanismene og -APIene tas i bruk

Denne delen beskriver endringer som er nødvendige hvis du prøver å endre en plugin-modul fra 3.0 slik at den tar i bruk mekanismene og APIene for 3.1.

Plattformstøtte for angre/gjør om

Eclipse 3.1 har en ny infrastruktur for å definere operasjoner som kan angres og en delt operasjonshistorikk som holder rede på operasjoner som er utført, angret og omgjort. De ulike angrerammeverkene fra ekstra plugin-moduler bør over tid migreres til plattformens operasjonsstøtte, slik at klienter av disse rammeverkene kan integreres dypere med plattformen og gjøre deres operasjoner som kan angres, tilgjengelige for angring i andre plugin-visninger og redigeringsprogrammer. Se dokumentasjonen om operasjoner som kan angres hvis du vil ha grunnleggende informasjon om hvordan du legger til støtte for angring i en plugin-modul. Plugin-moduler som allerede definerer støtte for angring eller bruker et annet rammeverk, kan migreres trinnvis til den nye angrestøtten, slik det beskrives nedenfor.

Migrere plugin-spesifikke operasjonsklasser (kommandoklasser) til IUndoableOperation

Plugin-moduler som allerede definerer klasser som beskriver operasjonene som kan endres, bør legge til en implementering for grensesnittet IUndoableOperation i operasjons-/kommandoklassene. Plugin-moduler kan fremdeles bruke eldre rammeverk til å administrere historikken (kommandostakken) hvis det er nødvendig, men et grensesnitt for IUndoableOperation gjør det mulig for en plugin-moduls klienter å bruke de samme operasjonene i plattformens operasjonshistorikk, og å blande ulike operasjoner som kan angres, fra forskjellige plugin-moduler. Denne strategien likner på den som brukes av SDK-tekstredigeringsprogrammene til å migrere til det nye operasjonsrammeverket. Hvis det ikke er mulig med en direkte tilordning av grensesnittet, kan det brukes wrappere til å tilordne IUndoableOperation-protokollen til eldre objekter som kan angres. Denne strategien brukes av støtten for refaktorisering av plattform/JDT. Migrering av operasjons-/kommandoklasser til IUndoableOperation er et viktig trinn fordi det tillater at operasjoner som kan angres fra ulike rammeverk, kan utnyttes av andre plugin-moduler uten at noen plugin-modul må migreres fullstendig.

Migrere kommandostakker med IOperationHistory

Når operasjoner eller kommandoer som kan angres, uttrykkes i form av IUndoableOperation, kan plugin-moduler som definerer en angrehistorikk (kommandostakk) for å holde rede på operasjoner som kan anges eller gjøres om, migreres til plattformens operasjonshistorikk ved å definere en IUndoContext som representerer angrehistorikken. Angrehistorikk som tidligere ble administrert lokalt, kan slås sammen i den felles operasjonshistorikken ved å definere en unik angrekontekst enten for hver del eller for hvert modellobjekt, legge til den riktige angrekonteksten i hver operasjon, og deretter legge til operasjonen i plattformens operasjonshistorikk. Angrehistorikk med et mer globalt omfang kan implementeres ved å definere en unik angrekontekst som representerer dette angreomfanget, tildele denne konteksten til hver operasjon, og deretter legge til operasjonen i plattformens operasjonshistorikk. Se dokumentasjonen om operasjoner som kan angres hvis du vil ha eksempler på oppretting av angrekontekster, tilordning av dem og tilføying av operasjoner i plattformens operasjonshistorikk.

Definere operasjoner som kan endres globalt for arbeidsbenken

Plugin-moduler der det er ønskelig å kunne angre operasjonene fra arbeidsbenkvisninger som Navigator eller Pakkeutforsker, må tilordne arbeidsbenkens angrekontekst til operasjonene. Se dokumentasjonen om operasjoner som kan angres hvis du vil ha mer informasjon om denne angrekonteksten og hvordan den kan hentes av både arbeidsbenken og plugin-moduler med kommandolinjegrensesnitt.

Plattformbehandlere for å angre/gjøre om handlinger

I plugin-moduler som ikke definerer en angreinfrastruktur eller operasjoner som kan angres, men der det er ønskelig å gi tilgang til plattformens angrehistorikk, bør det vurderes å endre de globale behandlerne for å angre/gjøre om handlinger, til de nye felles behandlerne for å angre og gjøre om handlinger. Handlingsbehandlerne bør tilordne en angrekontekst som oppgir hvilken angre- og omgjøringshistorikk som skal vises. Plugin-moduler kan bruke de lokalt definerte angrekontekstene til å vise angre- og omgjøringshistorikk som er delvis lokal. Arbeidsbenkens angrekontekst kan brukes til å vise angre- og omgjøringshistorikk for hele arbeidsbenken. Dokumentasjonen om operasjoner som kan angres inneholder et fullstendig eksempel.

Migrere tekstoperasjonshandlinger til de felles handlingsbehandlerne

Migrering av angre- og omgjøringshandlinger for tekstredigeringsprogram er noe forskjellig fra migrering av de globale behandlerne for angre-/omgjøringshandlinger. Rammeverket AbstractTextEditor definerer felles teksthandlinger ved hjelp av en parameterisert TextOperationAction. Disse handlingene er lagret lokalt i rammeverket, og de brukes til å tildele ulike kommandoer til et redigeringsprograms tekstoperasjonsmål. For at omgjøring av tekst skal fungere på riktig måte, er tekstredigeringsprogrammet avhengig av at det finnes tekstoperasjonshandlinger med riktige IDer (ITextEditorActionConstants.REDO og ITextEditorActionConstants.UNDO).

AbstractTextEditor er migrert slik at det oppretter de felles handlingsbehandlerne, mens det fremdeles tilordner dem til tabellen TextOperationAction med sine arvede IDer. På denne måten kan de nye behandlerne av angre- og omgjøringshandlinger hentes ved hjelp av de arvede teknikkene for å hente handlingen og utføre en operasjon. Tekstredigeringsprogrammene i hierarkiet AbstractTextEditor arver denne virkemåten.

Redigeringsprogrammer som ikke arver denne virkemåten fra AbstractTextEditor, bør vurdere å migrere eventuelle eksisterende angre- og omgjøringshandlinger til å bruke de nye behandlerne. Redigeringsprogrammer med arvede TextOperationActions for angring og omgjøring vil fremdeles ha fungerende lokal omgjøringstøtte, siden APIet for tekstomgjøringsstyreren JFace som brukes av disse handlingene, fremdeles støttes. Etikettene for angre- og omgjøringshandlingen vil ikke være konsistent med de nye angre-/omgjøringshandlingene for Eclipse SDK, som viser navnet på den tilgjengelige angre- og omgjøringsoperasjonen. For å opprette de felles behandlerne for angre- og omgjøringshandlinger, bør angrekonteksten som brukes av tekstvisningsprogrammets angrestyrer, brukes ved oppretting av handlingsbehandlerne, og disse behandlerne bør defineres i redigeringsprogrammet ved hjelp av den riktige ITextEditorActionConstants-IDen. Se AbstractTextEditor.createUndoRedoActions() og AbstractTextEditor.getUndoContext() hvis du vil ha et detaljert eksempel. Redigeringsprogrammer som er avhengige av en EditorActionBarContributor-subklasse for å legge til handlingslinjene for redigeringsprogrammene, kan bruke en liknende teknikk ved å opprette behandlere for angre- og omgjøringshandlinger, og definere dem når det aktive redigeringsprogrammet er definert.

Forbedringer i Hjelp

Informasjonssøk

Plugin-moduler som leverer søkesider til Søk-dialogboksen, bør vurdere å portere alt informasjonssøk til de felles søkemotorene. Siden 3.1 er alle typer informasjonssøk skilt fra arbeidsbenksøk. Informasjonssøkemotorene kjøres parallelt som bakgrunnsjobber, og resultatene samles i den nye Hjelp-visningen. Se Søk i hjelp hvis du vil ha mer informasjon.

Dynamisk hjelp

Den nye dynamiske Hjelp-visningen fungerer med eksisterende kontekst-IDer som er statisk knyttet til widgeter i arbeidsbenkdeler og -dialogbokser. Hvis du imidlertid oppfatter hjelpehendelsen selv og viser hjelp, er ikke den dynamiske Hjelp-visningen i stand til å vise noe nyttig. For å løse problemet bør du bruke det nye IContextProvider-grensesnittet som er beskrevet i dokumentet om dynamisk konteksthjelp.

JFace-preferanselagre

Fra og med utgave 3.1 er org.eclipse.jface.preference.IPreferenceStore, som blir returnert fra AbstractUIPlugin.getPreferenceStore(), en forekomst av org.eclipse.ui.preferences.ScopedPreferenceStore. ScopedPreferenceStore bruker APIet org.eclipse.core.runtime.preferences til å styre preferansene. I 3.0 brukte den kompatibilitetslaget for å kommunisere med en forekomst av org.eclipse.core.runtime.Preferences.

I 3.1 har vi gjort IPreferenceStore mindre tvetydig, slik at den er mer spesifikk når det gjelder hvilke typer verdier som sendes i hendelser for endret preferanse. IPreferenceStore fra AbstractUIPlugin#getPreferenceStore har samme virkemåte som før, men spesifiseres nå klarere.

Skriving: org.eclipse.jface.util.IPropertyChangeListener som er lagt til i en IPreferenceStore, kan potensielt få to typer gamle og nye verdier - skrevet eller strengrepresentasjon. Alle hendelser som er generert av et kall til en skrevet IPreferenceStore API (for eksempel setValue(strengnøkkel, boolsk verdi) vil generere en skrevet hendelse. Men det er også mulig at hendelser blir distribuert fra preferansene for kjernekjøretid som genererer en ikke-skrevet hendelse (for eksempel i en preferanseimport). Egenskapslyttere må forberedes for begge. Legg også merke til at skrevne hendelser ikke vil distribuere primitive typer, og et kall til setValue(strengnøkkel, boolsk verdi) vil derfor resultere i en hendelse der oldValue og newValue er boolske.

putValue: IPreferenceStore.putValue(strengnøkkel, strengverdi) genererer ikke en endringshendelse. Denne APIen skal brukes til private preferanser som ingen lytter vil reagere på.

initializeDefaultPreferences. Denne APIen ble foreldet i Eclipse 3.0, fordi den bare startes hvis kompatibilitetslaget blir brukt. Ettersom de fleste plugin-modulene avhenger av AbstractUIPlugin#getPreferenceStore for å få preferanselageret, ble dette tidligere startet da plugin-moduler ble startet. Hvis plugin-modulen ikke har tilgang til selve kompatibilitetslaget, kan ikke denne metoden startes. Det er anbefalt at du oppretter en org.eclipse.core.runtime.preferences.AbstractPreferenceInitializer for å behandle initialisering av preferanser.