dash-b · Fonctionnalités · Au clic
Un tableau de bord qui fait quelque chose.
La plupart des tableaux de bord sont en lecture seule par construction : ils vous montrent un nombre et vous laissent aller ailleurs pour agir dessus. Une tuile dash-b peut porter un bouton, et le presser écrit une ligne, en met une à jour, ou ouvre un formulaire construit à partir de votre propre table.
Deux tuiles
Un bouton, ou un formulaire
Action
Un bouton avec une étiquette que vous choisissez. Il exécute une seule opération nommée sur l'une de vos tables — marquer les recettes du jour comme encaissées, ajouter un shift, fermer un ticket. Rien à taper, une pression.
Formulaire de données
La même chose quand l'opération nécessite des détails. Les champs sont tirés du schéma propre à la table plutôt que de ce que le design déclare, si bien qu'une colonne que vous renommez change le formulaire et qu'une colonne que vous supprimez cesse d'être demandée.
Ce qu'est une action
Trois clés, et pas de quatrième
Une action nomme une opération, nomme sur quoi elle opère, et transmet des paramètres. C'est tout le vocabulaire :
- La commande est un index dans un registre que seul le code de dash-b peut enrichir. Un design ne peut pas en inventer une.
- La liaison est un nom, résolu au moment où le bouton est pressé contre les documents que votre compte détient. Un design qu'on vous envoie et qui nomme une table que vous n'avez pas s'arrête et le dit.
- Les paramètres sont un littéral, ou une valeur nommée lue dans le formulaire, la tuile ou la pression. Un niveau de profondeur, et rien d'autre.
Une URL, un en-tête, un jeton ou un rôle écrit dans une action est une clé morte.
Rien dans dash-b ne les lit. Un test envoie une action portant les quatre et vérifie qu'aucun n'a atteint le gestionnaire.
Le vocabulaire est délibérément faible. Chaque opérateur ajouté à un langage de paramètres est un pas vers un moteur de règles vivant dans un fichier que des inconnus s'envoient entre eux, et un fichier de design n'est pas un endroit où exécuter la logique de quelqu'un d'autre.
Les règles qu'une écriture respecte
Trois d'entre elles inversent le comportement du reste de dash-b
Une commande inconnue est une erreur bruyante
Partout ailleurs, une clé non reconnue est ignorée en silence, parce qu'un design doit survivre à la rencontre d'une version plus récente de lui-même. Pas ici : une écriture qui ne fait rien en silence ressemble exactement à une écriture qui a réussi.
Seul un appui réel compte
Le fait qu'une personne ait réellement pressé le bouton est décidé par le runtime, jamais par le design. Un design qui affirme qu'un geste s'est produit est refusé.
Tout ce qui modifie des données demande une confirmation
Les opérations sont en lecture seule, locales, ou modifiantes. Une opération modifiante demande d'abord — et ne peut pas se soustraire à la demande — et reçoit une clé qui fait qu'une double pression n'atterrit qu'une fois.
Où elle n'apparaît pas
Pas dans une page HTML exportée
Exportez un design comme page autonome et les boutons n'y sont pas. Un export n'exécute aucun code de dash-b, si bien qu'un formulaire y recueillerait la saisie de quelqu'un sans nulle part où l'envoyer — ce qui est pire que de ne pas l'offrir du tout. La tuile est une fonctionnalité du designer et du compte, et l'export le dit en l'omettant.
Il en va de même pour un lien publié. Ce qu'un lecteur peut voir, et ce qu'il ne peut pas, est décidé par les données auxquelles la tuile est liée — comment fonctionne le partage expose les deux cas.
Elle a besoin d'une table où écrire.
Cela peut être une table sur votre compte, ou votre propre base de données atteinte via un connecteur que vous hébergez — auquel cas aucun mot de passe de base de données ne nous parvient jamais.