Données fixes
Données fixes (e_fixed_data) produit un flux écrit à la main. Deux
formes, un même stockage — des colonnes et des lignes.
Le besoin
Deux cas quotidiens n'avaient aucune réponse simple :
- Une ligne, souvent faite de variables. Dans une boucle, traiter l'item
courant comme un flux à part entière demande de le poser quelque part :
${var.item.FILE_NAME}doit devenir une colonne. - Une petite table de référence, tapée sur place. « 1 c'est toto, 2 c'est tata » : trois lignes qu'on ne va ni créer en base, ni maintenir dans un CSV à côté du flux.
Le seul recours était Code Python — écrire du pandas pour trois lignes, c'est-à-dire mettre du code là où il n'y a qu'une donnée, et le sortir du regard de qui relit le flux.
Les deux formes
mode | Ce que l'écran montre | Ce qui sort |
|---|---|---|
row | une liste verticale champ → valeur | une ligne |
table | la grille | une ligne par ligne saisie |
En mode row, les lignes au-delà de la première sont écartées et dites —
elles ne sont pas effacées, pour qu'un aller-retour entre les deux formes ne
fasse rien perdre.
Chaque case est une expression
Il fallait choisir, par colonne, entre Valeur et Formule. Les deux ne s'opposaient pas sur la nature du contenu mais sur son arité : N cases, une par ligne, contre une expression pour toute la série. En mode « une ligne », N vaut 1 — le choix ne distinguait plus rien, et se tromper de case coûtait un run.
Une case est donc une expression FQL, partout :
| Ce qu'on écrit | Ce que ça vaut |
|---|---|
1 | l'entier 1 |
-2.5 | le nombre −2,5 |
'toto' | le texte toto |
toto | la colonne toto, déclarée avant celle-ci |
TODAY() | la date du jour |
${var.item.ID} | la variable, résolue à l'exécution |
C'est le prix d'un langage unique : toto désigne une colonne. Sans
quotes, la brick s'arrête en nommant la colonne introuvable — et le message
rappelle le geste.
Une expression de série garde son sens
Une case est évaluée sur la table entière, et l'on en prend le rang
correspondant. NB_LIGNES() voit donc toutes les lignes, et écrire la même
expression dans toutes les cases d'une colonne revient exactement à l'ancienne
colonne « calculée » :
HT 100 50
TTC HT * 1.2 HT * 1.2
Les cases identiques ne sont évaluées qu'une fois : c'est le cas courant, et il ne coûte pas plus cher qu'avant.
Une colonne ne voit que celles qui la précèdent : l'ordre de déclaration est l'ordre de calcul. C'est la même règle que Colonne calculée. L'ordre d'affichage reste celui de la déclaration : ranger les colonnes dans l'ordre du calcul ferait bouger une table sous les yeux.
Les références sont LIÉES, pas collées
Une référence ${…} ne se colle pas dans l'expression : elle y est liée,
comme un paramètre de requête SQL.
La raison est dure : FQL n'a aucun échappement de chaîne. Un texte portant à la fois une apostrophe et un guillemet n'a donc aucune écriture littérale possible. Collé brut, un document se retrouvait au milieu de l'expression, et le parseur signalait son premier caractère inattendu :
colonne « OCR » : caractère inattendu « { »
Exact, et incompréhensible : le type déclaré était TEXTE, la valeur était du texte. Liée, la donnée ne traverse jamais le parseur — contenu quelconque, type préservé — et elle se combine au reste :
${var.item.OCR_JSON} → le document entier
UPPER(${var.item.NOM}) → TOTO
C'est ce qui rend le cas de la boucle immédiat :
Pour chaque ligne → Données fixes (une ligne) → …
ID ← ${var.item.ID}
FICHIER ← ${var.item.FILE_NAME}
${var.item.…} n'a pas de plafond${(brick).colonne} lit une valeur publiée, et la publication s'arrête à 512
caractères — un JSON d'OCR n'y tient pas. ${var.item.…} lit la ligne que la
boucle passe à son corps : elle arrive entière.
Le type est déclaré, jamais deviné
Une colonne de « 1, 2, 3 » tapée à la main pourrait être un entier, un texte de
codes, ou un identifiant à zéros non significatifs. Deviner reviendrait à
trancher au hasard, et à changer d'avis le jour où quelqu'un ajoute 01.
Chaque colonne porte donc son type, et la conversion est celle du reste du moteur.
Pas en texte vide. Sur du texte la nuance se discute ; sur un entier, '' ne se
convertit pas et ferait échouer toute la brick pour une case qu'on a simplement
laissée tranquille.
Une valeur qui ne se lit pas comme le type déclaré arrête la brick, en nommant la colonne. Mettre un vide à la place transformerait une faute de frappe en donnée manquante, découverte bien plus loin.
Coller depuis un tableur
« Un ensemble de règles » existe déjà quelque part — un Excel, un mail. Le bouton Coller un tableau lit :
- la première ligne comme les en-têtes, convention du copier-coller de tableur ;
- la tabulation ou le point-virgule comme séparateur.
Elle est trop courante dans les libellés : « Dupont, Jean » se découperait en deux colonnes, et la table arriverait fausse sans que rien ne le dise.
Le collage remplace colonnes et cases. Les valeurs sont mises entre
quotes au passage — un tableur rend toto, qui en FQL désignerait une
colonne : sans cette traduction, le premier run échouerait sur autant de
colonnes introuvables qu'il y a de libellés. Les nombres restent nus. Les types
repartent en texte : ils se déclarent ensuite, colonne par colonne.
Ce qui est pardonné, et ce qui ne l'est pas
Une ligne trop courte est complétée de vides, une trop longue est rognée — une saisie décalée d'une cellule ne doit pas faire échouer tout le flux. Une colonne sans nom n'est pas produite : ce n'est pas une colonne à moitié, c'est une ligne qu'on vient d'ouvrir.