Décomposeurs de contenu

Les éditeurs comportent souvent des décomposeurs de contenu correspondants qui fournissent une vue structurée du contenu de l'éditeur et aident l'utilisateur à naviguer dans le contenu de l'éditeur.

C'est à cette fin que le plan de travail fournit une vue Structure standard. L'utilisateur du plan de travail contrôle l'affichage de cette vue à l'aide du menu Perspective->Afficher la vue.

Comme la méthode TextEditor générique ne connaît pas la structure de son texte, elle ne peut pas fournir de comportement pour une vue de structure intéressante. De ce fait, la vue Structure par défaut, illustrée ci-dessous, ne sert pas à grand chose.

Les plug-ins peuvent étendre TextEditor dans le seul but d'ajouter une page de décomposeur de contenu personnalisée à la vue de structure. Cette approche est utilisée dans l'exemple d'outil readme du plan de travail. La méthode ReadmeEditor substitue quelques méthodes dans TextEditor pour fournir son propre décomposeur.

Le décomposeur d'un éditeur est spécifié lorsque le plan de travail demande un adaptateur de type IContentOutlinePage.

public Object getAdapter(Class key) {
    if (key.equals(IContentOutlinePage.class)) {
        IEditorInput input = getEditorInput();
        if (input instanceof IFileEditorInput) {
            page = new ReadmeContentOutlinePage(
                ((IFileEditorInput)input).getFile());
            return page;
        }
    }
    return super.getAdapter(key);

Lorsqu'un ReadmeEditor est ouvert (sur un fichier .readme), le décomposeur de readme correspondant s'affiche (si l'utilisateur du plan de travail affiche la vue Structure).

Une page de décomposeur de contenu doit implémenter IContentOutlinePage. Cette interface associe la capacité de notifier le changement de sélection aux écouteurs (ISelectionProvider) avec le comportement d'une page dans une vue (IPage). Les décomposeurs de contenu sont généralement implémentés à l'aide d'afficheurs JFace. L'implémentation par défaut d'un décomposeur de contenu (ContentOutlinePage) utilise un afficheur d'arborescence JFace pour afficher une représentation hiérarchique de la structure. Cette représentation est adaptée à de nombreux décomposeurs structurés, dont ReadmeContentOutlinePage.

ReadmeContentOutlinePage est d'un aspect très similaire à la vue des sections du readme, illustré ci-dessous, que nous avons vu précédemment lorsque nous avons implémenté l'extension des vues du readme.

En réalité, la seule différence réside dans le fait que le décomposeur affiche une vue hiérarchique des sections, tandis que la vue des sections du readme affiche une liste à plat des sections. Il n'est donc pas surprenant que l'implémentation du décomposeur soit très similaire à celle de la vue, la seule différence étant que le décomposeur utilise un afficheur d'arborescence au lieu d'un afficheur de liste.

Lorsque la page de structure a été créée par l'éditeur, l'élément d'entrée a été transmis dans le constructeur. Cette entrée peut être souvent transmise directement à l'afficheur de la page de structure, comme le montre l'exemple ci-dessous.

public void createControl(Composite parent) {
    ...
    TreeViewer viewer = getTreeViewer();
    viewer.setContentProvider(new WorkbenchContentProvider());
    viewer.setLabelProvider(new WorkbenchLabelProvider());
    viewer.setInput(getContentOutline(input));
    ...
}

La création de l'afficheur d'arborescence est héritée de ContentOutlinePage. Les mêmes fournisseurs de contenu et de libellé utilisés dans la vue des sections du readme sont utilisés ici et la structure du contenu est construite à l'aide de la même méthode ReadmeModelFactory qui a construit les sections pour la vue.

private IAdaptable getContentOutline(IAdaptable input) {
    return ReadmeModelFactory.getInstance().getContentOutline(input);
}

C'est tout !

Bien sûr, le décomposeur lui-même ne fournit pas de comportement intéressant. La sélection des sections ne fait pas naviguer le texte dans l'éditeur ! De toute façon, en quoi ce décomposeur de contenu est-il bon ? Nous pouvons dire que le décomposeur de contenu ne fournit pas de comportement (en dehors de la représentation hiérarchique) que nous n'avons pas déjà vu dans la vue des sections. Ne pourrions-nous pas simplement utiliser un afficheur d'arborescence dans la vue des sections au lieu de fournir un décomposeur qui ne fait rien ?

Il ne s'agit que d'un exemple ! En fait, ReadmeContentOutlinePage est fourni pour montrer comment un décomposeur de contenu peut être personnalisé pour un éditeur de texte. Il ne constitue pas en lui-même un bon exemple de décomposeur de contenu. Les utilisateurs s'attendent à ce que les décomposeurs de contenu les assistent au cours de la navigation dans le contenu de l'éditeur, aussi est-il préférable d'utiliser la vue des sections si le seul but est d'afficher la structure du contenu.

Où est-il possible de trouver des décomposeurs de contenu plus intéressants ? Consultez les sous-classes de ContentOutlinePage et leurs éditeurs correspondants. Le schéma le plus typique est lorsqu'un éditeur fournit une page de structure et enregistre les événements de sélection qui la concerne. Lorsque des éléments sont sélectionnés dans la structure du contenu, l'éditeur se met à jour en fonction.

L'éditeur de code source Java (fourni dans le JDT) comporte un décomposeur de contenu intéressant. Le décomposeur Java présente une vue structurée du code source Java et permet à l'utilisateur de naviguer dans les déclarations, les méthodes et les zones dans l'éditeur correspondant. Comme le décomposeur rapporte les événements de sélection, l'éditeur Java met à jour sa règle verticale pour montrer où se trouvent les éléments du décomposeur dans le code source.