blocs/admin: 新規作成・編集機能のカスタマイズ

blocs/admin: 新規作成・編集機能のカスタマイズ

自動生成された管理画面の新規作成・編集機能をカスタマイズする方法を説明します。入力フォーム、バリデーション、確認画面、競合検出などを要件に合わせて調整できます。

前提条件: 自動生成ツールで管理画面を生成済みであること

テンプレートの一覧

共通テンプレートは resources/views/admin/base/entry に格納されています。

処理フロー

初期状態では モーダル で登録・更新を確認します（詳しくは No.1.2 / No.5.4）。confirmStore / confirmUpdate ルートおよび確認画面テンプレートは自動生成に含まれません。専用確認画面を使う場合のみ、以下の「パターンB」のフローになります。

★ はオーバーライドによるカスタマイズポイントです。

新規作成フロー

パターンA: モーダル確認（デフォルト）

flowchart TD
    subgraph create["create — 入力画面表示"]
        direction TB
        c1["prepareCreate ★ — 表示データ準備"]
        c2["outputCreate — 入力画面表示"]
        c1 --> c2
    end
    modal["（モーダルで確認）"]
    subgraph store["store — 新設処理"]
        direction TB
        s1["validateStore ★ — 入力データの検証"]
        s2["prepareStore ★ — 登録データ準備"]
        s3["executeStore ★ — データ登録"]
        s4["logStore ★ — ログ記録"]
        s5["outputStore — 完了処理"]
        s1 --> s2 --> s3 --> s4 --> s5
    end

    c1 --> c2
    c2 --> modal
    modal --> s1

パターンB: 専用確認画面（任意・追加時）

flowchart TD
    subgraph create["create — 入力画面表示"]
        direction TB
        c1["prepareCreate ★ — 表示データ準備"]
        c2["outputCreate — 入力画面表示"]
        c1 --> c2
    end
    subgraph confirm["confirmStore — 確認画面表示"]
        direction TB
        cf1["validateStore ★ — 入力データの検証"]
        cf2["prepareConfirmStore ★ — 表示データ準備"]
        cf3["outputConfirmStore — 確認画面表示"]
        cf1 --> cf2 --> cf3
    end
    subgraph store["store — 新設処理"]
        direction TB
        s1["validateStore ★ — 入力データの検証"]
        s2["prepareStore ★ — 登録データ準備"]
        s3["executeStore ★ — データ登録"]
        s4["logStore ★ — ログ記録"]
        s5["outputStore — 完了処理"]
        s1 --> s2 --> s3 --> s4 --> s5
    end

    c2 --> cf1
    cf3 --> s1

編集フロー

パターンA: モーダル確認（デフォルト）

flowchart TD
    subgraph edit["edit — 編集画面表示"]
        direction TB
        e1["getCurrent ★ — 編集データ取得"]
        e2["prepareEdit ★ — 表示データ準備"]
        e3["outputEdit — 入力画面表示"]
        e1 --> e2 --> e3
    end
    modal["（モーダルで確認）"]
    subgraph update["update — 更新処理"]
        direction TB
        u1["getCurrent ★ — 編集データ取得"]
        u2["validateUpdate ★ — 入力データの検証"]
        u3["checkConflict ★ — 衝突確認"]
        u4["prepareUpdate ★ — 登録データ準備"]
        u5["executeUpdate ★ — データ登録"]
        u6["logUpdate ★ — ログ記録"]
        u7["outputUpdate — 完了処理"]
        u1 --> u2 --> u3 --> u4 --> u5 --> u6 --> u7
    end

    e1 --> e2
    e3 --> modal
    modal --> u1

パターンB: 専用確認画面（任意・追加時）

flowchart TD
    subgraph edit["edit — 編集画面表示"]
        direction TB
        e1["getCurrent ★ — 編集データ取得"]
        e2["prepareEdit ★ — 表示データ準備"]
        e3["outputEdit — 入力画面表示"]
        e1 --> e2 --> e3
    end
    subgraph confirm["confirmUpdate — 確認画面表示"]
        direction TB
        c1["getCurrent ★ — 編集データ取得"]
        c2["validateUpdate ★ — 入力データの検証"]
        c3["prepareConfirmUpdate ★ — 表示データ準備"]
        c4["outputConfirmUpdate — 確認画面表示"]
        c1 --> c2 --> c3 --> c4
    end
    subgraph update["update — 更新処理"]
        direction TB
        u1["getCurrent ★ — 編集データ取得"]
        u2["validateUpdate ★ — 入力データの検証"]
        u3["checkConflict ★ — 衝突確認"]
        u4["prepareUpdate ★ — 登録データ準備"]
        u5["executeUpdate ★ — データ登録"]
        u6["logUpdate ★ — ログ記録"]
        u7["outputUpdate — 完了処理"]
        u1 --> u2 --> u3 --> u4 --> u5 --> u6 --> u7
    end

    e3 --> c1
    c4 --> u1

ベースコントローラーのメソッド

新規作成関連

編集関連

ベースコントローラーの主な変数

メソッドの共有関係

ベースコントローラー内部では、以下のメソッド呼び出し関係があります。

• prepareEdit() は内部で prepareCreate() を呼び出します。prepareCreate() をオーバーライドすると、新規作成画面だけでなく編集画面にも影響します。
• prepareUpdate() は内部で prepareStore() を呼び出します。prepareStore() をオーバーライドすると、新規登録処理だけでなく更新処理にも影響します。

編集画面や更新処理だけに固有のロジックを追加したい場合は、prepareEdit() / prepareUpdate() をオーバーライドし、parent::prepareEdit() / parent::prepareUpdate() を呼び出した後に追加処理を記述してください。

ログデータの自動生成

executeStore() および executeUpdate() は、処理の中で自動的に $this->logData を構築します。ログ記録のために手動で $this->logData を設定する必要はありません。

確認画面のセッションデータについて

専用確認画面（confirmStore / confirmUpdate / confirmDestroy / confirmSelect）では、確認画面表示時にリクエストデータを Laravel のフラッシュセッションへ保存し、確定処理（store / update / destroy / select）で復元します。

セッションキー

キーは {viewPrefix}.confirm です（例: admin.user.confirm）。登録・更新・削除・一括削除で同一キーを共有します（No.4.3 参照）。別種別の確認画面を同時に使う設計には注意してください。

フラッシュの有効期限

フラッシュデータは次の1リクエストでのみ有効です。確認画面表示後に別ページへ遷移してから戻ると、入力データは失われます。

確定処理時のバリデーション

専用確認画面経由で確定 POST された場合、セッションに確認データがあれば validateStore() / validateUpdate() 等はスキップされ、セッション内容を $request にマージして処理します（確認画面表示時に既に検証済みのため）。モーダル確認からの直接 POST では、従来どおり validate*() が実行されます。

編集時に現在のデータを取得する方法

コントローラー内で $this->getCurrent($id) を使用します。取得したデータはフォームの初期値表示や編集前の確認に利用できます。

編集の競合確認を有効にする方法

複数ユーザーによる同時編集の競合を検出するには、テンプレート内で updated_at の値を hidden フィールドとして送信します。

<input type="hidden" name="updated_at" />

checkConflict() はリクエストに updated_at が含まれている場合のみ動作します。hidden フィールドがなければ競合チェックはスキップされます。競合が検出された場合、編集画面にエラーメッセージ付きでリダイレクトされます。

確認画面の追加方法

管理画面の初期状態では モーダル による確認が行われます（詳しくは No.5.4 を参照）。専用の確認画面を追加するには以下の手順で実装します。

1. 確認画面用テンプレートの作成

resources/views/... 配下に confirmStore.blocs.html を作成し、入力内容の表示や「登録」ボタンを配置します。

2. 確認画面を表示するルートの定義

confirmStore / confirmUpdate は POST でリクエストを受け取ります。

Route::post('/confirmStore', [UserController::class, 'confirmStore'])->name('confirmStore');
Route::post('/{id}/confirmUpdate', [UserController::class, 'confirmUpdate'])->where('id', '[0-9]+')->name('confirmUpdate');

3. 新規作成画面から確認画面へ遷移するボタンを設置

<!-- data-bloc="buttonBottomCenter" -->
<!-- :formaction=route(prefix().".confirmStore") -->
<!--
    data-include="button"
    $buttonType="submit"
    $buttonClass="btn btn-primary"
    $buttonIcon="fa-solid fa-arrow-right"
    $buttonLabel="確認"
-->
<!-- data-endbloc -->

注: confirmStore / confirmUpdate ルートおよび確認画面テンプレートも、自動生成には含まれません。モーダル確認から専用確認画面へ切り替える場合に追加してください。