La infraestructura de texto de la plataforma suministra el coloreado de sintaxis por medio de un modelo de perjuicio, reparación y conciliación. Para cada rango aplicado a un documento, un conciliador de presentación determina qué región de la presentación visual debe invalidarse y cómo debe repararse. Pueden utilizarse estrategias distintas para diferentes tipos de contenido en el documento.
La implementación del coloreado de sintaxis (y hacerlo con un conciliador de presentación) es opcional. Por omisión, SourceViewerConfiguration no instala un conciliador de presentación, ya que no conoce el modelo de documento utilizado para un editor determinado y no tiene comportamiento genérico para el resaltado de sintaxis.
Para poder utilizar las clases de conciliación a fin de implementar el resaltado de sintaxis, el visor de código fuente del editor debe configurarse de forma que defina un conciliador de presentación. Una vez más, empezaremos por JavaSourceViewerConfiguration para observar cómo se define un conciliador de presentación para el editor.
public IPresentationReconciler getPresentationReconciler(ISourceViewer sourceViewer) { PresentationReconciler reconciler= new PresentationReconciler(); ... return reconciler; }
Para entender lo que hace un conciliador de presentación, debemos tratar en primer lugar los conceptos de perjuicio, reparación y conciliación.
A medida que el usuario modifica texto en un editor, deben volver a visualizarse partes del editor para mostrar los cambios. El cálculo del texto que debe volver a visualizarse se conoce como cálculo del perjuicio. Cuando está implicado el coloreado de sintaxis, el perjuicio causado por una operación de edición es mayor, ya que la presencia o ausencia de un simple carácter puede cambiar el coloreado del texto que lo circunda.
Los elementos que causan perjuicios, o perjudicadores, (IPresentationDamager) determinan la región de la presentación de un documento que debe reconstruirse debido a un cambio del documento. Se presupone que un perjudicador de la presentación es específico de un tipo de contenido (o región) determinado del documento. Debe ser capaz de devolver una región de daños que sea una entrada válida para un reparador de presentación (IPresentationRepairer). Un reparador debe ser capaz de derivar toda la información que necesita a partir de una región de daños para poder describir satisfactoriamente las reparaciones necesarias para un tipo de contenido determinado.
La conciliación describe el proceso global que consiste en mantener la presentación de un documento a medida que se efectúan cambios en el editor. Un conciliador de presentación (IPresentationReconciler) supervisa los cambios efectuados en el texto mediante su visor asociado. Utiliza las regiones del documento para determinar los tipos de contenido afectados por el cambio e indica un perjudicador que es adecuado al tipo de contenido afectado. Una vez calculado el perjuicio, se pasa al reparador apropiado, que construirá descripciones de reparación que se aplican al visor a fin de situarlo de nuevo en sincronía con el contenido subyacente.
Las clases de org.eclipse.jface.text.reconciler definen clases de soporte adicionales para sincronizar un modelo de documento con la manipulación externa del documento.
Los conciliadores de presentación deben suministrarse con un par formado por un reparador y un perjudicador para cada tipo de contenido que deba encontrarse en el documento. La determinación de la implementación adecuada para un conciliador de presentación corre a cargo de cada editor. Sin embargo, la plataforma proporciona soporte en org.eclipse.jface.text.rules para utilizar exploradores de documentos basados en normas a fin de calcular y reparar el perjuicio. En este paquete se definen los perjudicadores y reparadores por omisión. Pueden utilizarse junto con los conciliadores estándar de org.eclipse.jface.text.presentation para implementar el coloreado de sintaxis definiendo normas de exploración del documento.
Ahora, disponemos de información suficiente para examinar con detalle la creación del conciliador de presentación de ejemplo. Recuerde que el editor Java de ejemplo implementa un JavaPartitionScanner que divide el documento en tipos de contenido que representan javadoc, comentarios multilínea y todo los demás.
Para cada uno de estos tipos de contenido, debe especificarse un par perjudicador/reparador. Esta operación se realiza a continuación mediante la utilización de PresentationReconciler y 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;
Observe que el ejemplo suministra exploradores para cada tipo de contenido.
El tipo de contenido por omisión está configurado con un JavaCodeScanner, a fin de que puedan detectarse y colorearse las palabras clave. JavaCodeScanner crea normas para detectar diversos tipos de símbolos, como por ejemplo comentarios de una sola línea, espacios en blanco y palabras. Describe los colores que deben utilizarse para las palabras de tipos de símbolo diferentes.
Los demás tipos de contenido están configurados con un SingleTokenScanner y se les otorga un color que debe utilizarse para los símbolos de estos tipos de contenido.
DefaultDamagerRepairer maneja todos los detalles del perjuicio y reparación de las partes adecuadas de los documentos según las normas de exploración. Generalmente, no es necesario que el código del conector conozca estos detalles. El conector debe centrarse en crear un conjunto de normas adecuadas para dividir y explorar el contenido de su editor.
El editor Java de ejemplo proporciona una subclase de SourceViewerConfiguration para instalar el conciliador de presentación tal como se ha visto anteriormente. El conciliador de presentación también puede instalarse dinámicamente en un visor de texto utilizando el protocolo IPresentationReconciler. Hacerlo de una u otra forma no representa ninguna ventaja en cuanto a la ejecución, pero el hecho de colocar todas las alteraciones temporales de comportamiento conectable en una subclase de SourceViewerConfiguration ofrece la ventaja de consolidar todas las alteraciones temporales de comportamiento en un solo lugar. El protocolo dinámico puede ser de utilidad si, a lo largo de la vida de un editor, se conectan a un visor diversos conciliadores de presentación.