Syntaxe Xporter : ce qui fonctionne
Un état des lieux honnête du traitement de la syntaxe de modèles de style Xporter lorsque vous téléversez un document Word dans le mode modèle Word. Il reflète l'analyseur de migration exécuté à chaque téléversement — les mêmes classifications que celles du rapport de compatibilité de l'éditeur.
La promesse honnête
Exportelier n'est pas compatible Xporter, n'est pas un remplaçant de Xporter et n'exécute pas les modèles Xporter. Ce qu'il fait, c'est vous aider à migrer : au téléversement, l'analyseur reconnaît la syntaxe courante de style Xporter et vous indique, construction par construction, si elle fonctionne déjà, si elle peut être convertie automatiquement, si elle nécessite une réécriture manuelle ou si elle est hors périmètre par conception.
Deux garanties fermes :
- La syntaxe étrangère est seulement reconnue, jamais exécutée. L'analyseur lit la forme d'une construction —
#{for …},${dateformat(…)}— et rien d'un modèle téléversé n'est jamais évalué comme du code. - Aucun code tiers n'est copié. Les motifs de détection et les suggestions d'alias sont rédigés par Exportelier à partir de formes de syntaxe publiquement documentées.
Chaque constat relève de l'une de quatre catégories.
1. Fonctionne sans changement
Si votre modèle utilise déjà la syntaxe canonique d'Exportelier, il fonctionne tel quel. Cela produit une note d'information, pas un avertissement.
| Construction | Exemple |
|---|---|
| Jeton de valeur | ${issue.key} |
| Boucle | ${#each issue.subtasks as sub}…${/each} |
| Condition | ${#if issue.assignee}…${#else}…${/if} |
2. Convertible automatiquement
Syntaxe Xporter courante ayant un équivalent sûr et univoque. L'éditeur affiche un avertissement et propose un remplacement copiable.
| Construction Xporter | Équivalent Exportelier | Remarques |
|---|---|---|
${Key}, ${Summary}, ${Status}, … | ${issue.key}, ${issue.summary}, ${issue.status}, … | Alias de champs scalaires. |
${Assignee.displayName} | ${issue.assignee.displayName} | Alias de racine connu ; le reste du chemin est conservé. |
#{for comments} | ${#each comments as c} | Ouverture de boucle. |
#{if(Assignee)} | ${#if issue.assignee} | Condition simple de présence. |
#{else} | ${#else} | Marqueur else. |
Alias scalaires reconnus (16) : Key, Summary, Description, Status, Priority, Resolution, Assignee, Reporter, Creator, Created, Updated, DueDate, IssueType, Type, Project, Labels.
Alias de collection reconnus (5) : Comments, Attachments, Subtasks, Links, Worklogs.
Une suggestion a la bonne forme, mais la cible doit rester une liaison réelle de la référence des jetons. Certains alias exigent un ajustement manuel :
- Non liables :
Creator→issue.creator,Resolution→issue.resolution,Project→issue.project,IssueType/Type→issue.issuetype. Aucun n'est une liaison de niveau A. - Différence de casse :
DueDateest suggéré commeissue.duedate; la liaison estissue.dueDate. - Type incorrect :
Labelsest suggéré comme scalaire, maisissue.labelsest une collection — utilisez${#each issue.labels as l}…. - Liens de tickets :
Linksest suggéré commelinks, mais la liaison réelle estissue.issueLinks.
3. Non pris en charge mais explicable
Pas de correspondance univoque nette, mais un moyen clair d'exprimer la même intention. L'éditeur explique la réécriture ; c'est un avertissement, pas un blocage.
| Construction Xporter | Pourquoi | Que faire à la place |
|---|---|---|
${Comments[0].Body} | Les chemins n'acceptent pas l'indexation entre crochets. | Itérez : ${#each comments as c}${c.body}${/each}. |
#{end} | Un terminateur générique. | Utilisez la fermeture correspondante : ${/each} ou ${/if}. |
#{if(votes > 0)} | Les conditions ne testent que la présence d'un chemin ; pas d'opérateurs. | Testez la présence : ${#if issue.votes}. |
#{elseif(…)} | elseif n'existe pas. | Imbriquez les conditions. |
Toute autre directive #{…} | Non reconnue. | Remplacez-la par la syntaxe ${…}. |
${#each}/${/if} déséquilibrés, chemin erroné, ${ non fermé | Détecté par l'analyseur syntaxique. | Corrigez le jeton ; le rapport indique la position exacte. |
4. Non sûr ou non pris en charge
Hors périmètre à dessein : les prendre en charge transformerait le modèle en moteur de scripting, ce qu'Exportelier n'est délibérément pas. L'éditeur affiche une erreur et la construction n'est jamais exécutée.
| Construction Xporter | Statut | Que faire à la place |
|---|---|---|
${dateformat("yyyy-MM-dd")} et autres appels de fonctions ou de filtres | Les fonctions ne sont jamais exécutées. | Utilisez le jeu fixe de formateurs, p. ex. ${issue.created | date("yyyy-MM-dd")}. |
${jql("project = ABC")} / #{JQL: …} | JQL n'est jamais exécuté depuis un modèle. | Choisissez les tickets via le contexte d'export. |
| JavaScript, Groovy, Velocity, FreeMarker, filtres JS | Ce n'est pas un langage de script. | Exprimez la mise en page avec jetons, boucles, conditions et formateurs. |
Variables set, break/continue, arithmétique, expressions | Ce n'est pas un langage de script. | Restructurez avec les constructions prises en charge. |
Ce que le validateur fait de ces constats
Au téléversement, chaque constat devient un diagnostic assorti d'une gravité :
- info — fonctionne sans changement, aucune action.
- warning — convertible automatiquement ou explicable ; l'export se poursuit, mais une valeur peut rester vide si la liaison est inconnue.
- error — syntaxe non sûre ou non prise en charge, chemin non sûr ou erreur d'analyse.
Les constructions que Word conserve mais ne remplit pas — zones de texte, notes de bas de page, contrôles de contenu, codes de champ, commentaires et suivi des modifications — sont signalées à part comme avertissements unsupported-location. Le document les conserve, mais les jetons qu'elles contiennent ne sont pas remplis.