dash-b · Functies · Bij klikken
Een dashboard dat iets doet.
De meeste dashboards zijn van constructie alleen-lezen: ze tonen je een getal en laten je ergens anders heen gaan om het erop te acteren. Een dash-b-tegel kan een knop bevatten, en als je erop drukt wordt er een rij weggeschreven, één bijgewerkt, of een formulier geopend dat uit je eigen tabel is opgebouwd.
Twee tegels
Een knop, of een formulier
Actie
Eén knop met een label dat je zelf kiest. Hij voert één benoemde bewerking uit op een van je eigen tabellen — de opbrengst van vandaag als gebankst markeren, een dienst toevoegen, een ticket sluiten. Niets om te typen, één druk.
Gegevensformulier
Hetzelfde wanneer de bewerking details nodig heeft. De velden komen uit het eigen schema van de tabel en niet uit iets dat het ontwerp aangeeft, dus een kolom die je hernoemt verandert het formulier en een kolom die je verwijdert wordt niet meer gevraagd.
Wat een actie is
Drie sleutels, en geen vierde
Een actie benoemt een bewerking, benoemt waarop die werkt, en geeft parameters door. Dat is de hele woordenschat:
- Het commando is een index in een register waaraan alleen dash-b's eigen code iets kan toevoegen. Een ontwerp kan er geen verzinnen.
- De binding is een naam, opgelost op het moment dat je op de knop drukt, tegen de documenten die jouw account bevat. Een ontwerp dat iemand je stuurt en dat een tabel benoemt die jij niet hebt, stopt en zegt dat.
- De parameters zijn een letterlijke waarde, of één benoemde waarde die wordt gelezen uit het formulier, de tegel of de druk. Eén niveau diep, en niets anders.
Een URL, een header, een token of een rol die in een actie is weggeschreven is een dode sleutel.
Niets in dash-b leest ze. Een test verstuurt een actie met alle vier erin en controleert dat geen van hen de handler bereikt.
De woordenschat is opzettelijk zwak. Elke operator die aan een parametertaal wordt toegevoegd is een stap richting een regelmotor die in een bestand leeft dat vreemden elkaar toesturen, en een ontwerpbestand is geen plek om iemand anders' logica te draaien.
De regels waaraan een schrijfactie gehoorzaamt
Drie van deze zijn omkeringen van hoe de rest van dash-b zich gedraagt
Een onbekend commando is een luidkeelse fout
Overal elders wordt een onbekende sleutel stilletjes genegeerd, omdat een ontwerp een nieuwere versie van zichzelf moet overleven. Niet hier: een schrijfactie die stilletjes niets doet ziet er precies hetzelfde uit als een die werkte.
Alleen een echte druk telt
Of een persoon daadwerkelijk op de knop heeft gedrukt wordt beslist door de runtime, nooit door het ontwerp. Een ontwerp dat beweert dat een gebaar heeft plaatsgevonden wordt geweigerd.
Alles wat gegevens wijzigt, vraagt om bevestiging
Bewerkingen zijn alleen-lezen, lokaal, of wijzigend. Een wijzigende vraagt eerst — en kan niet afzien van het vragen — en krijgt een sleutel waardoor een dubbele druk één keer aankomt.
Waar het niet verschijnt
Niet in een geëxporteerde HTML-pagina
Exporteer je een ontwerp als zelfstandige pagina, dan zitten de knoppen er niet in. Een export draait geen enkele code van dash-b, dus een formulier daar zou iemands invoer verzamelen en nergens naartoe kunnen sturen — wat erger is dan het helemaal niet aanbieden. De tegel is een designer- en accountfunctie, en de export zegt dat door hem weg te laten.
Hetzelfde geldt voor een gepubliceerde link. Wat een lezer kan zien en wat niet, wordt bepaald door aan wiens gegevens de tegel is gebonden — hoe delen werkt zet beide gevallen uiteen.
Het heeft een tabel nodig om naar te schrijven.
Dat kan een tabel op je account zijn, of je eigen database die je bereikt via een connector die jij host — in welk geval er nooit een databasewachtwoord bij ons terechtkomt.