Je suis en train d'écrire une application dont l'une des caractéristiques est de permettre à l'utilisateur d'écrire un modèle de courriel en utilisant la syntaxe Markdown.
Outre le formatage, l'utilisateur doit pouvoir utiliser des caractères de substitution pour quelques variables qui seront remplacées au moment de l'exécution.
La façon dont cela fonctionne actuellement est très simple : les modèles contiennent les caractères de remplacement pythoniques %(var)s et je les remplace par un dictionnaire avant d'appliquer le formatage Markdown2.
Il s'avère que l'utilisateur final de ce système sera un utilisateur averti et je ne voudrais pas qu'il soit évident pour tout le monde que le système est écrit en Python.
Ce n'est pas que je n'aime pas Python... En fait, je pense que Python est l'outil parfait pour ce travail, mais je ne veux pas l'exposer à l'utilisateur (je ferais la même chose s'il était écrit en Java, Perl, Ruby ou autre).
J'aimerais donc savoir ce qui serait, à votre avis, la meilleure façon d'exposer les espaces réservés aux utilisateurs :
-
Selon vous, quel est le meilleur format pour les caractères de remplacement (pensez à ${var}, $(var) ou #{var}) ?
-
Quelle serait la meilleure façon de remplacer ces espaces ?
J'ai pensé à utiliser une expression régulière pour transformer, par exemple, ${var} en %(var)s, puis à appliquer la substitution régulière du modèle Python, mais je ne suis pas sûr que ce soit la meilleure approche.
Si vous allez dans ce sens, ce serait très bien si vous pouviez m'indiquer ce qu'est un brouillon de cette expression régulière également.
Merci !
Mise à jour : Un utilisateur m'a suggéré d'utiliser des systèmes de templating complets, mais je pense que cela ne vaut peut-être pas la peine, puisque tout ce dont j'ai besoin est la substitution de placeholders : Je n'aurai pas de boucles ni rien de tel.
Mise à jour finale : J'ai choisi de ne pas utiliser de moteurs de modèles pour le moment. J'ai choisi de suivre l'approche plus simple de string.Template (comme indiqué dans un commentaire de hyperboréen ). La vérité est que je n'aime pas choisir une solution parce qu'un jour, dans le futur, il pourrait y avoir un besoin. Je garderai toutes ces suggestions dans ma manche, et si au cours de la durée de vie de l'application il y a un besoin clair pour une ou plusieurs fonctionnalités offertes par celles-ci, je réexaminerai l'idée. Pour l'instant, je pense vraiment que c'est une surenchère. Avoir des modèles complets qui l'utilisateur final peut éditer comme il veut est, du moins de mon point de vue, plus problématique que bénéfique. Néanmoins, il est beaucoup plus agréable d'être conscient des raisons pour lesquelles je n'ai pas suivi cette voie, que de ne pas faire de recherches et de choisir.
Merci beaucoup pour toutes ces informations.
