La structure de texte de la plate-forme définit un modèle de document pour le texte et fournit un afficheur qui affiche le texte en utilisant ce modèle. Nous commencerons par observer comment l'exemple d'éditeur Java utilise ce modèle. Nous n'insisterons pas sur les mécanismes de base d'enregistrement d'une extension d'éditeur, puisque ce sujet a déjà été abordé dans la section relative à org.eclipse.ui.editors. En revanche, nous analyserons les spécificités liées à l'implémentation de la classe d'éditeur dans l'exemple.
Dans le plan de travail, un éditeur s'ouvre généralement lorsque l'utilisateur sélectionne un élément de domaine (tel qu'un fichier ou un élément stocké dans un fichier d'archive) et l'ouvre. Une fois l'éditeur créé, il est associé à une entrée d'éditeur (IEditorInput), qui décrit l'objet édité.
L'exemple d'éditeur Java s'ouvre lorsque l'utilisateur ouvre un fichier ayant l'extension "*.jav". Auquel cas, l'entrée dans l'éditeur est IFileEditorInput. La structure de texte de la plate-forme est peu concernée par l'entrée d'éditeur elle-même. Elle travaille avec un modèle de présentation appelé IDocument, pour l'entrée de façon à pouvoir effectivement afficher et manipuler du texte.
Cela signifie qu'il doit exister un moyen de mapper un modèle de domaine donné (l'entrée d'éditeur) à un modèle de présentation. Ce mappage est défini dans un IDocumentProvider. Pour une entrée d'éditeur donnée, le fournisseur de documents renvoie un IDocument approprié.
L'exemple de l'éditeur Java hérite de l'élément TextFileDocumentProvider défini par le plug-in org.eclipse.ui.editors. L'extension org.eclipse.ui.editors.documentProviders est utilisée pour définir le mappage entre les types d'entrée de l'éditeur (ou les extensions de fichier) et les fournisseurs de documents. Le plug-in de l'éditeur définit son fournisseur de document de la manière suivante :
<extension point="org.eclipse.ui.editors.documentProviders"> <provider class="org.eclipse.ui.editors.text.TextFileDocumentProvider" inputTypes="org.eclipse.ui.IStorageEditorInput" id="org.eclipse.ui.editors.text.StorageDocumentProvider"> </provider> </extension>
Ce point d'extension permet aux plug-ins d'enregistrer les fournisseurs de document et de les associer à une extension de fichier ou à une classe d'entrée de l'éditeur. L'exemple de l'éditeur Java ne définit pas sa propre extension de fournisseur de document. Il hérite du fournisseur de document générique spécifié pour tous les types d'entrée correspond à IStorageEditorInput. Lorsque l'utilisateur ouvre un fichier pour modification, la plate-forme gère les détails de création de l'instance de fournisseur de document appropriée. Si un fournisseur de document spécifique est enregistrée pour l'extension de fichier, c'est celui-ci qui est utilisé. S'il n'existe pas de fournisseur de document spécifique pour cette extension de fichier, le type d'entrée de l'éditeur est utilisé pour recherche le fournisseur approprié.
En utilisant le fournisseur de document de plate-forme générique, l'exemple d'éditeur Java peut tirer parti de toutes les fonctions du fournisseur de document, comme la mise en mémoire tampon des fichiers et les autres optimisations.
Dans la mesure où l'éditeur Java utilise le fournisseur de document de texte de la plate-forme, comment peut-il permettre un comportement spécialisé pour gérer des fichiers Java ?
L'extension org.eclipse.core.filebuffers.documentSetup est utilisée pour définir des mappages entre des extensions de fichier et un élément IDocumentSetupParticipant. Le participant à la mise en page configure le document à l'aide de fonctions spéciales une fois qu'il a été indiqué à l'éditeur.
<extension id="ExampleJavaDocumentSetupParticipant" name="%documentSetupParticipantName" point="org.eclipse.core.filebuffers.documentSetup"> <participant extensions="jav" class="org.eclipse.ui.examples.javaeditor.JavaDocumentSetupParticipant"> </participant> </extension>
Cette définition d'extension est ce qui donne à l'exemple une chance de mettre en page ce document pour des tâches spécifiques à Java. Quel est l'action de JavaDocumentSetupParticipant ? Nous allons examiner une version simplifiée de la méthode setup.
public void setup(IDocument document) { ... IDocumentPartitioner partitioner= new FastPartitioner(JavaEditorExamplePlugin.getDefault().getJavaPartitionScanner(), JavaPartitionScanner.JAVA_PARTITION_TYPES); partitioner.connect(document); ... }
Le code de la méthode setup configure un objet appelé partitionneur.
Le partitionneur (IDocumentPartitioner) est chargé de diviser le document en portions qui ne se chevauchent pas appelées partitions. Les partitions (représentées par ITypedRegion) sont utiles pour traiter les différentes sections du document différemment pour ce qui est des fonctions comme la mise en évidence de la syntaxe ou la mise en forme.
Dans le cas de l'exemple d'éditeur Java, le document est divisé en partitions qui correspondent aux commentaires javadoc, aux commentaires multilignes et à d'autres éléments. A chaque région est affecté un type de contenu et sa position dans le document. Les positions sont actualisées à mesure que l'utilisateur modifie le texte.
Chaque éditeur détermine l'implémentation appropriée d'un partitionneur de document. L'analyse des documents de base de règles est prise en charge dans org.eclipse.jface.text.rules. L'emploi d'un scanneur de base de règles permet à un éditeur d'utiliser le FastPartitioner fourni par la sructure.
IDocumentPartitioner partitioner= new FastPartitioner(JavaEditorExamplePlugin.getDefault().getJavaPartitionScanner(), JavaPartitionScanner.JAVA_PARTITION_TYPES);
RuleBasedPartitionScannerest la superclasse des scanneurs de base de règles. Les sous-classes sont chargées de l'énumération et de l'implémentation des règles à utiliser pour différencier des jetons tels que les délimiteurs de lignes, les caractères blancs et les motifs génériques lors du scannage d'un document. Le JavaPartitionScanner de l'exemple définit des règles afin de différencier les commentaires monolignes, les constantes de type caractère, les commentaires javadoc, les commentaires multilignes et les mots. Cette opération s'effectue dans le constructeur du scanneur :
public JavaPartitionScanner() { super(); IToken javaDoc= new Token(JAVA_DOC); IToken comment= new Token(JAVA_MULTILINE_COMMENT); List rules= new ArrayList(); // Ajouter une règle pour les commentaires monolignes. rules.add(new EndOfLineRule("//", Token.UNDEFINED)); // Ajouter une règle pour les constantes de type chaîne et caractère. rules.add(new SingleLineRule("\"", "\"", Token.UNDEFINED, '\\')); rules.add(new SingleLineRule("'", "'", Token.UNDEFINED, '\\')); // Ajouter une règle pour les mots spéciaux. rules.add(new WordPredicateRule(comment)); // Ajouter des règles pour les commentaires multilignes et javadoc. rules.add(new MultiLineRule("/**", "*/", javaDoc, (char) 0, true)); rules.add(new MultiLineRule("/*", "*/", comment, (char) 0, true)); IPredicateRule[] result= new IPredicateRule[rules.size()]; rules.toArray(result); setPredicateRules(result); }
Reportez-vous aux classes de org.eclipse.jface.text.rules pour plus de détails sur la définition des règles et sur les types de règles disponibles. Nous reviendrons sur les scanneurs lorsque nous étudierons la coloration de syntaxe.