実際に動作するダッシュボード。
ほとんどのダッシュボードは構造上、読み取り専用です。数字を表示するだけで、対処するには別の場所へ移動しなければなりません。dash-b のタイルにはボタンを持たせることができ、押すと行を書き込み、更新し、あるいはご自身のテーブルから作られたフォームを開きます。
2つのタイル
ボタン、またはフォーム
操作
ラベルは自由に選べるボタンが1つ。ご自身のテーブルの1つに対して、名前付きの単一操作を実行します — 本日の売上を入金済みにする、シフトを追加する、チケットを閉じる。入力は不要、押すだけです。
データフォーム
操作に詳細が必要な場合も同様です。フィールドはデザインが宣言するものではなくテーブル自身のスキーマから引き出されるため、列の名前を変更すればフォームが変わり、列を削除すればその入力は求められなくなります。
アクションとは何か
3つのキー、4つ目はない
アクションは操作の名前、その対象の名前、そしてパラメータを渡します。語彙はこれですべてです:
- コマンドは、dash-b 自身のコードだけが追加できるレジストリへのインデックスです。デザインが新たに作り出すことはできません。
- バインディングは名前であり、ボタンが押された時点であなたのアカウントが保持するドキュメントに対して解決されます。あなたが持っていないテーブルを名指すデザインが誰かから送られてきた場合、停止してその旨を伝えます。
- パラメータはリテラル、またはフォーム、タイル、押下から読み取る名前付きの値の1つです。1階層までで、それ以上はありません。
アクションに書き込まれた URL、ヘッダー、トークン、ロールは、無効なキーです。
dash-b のどの部分もそれらを読み取りません。テストは4つすべてを含むアクションを送出し、どれもハンドラーに届いていないことを確認します。
この語彙は意図的に弱くしてあります。パラメータ言語に演算子を1つ追加するたびに、見知らぬ人同士が送り合うファイルの中でルールエンジンが動く方向へ一歩近づきます。デザインファイルは他人のロジックを実行する場所ではありません。
書き込みが守るべきルール
このうち3つは、dash-b の他の部分の動作とは逆になっています
未知のコマンドは大きなエラーになる
他のどこでは、認識できないキーは静かに無視されます。デザインは自分より新しいバージョンに出会っても生き延びるべきだからです。ここは違います。黙って何もしない書き込みは、成功した書き込みとまったく同じに見えてしまうからです。
実際の押下のみが有効
人が実際にボタンを押したかどうかは、デザインではなくランタイムが判定します。ジェスチャーが起きたと主張するデザインは拒否されます。
データを変更するものはすべて確認を求める
操作は、読み取り専用、ローカル、または変更を伴うもののいずれかです。変更を伴う操作はまず確認を求め — 確認を省くことはできません — 二重押下が1回しか着地しないようにするキーが与えられます。
表示されない場所
書き出したHTMLページには表示されない
デザインをスタンドアロンのページとして書き出すと、ボタンは含まれません。書き出し物は dash-b のコードを一切実行しないため、そこにフォームがあれば誰かの入力を集めても送り先がない — それは最初から提供しないことより悪い結果です。このタイルはデザイナーとアカウントの機能であり、書き出し物はそれを省くことでその旨を示します。
公開リンクについても同様です。読者が見えるものと見えないものは、タイルが誰のデータにバインドされているかで決まります — 共有の仕組みに両方のケースが説明されています。
書き込み先のテーブルが必要です。
それはご自身のアカウント上のテーブルでも、ご自身がホストするコネクタ経由で到達する独自のデータベースでも構いません — その場合、データベースのパスワードが当社に届くことは決してありません。