A coloração da sintaxe é fornecida no quadro de texto da plataforma por meio de um modelo de danos, reparação e reconciliação. Para cada alteração aplicada a um documento, um reconciliador de apresentações determina qual a região na apresentação visual que deve ser invalidada e como a reparar. Podem ser usadas diversas estratégias para diferentes tipos de conteúdo no documento.
A implementação de coloração da sintaxe (e isto com um reconciliador de apresentações) é opcional. Por predefinição, a SourceViewerConfiguration não instala um reconciliador de apresentações visto que não sabe o modelo de documentos utilizado para determinado editor e não tem comportamento genérico para destaque de sintaxe.
Para poder utilizar as classes de reconciliação para implementar destaque de sintaxe, a configuração do visualizador de fonte do editor deve ser configurada para definir um reconciliador de apresentações. Mais uma vez, começamos com JavaSourceViewerConfiguration para ver como é definido um reconciliador de apresentações para o nosso editor.
public IPresentationReconciler getPresentationReconciler(ISourceViewer sourceViewer) { PresentationReconciler reconciler= new PresentationReconciler(); ... return reconciler; }
Para compreender o que faz um reconciliador de apresentações, primeiro veremos os conceitos de danos, reparação e reconciliação.
À medida que o utilizador modifica texto num editor, é necessário reapresentar partes deste para mostrar as alterações. O cálculo do texto que tem de ser reapresentado chama-se cálculo dos danos. Quando se trata de coloração de sintaxe, o volume dos danos causados por uma operação de edição torna-se mais extensivo, dado que a presença ou ausência de único carácter pode alterar a coloração do texto em redor dele.
Os agentes de danos (IPresentationDamager) determinam a região da apresentação de um documento que deve ser reconstruída devido a alterações no documento. Parte-se do princípio de que um agente de danos é específico a determinado tipo de conteúdo de documento (ou região). Deverá ser capaz de devolver uma região de dados que seja uma entrada de dados válida para um reparador de apresentações (IPresentationRepairer). O reparador deve ser capaz de inferir todas as informações de que necessita de uma região de danos, para poder descrever satisfatoriamente as reparações necessárias a determinado tipo de conteúdo.
A reconciliação descreve o processo global de manter a apresentação de um documento enquanto se procede a alterações no editor. Um reconciliador de apresentações (IPresentationReconciler) supervisiona alterações ao texto através do seu visualizador associado. Utiliza as regiões do documento para determinar os tipos de conteúdo afectados pela alteração e avisa um agente de danos que seja apropriado para o tipo de conteúdo afectado. Uma vez calculados os danos, são transmitidos ao reparador apropriado que irá construir descrições de reparação, as quais são aplicadas ao visualizador para repor a sincronia com o conteúdo subjacente.
As classes em org.eclipse.jface.text.reconciler definem classes de suporte adicionais para sincronizar um modelo de documentos com manipulação externa do documento.
Os reconciliadores de apresentações devem estar habilitados com um par de reparador e agente de danos para cada tipo de conteúdo que se encontre no documento. Compete a cada editor determinar a implementação apropriada para um reconciliador de apresentações. Todavia, a plataforma faculta suporte em org.eclipse.jface.text.rules para utilizar leitores baseados em regras para calcular e reparar danos. Os agentes de danos e os reparadores predefinidos estão definidos neste pacote. Podem ser utilizados junto com os reconciliadores padrão em org.eclipse.jface.text.presentation para implementar coloração de sintaxe mediante definição de regras de leitura para o documento.
Dispomos agora de um historial adequado para ver em pormenor a criação do reconciliador de apresentações exemplo. Recorde que o exemplo do editor Java implementa um JavaPartitionScanner o qual particiona o documento em tipos de conteúdo que representam javadoc, comentários multi-linha e tudo o mais.
Para cada um destes tipos de conteúdo, deve ser especificado um par agente de danos/reparador. Tal realiza-se a seguir com o PresentationReconciler e o 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;
Repare que o exemplo faculta leitores para cada tipo de conteúdo.
O tipo de conteúdo predefinido é configurado com um JavaCodeScanner para que as palavras-chave possam ser detectadas e coloridas. O JavaCodeScanner constrói regras para detectar diferentes espécies de sinais como, por exemplo, comentários de linha única, espaços em branco e palavras. Descreve as cores que devem ser usadas para palavras de diferentes tipos de sinais.
Os outros tipos de conteúdo são configurados com um SingleTokenScanner e recebem uma cor a utilizar em sinais nestes tipos de conteúdo.
Todos os detalhes da ocorrência de danos e reparações nas partes devidas dos documentos segundo as regras de leitura são tratados pelo DefaultDamagerRepairer. Estes detalhes geralmente não têm que ser inteligíveis para o código do plug-in. O plug-in deve concentrar-se na construção de um conjunto de regras que sejam apropriadas para particionar e ler o conteúdo do respectivo editor.
O exemplo do editor Java faculta uma subclasse de SourceViewerConfiguration para instalar o reconciliador de apresentações tal como vimos antes. Também é possível instalar dinamicamente um reconciliador de apresentações num visualizador de texto por meio do protocolo IPresentationReconciler. Não há vantagens de tempo de execução numa das formas, mas colocar todas as sobreposições de comportamento de plug-in numa subclasse de SourceViewerConfiguration traz a vantagem de consolidar todas as sobreposições de comportamento em um só sítio. O protocol dinâmico pode ser útil quando existem diferentes reconciliadores de apresentações anexados a um visualizador ao longo da vida de um editor.