La conception de l'éditeur XML indente XML sans tabulations / espaces - inconvénients?
J'ai développé un éditeur de texte XML qui indente XML en utilisant une marge gauche "flottante" plutôt que les caractères de tabulation ou d'espace les plus courants. L'indentation est mise à jour en permanence et ne repose que sur le contexte XML des caractères de nouvelle ligne. L'utilisation prévue de l'outil est pour l'édition XSLT et pour les vocabulaires XML qui ont tendance à être fabriqués à la main et où la gestion des espaces blancs est critique (comme XMLSpec).
Pour que cet outil fonctionne avec XML à partir d'autres sources, tout fichier XML ouvert ou collé à partir du presse-papiers est d'abord analysé pour les caractères en retrait; ceux-ci sont ensuite supprimés avant de rendre le XML formaté.
Après avoir surmonté quelques premiers problèmes importants tels que le formatage des attributs, le XML commenté et la tendance du XML à sauter de manière alarmante sur l'écran, il semble y avoir de nombreux avantages à cela, en termes de lisibilité, d'efficacité/ergonomie de l'interface utilisateur, de traitement , contrôle de version, etc.
Cependant, s'il existe de tels avantages, je me demande pourquoi tous les éditeurs XML ne le font pas déjà.
Ainsi, en termes de convivialité de l'outil et de lisibilité/utilité du XML produit, lorsque les caractères utilisés pour indenter le XML sont supprimés; quels sont les problèmes potentiels et comment dois-je les atténuer?
J'ai testé d'autres éditeurs XML avec du XML produit par cet outil. Ils réussissent tous à reformater raisonnablement le XML (sauf pour les attributs - qui ont des conventions d'indentation plus variables) en insérant des caractères de remplissage.
L'éditeur fournit également une autre vue où la marge gauche est réduite, mais aucun caractère n'est affecté. Dans les exemples liés ci-dessous, l'élément en surbrillance dans chaque vue montre le seul endroit (zone en surbrillance sans caractères) où des caractères d'espace ont été ajoutés par l'auteur pour l'indentation. Cela était nécessaire pour mettre en retrait une seule ligne dans une valeur d'attribut multiligne, de sorte que le contexte XML n'était pas suffisant.
Captures d'écran de l'éditeur XML: comparaison des vues indentées et non indentées
[Modifier] Encore quelques points:
Le texte se déplaçant sur l'écran pendant la saisie de l'utilisateur présente certains défis (comme déjà mentionné). Cependant, l'utilisation de la saisie semi-automatique des balises/attributs et du formatage différé est utile. De plus, il y a déjà quelques mouvements de balises dans les éditeurs plus conventionnels, donc ce comportement ne sera pas complètement inattendu.
Une attention particulière a été portée à la gestion des raccourcis clavier qui ont des effets spéciaux sur les espaces blancs (comme ctrl-backspace ou tab) pour qu'il n'y ait pas trop de surprises.
L'éditeur fonctionne mieux avec le retour automatique à la ligne, mais de nombreux utilisateurs suivent les conventions de l'éditeur de texte pour maintenir une longueur de ligne maximale en insérant des sauts de ligne. Une fonctionnalité facultative supprime de tels sauts de ligne, mais il est reconnu que cela pourrait causer autant de problèmes qu'elle en résout.
La raison derrière les balises XML à indentation automatique trouvées dans les commentaires est que les blocs de XML peuvent être commentés/non commentés à volonté. Les blocs CData, bien qu'ils puissent contenir des balises XML, sont traités comme du texte normal; c'est parce que les balises CData ne peuvent pas être supprimées sans rendre le XML invalide. Le contenu de CData est coloré différemment du texte analysé pour éviter toute confusion au sujet de l'indentation.
Indentation de XML dans les commentaires: bien qu'automatisée, elle est indépendante de la "vraie" indentation XML pour éviter tout élément dans les commentaires affectant la mise en forme du reste du XML.
Collage vers d'autres outils XML - Parce qu'il n'y a pas de retrait "étranger" à gérer par l'éditeur, cela fonctionne probablement mieux que lors de la copie entre 2 outils conventionnels.
Collage sur des outils texte uniquement (comme un wiki) - Cela pose problème à moins que cet outil ne reconnaisse RTF.
Une option pour économiser avec un espace blanc pourrait être fournie, cependant, un "outil de reformatage" redistribuable/en ligne pourrait fournir plus de flexibilité?
Juste pour info: cet éditeur a été initialement publié dans le cadre d'un système de traitement XML beaucoup plus large, cependant, pour obtenir des commentaires plus généraux, j'ai également publié une version gratuite plus simple et plus légère, XMLQuire . Compte tenu du nombre de téléchargements du jour 1 pour cela, j'espère être en mesure d'évaluer les inconvénients directement à partir des commentaires des utilisateurs en direct assez rapidement ...
[mise à jour] Les téléchargements de produits utilisant ce système fonctionnent à environ 200 par semaine, donc le nombre total de téléchargements doit maintenant dépasser 10 000. Aucun utilisateur ne s'est encore plaint de la gestion des espaces blancs, mais seulement quelques-uns sont revenus avec des commentaires élogieux. Il semble que pour beaucoup, cette fonctionnalité passe largement inaperçue.
Vous modifiez les conventions normales de l'éditeur, les utilisateurs devront donc s'habituer à et non à taper les espaces/tabulations et aussi à sauter le texte à droite lorsqu'ils terminent une nouvelle balise d'ouverture et laissé à la fin d'une balise de fermeture. Rien de tout cela ne semble être un obstacle de taille. En effet, vous exécutez "Prettify" à chaque pression de touche, et donnez ainsi un retour plus réactif. Vous pouvez le voir comme étant analogue à la coloration syntaxique en surbrillance lorsque vous tapez. Les gens ont dû s'adapter à cela, mais c'est une victoire nette.
Les questions d'utilisabilité qui me viennent à l'esprit sont dans la zone grise entre les questions UX et les questions sur les fonctionnalités de l'application.
- Et <! CDATA []]>? Le retrait automatique sera-t-il désactivé pour cela? Ou éventuellement désactivé? Il pourrait être un peu déroutant de mélanger l'automatisation de l'indentation et du manuel. Ce n'est pas un problème avec une application où tout le formatage est manuel.
- L'application fonctionne sans retrait en interne. Puis-je exporter/enregistrer avec retrait si je le souhaite? Je pourrais vouloir l'utiliser avec un éditeur qui ne peut pas automatiquement ajouter une indentation, ou couper et coller sur un wiki.
Modifier
Merci pour la mise à jour.
Cela ressemble maintenant au genre de chose où l'on ne peut faire des commentaires plus utiles et détaillés qu'en l'essayant. Il y a quelque temps, j'ai écrit un "assembleur instantané" qui faisait toute la vérification de la syntaxe et du type, l'expansion des macros, la génération de code comme vous l'avez tapé. Obtenir la réactivité requise n'a pas été facile, mais au final, les principaux problèmes de convivialité n'étaient pas là. Les problèmes d'utilisation étaient liés au comportement de sélection du texte qui n'implémentait pas tous les détails de la sélection normale de l'éditeur (faire glisser pour étendre provoquant le défilement de la fenêtre) - et cela s'est produit parce que je ne le fais pas moi-même, et parce que je n'ai pas pu étendre simplement une norme contrôle de l'éditeur.
Alors testez, avec un à trois utilisateurs et obtenez leur avis. Les problèmes ne sont probablement pas dans la zone qui vous inquiète.
Je dirais que vous seriez très en sécurité pour exécuter votre idée. Il semble que vous ayez la possibilité que les gens qui veulent vraiment utiliser des espaces explicites puissent le faire, et votre marché cible semble suffisamment instruit en informatique pour qu'ils trouvent cette option - s'ils s'avèrent justement vouloir s'en tenir à l'ancienne façon de le faire .
Cela semble une bonne idée. Bonne chance.
Si vous supprimez réellement des caractères d'indentation de la source, par opposition au simple rendu comme s'ils n'étaient pas là, alors vous risquez de rompre l'interopérabilité avec d'autres éditeurs. Une personne qui a créé un fichier XML formaté manuellement dans, disons, emacs (ou le Bloc-notes ou autre), puis a utilisé votre éditeur avec, ne devrait pas perdre sa capacité à revenir à son éditeur d'origine.