スクリプトとサーバースクリプトの全体像
プリザンターでは、ブラウザで実行する「スクリプト」と、サーバーで実行する「サーバースクリプト」を使って処理を追加できます。どちらも JavaScript を書きますが、使えるオブジェクト、実行される場所、変更する値の反映先が異なります。
最初に「どこで動くか」「いつ動くか」「どこの値を変えるか」を決めます。この3つを分けると、表示だけの変更と保存する変更を区別できます。
どこで動くか
| 比較する点 | スクリプト | サーバースクリプト |
|---|---|---|
| 実行場所 | 利用者のブラウザ | プリザンターのサーバー |
| 実行の仕組み | ページに出力された JavaScript を実行 | ClearScript の V8 エンジンで JavaScript を実行 |
| 主な入口 | 出力先の画面、$p.events のイベント | 作成前・更新前・画面表示の前などの実行条件 |
| 主に扱うもの | $p、jQuery、画面の入力欄や表示要素 | context、model、columns、items など |
| 値の変更 | DOM や送信バッファを変更 | サーバー側のレコードモデルや表示設定を変更 |
| DB 保存との関係 | 本体の送信・保存処理へ値を渡す | 通常の作成・更新処理、または明示的な更新処理へ値を渡す |
ブラウザ側のスクリプトは HTML への出力処理でページに組み込まれます。サーバー側は V8 エンジンの生成と ホストオブジェクトの登録・実行を通ります。
$p.getControl() はブラウザの入力要素を取得する関数です。サーバースクリプトの model はサーバーから渡されたオブジェクトです。同じ項目を扱っていても、この2つを直接共有しているわけではありません。
いつ動くか
ブラウザ側には2段階の指定があります。
- 出力先で、どの画面にスクリプトを含めるかを指定する。
- イベントで、出力したコード内の処理をいつ呼ぶかを指定する。
例えば出力先を編集画面にして、$p.events.on_editor_load に関数を代入すると、編集画面の読み込みイベントでその関数が呼ばれます。出力先を選ぶだけで、コード全体が項目変更のたびに再実行されるわけではありません。
根拠は 新規・編集の出力先選択、読み込みイベントの呼び出し、登録関数の実行です。
サーバー側は、作成前・更新前・行表示の前などの条件に合うスクリプトが実行されます。「編集画面を開く」と「編集画面から更新する」は別の操作です。画面を開いただけでは作成前・更新前の処理は走りません。詳しい呼び出し順は 操作別の実行順で確認できます。
どこの値を変えるか
| 値の場所 | 何を保持するか | 代表的な操作 | 次に確認すること |
|---|---|---|---|
| DOM | 現在の入力欄や表示 | $p.setValue()、jQuery の .val() | 送信する値にも登録されたか |
| 送信バッファ | フォームごとの送信用の値 | $p.setData()、$p.set() | 実際のリクエストに含まれたか |
| サーバーのレコードモデル | 処理中のレコード値 | model.Title などへの代入 | 編集権限を通り、保存処理へ進んだか |
| DB | 保存されたレコード値 | 本体の作成・更新処理 | 再取得した値がどうなっているか |
| ブラウザへの応答 | 表示の差し替えや命令 | context.AddResponse() | ブラウザがどの命令を適用したか |
$p.set() は対象のコントロールの値を変更してから $p.setData() を呼びます。一方、$p.getData() は送信バッファを返す関数であり、呼ぶだけでは入力欄の値を収集しません（set・getData・setData の実装）。
サーバー側の model への代入も、直ちに DB 更新する命令ではありません。変更した項目は編集可能か判定され、レコードモデルへ戻されます。その後の作成・更新処理に含まれるかは実行条件で変わります（編集可能項目の抽出、変更値の反映）。
編集して保存するまでを通して見る
次は記録テーブルの通常の編集・更新を説明する模式図です。個別のプロセス処理、関連情報の更新、応答形式による分岐は省略しています。
図を読み込み中…
ブラウザの送信処理は send()、入力反映と検証は ResultUtilities.Update()、更新前後の処理は ResultModel.Update()が根拠です。
この図では、ブラウザの検証、サーバーの標準検証、更新前スクリプトが別の段階にあります。「更新前」は、標準検証も含めた全処理の最初を意味しません。
処理をどちらに置くか
次は、上の実行場所と反映先に基づく設計上の選び方です。
| やりたいこと | 起点にする場所 | 判断理由 |
|---|---|---|
| 入力欄の表示や操作を補助する | ブラウザのスクリプト | DOM とブラウザのイベントを扱う |
| 画面で変更した値を保存へ渡す | $p.set() と本体の送信処理 | 表示と送信バッファの両方を見る必要がある |
| 作成・更新する値を整える | 作成前・更新前のサーバースクリプト | 保存前のレコードモデルを変更する |
| 一覧の行ごとに表示を変える | 行表示の前のサーバースクリプト | その行のレコードを対象にする |
| サーバーの処理結果を画面へ返す | サーバースクリプトとブラウザの応答処理 | 応答を受けたブラウザが命令を実行する |
| 定期的に処理を実行する | バックグラウンドサーバースクリプト | スケジュールに従ってサーバーで実行する |
画面表示のために値を変えた場合と、保存するために値を変えた場合は、確認方法も分けます。画面への応答だけで DB 保存まで確認したことにはなりません。
次に読むページ
- 送信前にタイトルを整えて画面と送信値を揃える — 検証前イベントと送信バッファの更新。
- 保存前にタイトルを正規化する — 保存前に
modelの変更を反映する条件。 - スクリプトの課題別と話題別案内とサーバースクリプトの課題別と話題別案内 — 必要な機能を詳しく読む。
- 動かない・値が反映されないときの調べ方 — どの段階で止まったかを調べる。