Het platformtekstframework bevat een syntaxiskleurenmodel voor beschadiging, herstel en synchronisatie. Voor elke wijziging in een document wordt door een presentatie-reconciler (synchronisatieprogramma) vastgesteld welke regio van de visuele presentatie ongeldig moet worden gemaakt en hoe deze kan worden hersteld. Voor elk contenttype in het document kunt u een andere strategie gebruiken.
Het implementeren van syntaxiskleuren (met een presentatiesynchronisatieprogramma) is optioneel. Standaard wordt bij SourceViewerConfiguration geen presentatie-reconciler geïnstalleerd omdat niet automatisch kan worden bepaald welk documentmodel voor een bepaalde editor wordt gebruikt en er geen algemeen gedrag voor syntaxisaccentuering is.
Om de synchronisatieklassen te gebruiken voor de implementatie van syntaxisaccentuering, moet de bronviewer voor uw editor worden geconfigureerd met een presentatie-reconciler. Ook in dit document behandelen we eerst JavaSourceViewerConfiguration om te zien op welke wijze de presentatie-reconciler voor onze editor is gedefinieerd.
public IPresentationReconciler getPresentationReconciler(ISourceViewer sourceViewer) { PresentationReconciler reconciler= new PresentationReconciler(); ... return reconciler; }
Om de functie van een presentatie-reconciler beter te begrijpen, wordt eerst behandeld wat we verstaan onder beschadiging, herstel en synchronisatie.
Als de gebruiker een stuk tekst in een editor wijzigt, moeten bepaalde delen van de editor worden vernieuwd om de wijzigingen zichtbaar te maken. Het bepalen van de tekst die opnieuw moet worden weergegeven, wordt ook wel het berekenen van de beschadiging genoemd. Bij het gebruik van syntaxiskleuren is de beschadiging die ontstaat door een bewerking groter, omdat de aanwezigheid of afwezigheid van één teken al van invloed kan zijn op de kleur van de tekst eromheen.
Met zogenaamde 'damagers' (IPresentationDamager) wordt vastgesteld welke regio van een documentpresentatie opnieuw moet worden opgebouwd vanwege een documentwijziging. Een presentatie-damager wordt verondersteld specifiek te zijn voor een bepaald(e) contenttype (of regio) van het document. Deze moet in staat zijn om een beschadigingsregio te retourneren als geldige invoer voor een presentatie-repairer (IPresentationRepairer). Een repairer moet in staat zijn om alle informatie van een beschadigde regio af te leiden die nodig is voor een beschrijving van alle vereiste hersteltaken voor een bepaald contenttype.
Onder synchronisatie verstaan we het algemene proces voor het bijhouden van de presentatie van een document tijdens het aanbrengen van wijzigingen in de editor. Met een presentatie-reconciler (IPresentationReconciler) worden wijzigingen in de tekst bijgehouden via de bijbehorende viewer. De regio's van het document worden gebruikt om vast te stellen welke contenttypen door de wijziging worden beïnvloed en geeft deze informatie door aan een damager die geschikt is voor desbetreffende contenttype. Zodra de totale beschadiging is berekend, wordt deze informatie doorgegeven aan de juiste repairer. De repairer levert vervolgens herstelbeschrijvingen aan voor de viewer om deze weer te synchroniseren met de onderliggende content.
De klassen in org.eclipse.jface.text.reconciler definiëren aanvullende ondersteunende klassen om een documentmodel te kunnen synchroniseren met externe bewerkingen van het document.
Presentatie-reconcilers moeten worden aangeleverd met een combinatie van een repairer en een damager voor elk contenttype in het document. De juiste implementatie voor een presentatie-reconciler moet per editor worden vastgesteld. Het platform biedt echter wel ondersteuning in org.eclipse.jface.text.rules voor het gebruik van op regels gebaseerde documentscanprogramma's (scanners) om beschadigingen te kunnen berekenen en herstellen. In dit pakket zijn al standaarddamagers en -repairers gedefinieerd. Deze kunnen worden gebruikt in combinatie met de standaardreconcilers in org.eclipse.jface.text.presentation om syntaxiskleuren te implementeren door scanregels voor het document te definiëren.
Nu beschikt u over genoeg achtergrondinformatie om dieper in te kunnen gaan op de aanmaak van de voorbeeldpresentatie-reconciler. Zoals eerder vermeld, implementeert de Java-voorbeeldeditor een JavaPartitionScanner (Java-partitiescanner) om het document onder te verdelen naar contenttype in Javadoc, commentaar dat bestaat uit meerdere regels, en overige content.
Voor elk van deze contenttypen moet een damager/repairer-combinatie worden opgegeven. Dit wordt hieronder uitgevoerd met de elementen PresentationReconciler en 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;
Merk op dat in het voorbeeld voor elk contenttype een scanner wordt opgegeven.
Het standaardcontenttype wordt ingesteld met een JavaCodeScanner zodat sleutelwoorden gedetecteerd en gekleurd kunnen worden. De JavaCodeScanner bouwt regels voor het detecteren van verschillende soorten tokens, bijvoorbeeld voor commentaar dat bestaat uit één regel, witruimte, en woorden. De scanner bevat ook een beschrijving van de kleuren die moeten worden gebruikt voor woorden van verschillende soorten tokens.
De overige contenttypen worden ingesteld met een SingleTokenScanner (één-tokenscanner) en een kleur die moet worden gebruikt voor tokens van deze contenttypen.
Alle details met betrekking tot beschadiging en herstel van de desbetreffende delen van documenten volgens de scanregels worden afgehandeld door DefaultDamagerRepairer. Deze details hoeven gewoonlijk niet te worden geïnterpreteerd door plugincode. Uw plugin moet eerder gericht zijn op het bouwen van regels voor het partitioneren en scannen van de content in de bijbehorende editor.
Zoals u eerder hebt kunnen zien in het Java-editorvoorbeeld, bevat deze een subklasse van SourceViewerConfiguration om de presentatie-reconciler te installeren. Een presentatie-reconciler voor een tekstviewer kan ook dynamisch worden geïnstalleerd met behulp van het protocol IPresentationReconciler. Geen van beide methoden biedt specifieke runtime-voordelen, maar het plaatsen van alle vervangende plugin-gedragspatronen in een subklasse van SourceViewerConfiguration heeft wel als voordeel dat alle gedragspatroonwijzigingen op één centrale locatie worden geconsolideerd. Het dynamische protocol is vooral nuttig wanneer er verschillende presentatie-reconcilers aan een viewer worden gekoppeld tijdens de levenscyclus van een editor.