Spintax conditionnel : {?VAR?then|else}

Parfois le choix entre deux formulations n’est pas un pile ou face — il dépend d’un fait. Le produit a une offre gratuite, ou non. Le marchand accepte les cryptomonnaies, ou seulement la monnaie classique. Le spintax conditionnel est le pendant piloté par la valeur de la branche {a|b} : au lieu de tirer au hasard, il choisit selon qu’une variable est truthy ou non.

Les trois formes

La syntaxe conditionnelle ajoute trois jetons à la famille spintax de GTW. Les trois sont évalués avant la résolution des énumérations et des permutations — c’est une passe préalable, pas un branchement à l’exécution.

Le préfixe ! inverse le test. Il n’existe pas de forme distincte {?VAR??else} — si vous ne voulez que la branche falsy, écrivez {?!VAR?else}.

Truthy et falsy

La règle truthy est volontairement plus simple que celle de JavaScript. Vous ne devriez pas avoir à retenir des cas limites de conversion.

C’est toute la règle. Truthy = au moins un caractère qui n’est pas un blanc. S’il vous faut un jour une véracité à la JavaScript, faites ce test dans l’assembleur, avant de passer la variable.

La véracité lit la valeur brute

La recherche porte sur la valeur brute stockée dans la variable. Les références %var% imbriquées dans cette valeur ne sont pas développées pour le test — seulement plus tard, quand expandVariables s’exécute comme étape distincte.

#set %X% = %Other%
{?X?yes|no}     → "yes"

Même si %Other% devait se développer en chaîne vide, la valeur brute de %X% est la chaîne littérale %Other% — non vide, donc truthy. Pour une véracité qui tienne compte de la valeur, écrivez %X% directement en '1' ou ''. Calculez le garde-fou dans l’assembleur avant de le passer.

Le pipeline à deux passes

Le moteur traite un template par étapes. Les conditions obtiennent deux passes d’évaluation :

1. strip comments
2. extract #set / #def directives
3. merge variables
4. apply conditionals       ← pass 1
5. expand %var% references
6. apply conditionals       ← pass 2
7. resolve enumerations
8. resolve permutations
9. post-process

La passe 1 traite les conditions écrites directement dans le corps du template. Elle s’exécute avant le développement des variables, pour qu’une branche falsy soit écartée sans dépenser de cycles sur ses %var%.

La passe 2 traite le cas où la valeur d’une variable contient elle-même une condition :

#set %CTA% = {?HasBonus?Claim bonus|Deposit now}
%CTA%                  /# pass 2 sees the conditional after expansion #/

Une précision : la passe 2 ne boucle pas. Si la branche retenue contient une nouvelle référence %var%, cette référence reste littérale — il n’y a pas de troisième passe de développement. Pour la plupart des templates réels, cela convient ; les garde-fous employés dans les branches conditionnelles (%HasCrypto%, %HasFiat%) sont en général ceux déjà résolus en passe 1.

Exemple travaillé : la section « moyens de paiement »

C’est le cas pour lequel la syntaxe a été conçue. Une page produit affiche une section « Moyens de paiement ». Certains marchands acceptent la crypto, d’autres seulement la monnaie classique, d’autres les deux, quelques-uns n’ont encore aucune intégration de paiement.

L’assembleur de variables calcule deux garde-fous et trois blocs HTML pré-rendus :

%HasCrypto%    "1" or ""
%HasFiat%      "1" or ""
%CryptoSection%   /# already-rendered <h3> + <ul> #/
%FiatSection%
%LimitsSection%

Le template orchestrateur utilise des conditions pour n’ouvrir la ligne de repli qu’aux entrées sans données de paiement :

%FiatSection%%CryptoSection%%LimitsSection%
{?!HasCrypto?{?!HasFiat?<p>Payment details will be published shortly.</p>}}

Lisez la dernière ligne ainsi : si ni crypto ni monnaie classique, rends le paragraphe de repli. Les conditions imbriquées court-circuitent de l’extérieur vers l’intérieur : quand %HasCrypto% = "1", le test falsy externe échoue immédiatement et la condition interne n’est jamais évaluée.

Comparez avec l’ancien contournement — une variable garde-fou remplie par du spintax qui tirait au sort, avec une probabilité pondérée, entre chaîne vide et paragraphe de repli. Cela marchait, mais la sortie n’était pas déterministe et le template devait trimballer une variable de plus. La syntaxe conditionnelle dit exactement ce qu’elle veut dire.

Tirage ou condition — ne pas confondre

Anti-patterns

1. Opérateurs booléens

Il n’y a ni &&, ni ||, ni !=, ni == en spintax conditionnel. La syntaxe est volontairement minimale. S’il vous faut de la logique composée, calculez le booléen dans l’assembleur de variables :

/# wrong: not supported #/
{?HasCrypto && HasLicense?…}

/# right: compose in the assembler #/
#set %ShowCryptoBlock% = {?HasCrypto?{?HasLicense?1}}
{?ShowCryptoBlock?…}

L’assembleur peut utiliser n’importe quel langage hôte et n’importe quelle logique. Spintax reste un outil de template, pas un langage de programmation.

2. #set à l’intérieur d’une branche

Les directives #set sont extraites avant toute passe conditionnelle — c’est l’étape 2 du pipeline. Une ligne #set placée dans une branche {?…?…} s’exécute sans condition ; la condition ne contrôle que la présence du reste vide de la ligne dans le texte de la branche retenue.

/# wrong: both #set lines fire — the second wins #/
{?A?
#set %x% = first
|}{?A?
#set %x% = second
|}%x%
→ always "second", regardless of A

S’il vous faut une affectation conditionnelle, faites-la dans l’assembleur.

3. Un | de premier niveau comme littéral dans then

Le premier | de profondeur 0 dans le corps sépare then de else. Tout | suivant à la profondeur 0 reste littéral — mais dans la branche else, pas dans la branche then.

{?A?x|y|z}     /# A truthy → "x"; A falsy → "y|z" #/

Si la branche then a besoin d’un | littéral, enveloppez-le dans des accolades imbriquées ou utilisez l’entité HTML | :

{?A?{x|y}}             /# inner | is depth 1, not a separator #/
{?A?x | y}         /# explicit entity, renders as "x | y" #/

4. Confondre passe préalable et exécution

Les conditions s’exécutent en passe préalable, avant la résolution des énumérations et des permutations. Autrement dit, une branche falsy est entièrement écartée — aucun tirage aléatoire qu’elle contient ne se produit jamais. Si une permutation %RandomQuirk% se cache au fond de la branche falsy, elle n’est jamais évaluée quand la condition est fausse. Tant mieux. C’est le but.

Analyse tolérante — les formes mal formées ne sont pas fatales

Un ? isolé dans le texte (« Comment ? Comme ça ? ») est courant. L’analyseur est volontairement tolérant : tout {?… qui ne correspond pas à la grammaire reste littéral au lieu de lever une erreur.

Le validateur de ce site (et le playground) signale en revanche les formes équilibrées mais mal formées par un avertissement, pour que vous les attrapiez dans l’éditeur :

À l’exécution, aucune forme mal formée ne lève d’erreur. Le moteur poursuit vers les passes normales d’énumération et de permutation ; des jetons équilibrés mais mal formés peuvent y être consommés — ne comptez donc pas sur leur préservation littérale.

Checklist rapide

• Utilisez {?VAR?…} quand le choix dépend d’une valeur, jamais {a|b}.
• Utilisez {?!VAR?…} plutôt que d’inventer une variable garde-fou « non ».
• Les booléens composés se calculent dans l’assembleur. Les conditions spintax sont atomiques.
• Ne mettez jamais de #set dans une branche — il s’exécute sans condition.
• Si then a besoin d’un | littéral, enveloppez-le dans {…} ou utilisez |.
• Truthy = pas un blanc, point final. Toute véracité particulière se pré-calcule dans l’assembleur.
• Pré-rendez en variables les fragments HTML des sections qui changent de forme selon le locataire. Les conditions les ouvrent.

Essayez en direct

Le playgroundEN contient un exemple {?HasFreeTier?…|…} dans le template par défaut. Basculez %HasFreeTier% entre 1 et vide pour voir les deux branches sans rien taper d’autre.

Continuer la série