Skip to main content

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 :

  1. 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.
  2. 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​

modeCe que l'écran montreCe qui sort
rowune liste verticale champ → valeurune ligne
tablela grilleune 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 écritCe que ça vaut
1l'entier 1
-2.5le nombre −2,5
'toto'le texte toto
totola colonne toto, déclarée avant celle-ci
TODAY()la date du jour
${var.item.ID}la variable, résolue à l'exécution
Un texte s'écrit entre quotes

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.

Une cellule vide sort VIDE

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.
La virgule n'est pas un 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.