動かない・値が反映されないときの調べ方
「動かない」を、コードが出力されない、呼ばれない、値が送られない、保存されない、応答で上書きされる、という段階に分けて調べます。画面の表示だけで、実行と保存の両方が成功したとは判断できません。
全体の流れは スクリプトとサーバースクリプトの全体像を参照してください。
最初に揃える情報
- プリザンターのバージョン。
- テーブルの種類と、対象項目の物理名。
- 操作。画面を開く、新規作成する、更新する、項目を変更する、一覧を絞り込む、など。
- ブラウザ側の出力先・イベント、またはサーバー側の実行条件。
- 操作するユーザーの項目の読み取り・編集権限。
- 期待する値と、実際に確認できた値の場所。
再現に使うレコードは検証用にし、ログやコンソールへ出す値も確認に必要な項目だけに絞ります。
症状から確認先を選ぶ
| 症状 | まず確認すること | 詳細 |
|---|---|---|
| ブラウザのログが出ない | コードが出力されているか、イベントが呼ばれる操作か | 送信前の実装例 |
| イベントの一部の処理だけ動く | 同じイベントへの代入で上書きしていないか | 複数処理の登録 |
| 項目を取得できない | 項目名の解決結果と DOM 要素の有無 | get・set 系関数 |
| 画面は変わるが送信値が変わらない | DOM だけを変更していないか | 送信バッファ |
| 数値の取得結果が入力と違う | data-raw が優先される経路か | getValue の仕様 |
| サーバーで値が見えない | 対象レコードと読み取り権限 | model |
| サーバーで代入したのに保存されない | 編集権限と、その後に保存処理があるか | model の反映条件 |
| 保存後や項目変更後に値が戻る | 応答での値設定・フィールド差し替え、再描画イベント | 自動ポストバック |
| 実行元の判定で処理から外れる | Condition と Action を混同していないか | context |
| 一定時間で処理が止まる | 結合後に適用されるタイムアウト | タイムアウト |
1. 出力と呼び出しを確認する
ブラウザの開発者ツールでスクリプト本文を検索し、対象画面にコードがあるか確認します。出力されていなければ、出力先、個別の無効設定、すべて無効化、下書き出力を見ます。本文があるのにログが出なければ、コンソールのエラーとイベントの呼び出し元を確認します。
本体は出力先と無効・下書き条件でコードを選びます（GetScriptBody()、全体の無効化と出力判定）。
イベントは、すべての画面更新で必ず呼ばれるとは限りません。例えば一覧の初回読み込みとフィルター変更は区別します。イベントの実行タイミングで調べ方を確認してください。
サーバー側は context.Condition と context.Actionを確認します。「画面表示の前」は更新後の再描画にも使われる経路があります。操作別の実行順で、再現操作がどの条件を通るかを追います。
2. DOM と送信バッファを別々に見る
タイトルの通常のテキスト入力欄がある編集画面で、次のコードをコンソールから実行します。値を変更せず、ブラウザ側の状態を確認します。
(function () {
const $control = $p.getControl('Title');
if (!$control || $control.length !== 1 || !$control.is('input[type="text"]')) {
console.warn('タイトルの入力欄が見つかりません。');
return;
}
const controlId = $control.attr('id');
const formId = $control.closest('form').attr('id');
const data = $p.data[formId];
console.log('コントロール ID', controlId);
console.log('フォーム ID', formId);
console.log('DOM の値', $control.val());
console.log('data-raw', $control.attr('data-raw'));
console.log('送信バッファの値', data ? data[controlId] : undefined);
})();送信バッファの値が undefined でも、保存時にその項目が必ず送られないとは限りません。本体はアクションに応じて送信直前にも値を収集します。新規作成と更新では収集対象も異なります（setMustData()）。
$p.getData() は、フォーム ID の設定と未作成のバッファの初期化も行います。この例は $p.data を直接読み、確認のために初期化しない形にしています（getData()）。
3. 実際に送信された値を見る
開発者ツールのネットワーク表示を開いた状態で、問題が起きる操作を再現します。
- 対象のリクエストを選ぶ。
- URL と操作名を確認する。更新と自動ポストバックを区別する。
- 送信データで対象項目の値を見る。
- 応答の内容と、画面へ適用された結果を見る。
本体の送信はフォームごとのバッファを取り出し、操作情報や必須送信値を加えて実行します（send()）。途中のバッファの値だけで判断せず、実際のリクエストを確認します。
4. サーバーの対象と反映条件を見る
model が存在しても、期待するレコードの値が入っているとは限りません。一覧の画面表示前と行表示前では、対象の渡し方が異なります。確認する順序は次のとおりです。
- 実行条件と操作が一致しているか。
- 呼び出し元が対象レコードを渡しているか。
- 項目を読み取る権限があるか。
- 変更する項目がサイト設定にあり、編集可能か。
- 代入後に通常の保存処理へ進む条件か。
対象レコードと権限、保存の条件は model の内部構造と反映条件にまとめています。同じコードを別の実行条件へ移すだけで、保存結果まで同じになるとは判断できません。
5. 保存と画面への応答を分けて確認する
保存結果は、処理結果を確認してからレコードを再取得して調べます。画面側のログや代入値だけで保存成功を判断しません。
context.AddResponse() は応答コレクションへ命令を追加する処理です。ブラウザが受け取って実行する命令と、DB 更新は別の処理です（AddResponse()）。
応答では値の設定だけでなく、フィールドの差し替えも起こります。以前の要素を保持していたコードでは、その要素と現在の画面を区別する必要があります。どの命令で DOM と送信バッファを変えるかは 自動ポストバックと画面への応答反映で確認してください。
次に読むページ
- サーバースクリプトの内部構造 — 結合とデバッグ、例外処理。
- タイムアウト — 実行全体への適用。
- 日付の扱い — 保存値と表示時刻の違い。
- httpClient と外部 API 呼び出しの落とし穴 — 外部連携での制約。