Syntaksfarvning stilles til rådighed i platformens tekststruktur vha. en model for skader, reparation og afstemning. For hver ændring i et dokument afgør en funktion til præsentationsafstemning, hvilket område af den visuelle præsentation som skal defineres som ugyldigt, og hvordan det skal repareres. Der kan bruges forskellige strategier for forskellige indholdstyper i dokumentet.
Det er valgfrit at implementere syntaksfarvning (og at gøre det vha. en funktion til præsentationsafstemning). Som standard installerer SourceViewerConfiguration ikke en funktion til præsentationsafstemning, fordi den ikke kender den dokumentmodel, som bruges til en bestemt editor, og ikke har nogen generisk funktionsmåde for syntaksfremhævning.
For at kunne bruge afstemningsklasserne til implementering af syntaksfremhævning skal editorens konfiguration af kildefremvisning være konfigureret, så den definerer en funktion til præsentationsafstemning. Nu starter vi igen JavaSourceViewerConfiguration for at se, hvordan en funktion til præsentationsafstemning defineres til vores editor.
public IPresentationReconciler getPresentationReconciler(ISourceViewer sourceViewer) { PresentationReconciler reconciler= new PresentationReconciler(); ... return reconciler; }
Vi ser først på begreberne skader, reparation og afstemning for at forstå, hvad en funktion til præsentationsafstemning gør.
Efterhånden som brugeren ændrer tekst i en editor, skal dele af editoren vises igen, så ændringerne vises. Beregning af den tekst, som skal vises igen, kaldes beregning af skader. Når der er involveret syntaksfarvning, bliver omfanget af den skade, som forårsages af redigeringsfunktionen, mere omfattende, fordi tilstedeværelse eller fravær af et enkelt tegn kan ændre farven på den omgivende tekst.
Funktioner til bedømmelse af skade kaldes 'Damagers'(IPresentationDamager) og afgør, hvilken del af dokumentets præsentation der skal bygges igen som følge af en dokumentændring. En funktion til bedømmelse af skaden i en præsentation antages af være specifik for en bestemt dokumentindholdstype (eller et bestemt område). Den skal være i stand til at returnere et skadeområde, som er gyldigt input til en reparationsfunktion kaldet en 'Repairer'(IPresentationRepairer). En reparationsfunktion skal kunne udlede alle de nødvendige oplysninger af et beskadiget område for at kunne beskrive den reparation, der kræves af en bestemt indholdstype, på en relevant måde.
Afstemning beskriver den overordnede proces med at vedligeholde præsentationen af et dokument, efterhånden som der foretages ændringer i editoren. En funktion til præsentationsafstemning (IPresentationReconciler) overvåger ændringer i teksten via sin tilknyttede fremviser. Den bruger områderne i dokumentet til at afgøre, hvilke indholdstyper der er berørt af ændringerne, og giver besked til en funktion til bedømmelse af skaden, at den er relevant for den berørte indholdstype. Når skaden er beregnet, videresendes den til den relevante reparationsfunktion, som udfærdiger reparationsbeskrivelser, der anvendes af fremviseren til at blive synkroniseret med det underliggende indhold.
Klasserne i org.eclipse.jface.text.reconciler definerer yderligere supportklasser til synkronisering af en dokumentmodel med ekstern manipulation af dokumentet.
Funktioner til præsentationsafstemning skal tildeles en 'repairer' og 'damager' for hver indholdstype i dokumentet. Det er op til den enkelte editor at bestemme den relevante implementering af en funktion til præsentationsafstemning. Platformen indeholder dog understøttelse i form af org.eclipse.jface.text.rules mht. brug af regelbaserede dokumentscannere til beregning og reparation af skader. I denne pakke er der defineret standard-'damagers' og -'repairers'. De kan benyttes sammen med standardafstemningsfunktionerne i org.eclipse.jface.text.presentation til at implementere syntaksfarvning vha. en definition af scanningsregler for dokumentet.
Nu har vi tilstrækkeligt baggrundsmateriale til at se nærmere på oprettelsen af eksemplet på en funktion til præsentationsafstemning. Vi har set, at Java-editoreksemplet implementerer en JavaPartitionScanner, som opdeler dokumentet i indholdstyper, der repræsenterer Javadoc, kommentarer på flere linjer og alt muligt andet.
For hver af disse indholdstyper skal der angives en 'damager' og en 'repairer'. Det gøres nedenfor vha. PresentationReconciler og DefaultDamagerRepairer.
JavaColorProvider provider= JavaEditorEnvironment.getJavaColorProvider(); PresentationReconciler reconciler= new PresentationReconciler(); DefaultDamagerRepairer dr= new DefaultDamagerRepairer(JavaEditorEnvironment.getJavaCodeScanner()); reconciler.setDamager(dr, IDocument.DEFAULT_CONTENT_TYPE); reconciler.setRepairer(dr, IDocument.DEFAULT_CONTENT_TYPE); dr= new DefaultDamagerRepairer(new SingleTokenScanner(new TextAttribute(provider.getColor(JavaColorProvider.JAVADOC_DEFAULT)))); reconciler.setDamager(dr, JavaPartitionScanner.JAVA_DOC); reconciler.setRepairer(dr, JavaPartitionScanner.JAVA_DOC); dr= new DefaultDamagerRepairer(new SingleTokenScanner(new TextAttribute(provider.getColor(JavaColorProvider.MULTI_LINE_COMMENT)))); reconciler.setDamager(dr, JavaPartitionScanner.JAVA_MULTILINE_COMMENT); reconciler.setRepairer(dr, JavaPartitionScanner.JAVA_MULTILINE_COMMENT); return reconciler;
Bemærk, at eksemplet stiller scannere til rådighed for alle indholdstyper.
Standardindholdstypen klargøres med en JavaCodeScanner, så nøgleord kan findes og farvelægges. JavaCodeScanner opbygger regler for registrering af forskellige typer tokens, f.eks. kommentarer på en enkelt linje, tom plads og ord. Den beskriver de farver, der skal bruges til ord med forskellige token-typer.
De andre indholdstyper klargøres med en SingleTokenScanner og tildeles en farve, der skal bruges til tokens i disse indholdstyper.
Alle oplysninger til beskadigelse og reparation af de relevante dele af dokumenterne i henhold til scanningsreglerne håndteres af DefaultDamagerRepairer. Disse oplysninger behøver typisk ikke kunne forstås af plugin-koden. Din plugin skal fokusere på at opbygge et sæt regler, som er relevante for opdeling og scanning af dens editorindhold.
Java-editoreksemplet stiller en underklasse af SourceViewerConfiguration til rådighed med henblik på installation af funktionen til præsentationsafstemning, som vi tidligere har omtalt. En funktion til præsentationsafstemning kan også installeres dynamisk i en tekstfremviser vha. protokollen IPresentationReconciler. Der er ingen speciel runtime-fordel ved nogen af metoderne, men hvis alle tilsidesættelser af plugin-funktionsmåde placeres i en underklasse til SourceViewerConfiguration, har du den fordel, at alle tilsidesættelser af funktionsmåde er konsolideret ét sted. Den dynamiske protokol kan være praktisk, hvis der tilsluttes forskellige funktioner til præsentationsafstemning til en fremviser i løbet af en editors levetid.