Day 10：表格裡顯示關聯資料，一眼看出這張訂單屬於哪個客戶 結尾留下一句話，翻開一張訂單的編輯頁或檢視頁，現在知道這張訂單屬於哪個客戶，可是這張訂單實際包含哪些商品、各買了多少數量，還是完全看不出來。這句話其實還連著更早一筆帳，Day 09：表單裡選關聯資料，下拉選單背後在做什麼 當時就點出訂單表單只能選一個商品欄位，這在業務常理上並不合理。

今天要處理的正是這兩件事，一次還清。

一張訂單，到底買了什麼

回頭看 Day 01：為什麼是 Filament，跟手刻後台與其他套件比起來差在哪 定案的業務語意，這間批發商的訂單量不算巨大但頻率高，一家寵物用品店一次叫貨，通常同時訂購飼料、玩具、清潔用品這類多個品項，不會只叫一種東西。但目前訂單表單裡的 product_id，一張訂單只能對應到一個商品，這個限制從 Day 9 就被誠實點名，當時的理由是任務範圍刻意先聚焦在單一關聯欄位的選擇機制，這種巢狀關聯情境留到後面處理。

現在正是清償這筆債務的時候。今天要引入訂單明細這個新的資料概念，一張訂單底下可以有多筆明細，每筆明細對應一個商品，並各自記錄買了多少數量。這件事處理完之後，訂單表單裡原本那個只能選一個商品的 product_id 欄位就會被移除，改由一個獨立的介面來管理這些明細，這個獨立介面的名字，也是今天要正式定案的系列錨點，Relation Manager。

訂單跟商品之間，多了一層資料

訂單明細是本篇新增的模組，欄位設計同樣保持精簡，只服務今天的示範需求，不做成含單筆折扣、稅額這類完整明細規格會有的欄位。

在這邊的範例來說，三個欄位就已經足夠：

• order_id，所屬訂單，這筆明細屬於哪一張訂單。
• product_id，所屬商品，這筆明細對應到哪一個商品。
• quantity，數量，這筆明細訂購了多少件。

先確認 Model 跟 Migration，這個節奏相信大家已經很熟悉：

php artisan make:model OrderItem -m

Schema::create('order_items', function (Blueprint $table) {
    $table->id();
    $table->foreignId('order_id')->constrained();
    $table->foreignId('product_id')->constrained();
    $table->unsignedInteger('quantity')->default(1);
    $table->timestamps();
});

關聯定義也是熟悉的 belongsTo、hasMany：

// OrderItem.php
public function order(): BelongsTo
{
    return $this->belongsTo(Order::class);
}

public function product(): BelongsTo
{
    return $this->belongsTo(Product::class);
}

// Order.php
public function items(): HasMany
{
    return $this->hasMany(OrderItem::class);
}

不過這邊值得停下來看一眼這個關聯結構的位置。訂單明細本身是一張獨立的資料表，同時關聯著訂單與商品兩端，一筆訂單對應多筆訂單明細，一筆訂單明細對應一個商品。這跟 Day 9 處理過的「訂單直接關聯一個客戶」性質完全不同，客戶那條關聯是單純的一對一指向，訂單選了誰就是誰。訂單明細要處理的，是「在同一張訂單底下，同時存在多筆各自獨立的從屬資料」，這是一種新的關聯型態，讀者過去八天沒有正式遇過。

也正因為這個性質不同，讀者可能直覺想到，這不就是一對多關聯，能不能延用 Day 9 學過的關聯欄位處理。答案是不行，關聯欄位適合的情境是「這筆資料選擇另一筆已存在資料」，選一個客戶、選一個商品，都是單一指向。訂單明細需要的是「在同一個畫面裡，同時新增、編輯、刪除多筆從屬於這張訂單的獨立資料列」，這已經超出一個欄位能承載的範圍，需要一個獨立的管理介面才處理得動。這種介面型態，讀者如果曾在電商後台看過訂單編輯頁下方多出一塊可以新增商品明細列的區域，這裡要示範的正是類似的東西。

Relation Manager，一個獨立的子介面

今天正式定案這個系列既定錨點：Relation Manager，是在 Resource 檢視或編輯頁面內，管理該筆資料與關聯資料表之間關係的獨立子介面。此後全系列提到這類介面，一律沿用這個詞，不再另創同義詞。

拆解定義裡的兩個關鍵詞。「檢視或編輯頁面內」指出這個介面不是獨立存在的頁面，不會出現在側邊選單裡自成一個項目，而是掛載在某一筆已存在資料的檢視或編輯頁面裡面，訂單明細的 Relation Manager 只會出現在打開某一張具體訂單之後。「獨立子介面」指出這個區塊有自己的一套列表、新增、編輯、刪除操作，不受外層訂單表單本身的送出流程影響。

這一點呼應 Day 08：Action 是什麼，表格列、頁首、表單內三種掛載位置 定案 Action 時談過的表單內操作，兩者性質類似，都是不透過外層表單一次性提交的獨立操作單元。表單內操作是掛在表單裡的一顆按鈕，點下去獨立執行、獨立完成；Relation Manager 則是掛在頁面裡的一整塊區域，裡面自己有完整的增刪查改邏輯，規模比單顆按鈕大得多，但「不跟著外層表單一起送出」這個特性是共通的。

Relation Manager 解決的核心問題，正是上一段點出的困境。一對多且需要同時管理多筆從屬資料的關聯情境，用一個表單欄位裝不下，但也不必為了訂單明細另外開一個獨立的 Resource，讓使用者跳出訂單畫面、跑到另一個頁面去新增明細再回頭核對是哪一張訂單。Relation Manager 讓這些從屬資料在自己所屬的那筆訂單的檢視或編輯頁面裡，就能直接被管理，不需要離開當下正在看的這張訂單。

在訂單編輯頁裡管理明細

動手之前，先移除訂單表單裡那個已經完成任務的舊欄位。

Day 9 留下的 Select::make('product_id') 這個關聯欄位，今天正式從訂單表單裡拿掉，一張訂單不再只能對應一個商品，這件事改由接下來要掛載的 Relation Manager 負責。

生成訂單明細的 Relation Manager：

php artisan make:filament-relation-manager OrderResource items product_id

指令裡的 items 對應剛才在 Order.php 定義的 items() 關聯方法，product_id 是這個 Relation Manager 底下的表單要顯示的標題欄位，指令跑完會產生一個獨立的 OrderItemsRelationManager 類別，接著把表單跟表格內容補上：

use Filament\Schemas\Schema;
use Filament\Forms\Components\Select;
use Filament\Forms\Components\TextInput;
use Filament\Tables\Columns\TextColumn;
use Filament\Tables\Actions\CreateAction;
use Filament\Tables\Actions\EditAction;
use Filament\Tables\Actions\DeleteAction;

public function form(Schema $schema): Schema
{
    return $schema->components([
        Select::make('product_id')
            ->label('商品')
            ->relationship('product', 'name')
            ->searchable()
            ->required(),

        TextInput::make('quantity')
            ->label('數量')
            ->numeric()
            ->minValue(1)
            ->default(1)
            ->required(),
    ]);
}

public function table(Table $table): Table
{
    return $table
        ->recordTitleAttribute('product_id')
        ->columns([
            TextColumn::make('product.name')
                ->label('商品名稱'),

            TextColumn::make('quantity')
                ->label('數量'),
        ])
        ->headerActions([
            CreateAction::make(),
        ])
        ->actions([
            EditAction::make(),
            DeleteAction::make(),
        ]);
}

最後把這個 Relation Manager 註冊到訂單 Resource 上：

// OrderResource.php
public static function getRelations(): array
{
    return [
        RelationManagers\OrderItemsRelationManager::class,
    ];
}

打開任何一張訂單的編輯頁面，訂單自身的欄位下方，現在會多出一個獨立區塊，標題是商品明細，呈現這張訂單目前已有的明細列表。點擊區塊右上角的新增按鈕，跳出的表單就是剛才寫的那份，選擇商品、填入數量，送出之後這筆明細立刻出現在列表裡，整個過程不需要等到訂單本身的表單被送出才會儲存，這正是前一段強調的「獨立子介面」特性，新增明細跟訂單自身欄位有沒有被修改、有沒有存檔，是兩件互不干擾的事。

既有的明細列一樣能直接編輯或刪除，點列表上的編輯圖示，跳出同一份表單，把數量從三改成五，存檔，這筆明細的數量就更新了。整個過程使用者始終停留在同一張訂單的編輯頁面，不需要跳到別的頁面再繞回來確認自己改的是哪張訂單底下的哪筆明細。

這裡有個細節值得點出來，訂單明細裡選擇商品的那個欄位，寫法跟 Day 9 拆解過的關聯欄位機制一模一樣，relationship('product', 'name')，查的是商品資料表，顯示的是商品名稱，存進去的是商品主鍵。差別只在於這次它掛載在 Relation Manager 內部的表單，而不是訂單自身的表單。同一套關聯欄位機制，換了一層掛載位置，照樣可以直接複用，不需要為了「這次是巢狀關聯裡的表單」重新學一套選擇商品的邏輯。

訂單完整了，但系統還沒有連成一片

今天做完這一輪調整，訂單明細正式登場，Relation Manager 這個系列錨點也定案了。訂單編輯頁現在能直接管理這張訂單底下的商品明細，新增、編輯、刪除都在同一個畫面完成，不需要離開訂單頁面去別的地方操作。Day 9 留下的「訂單只能關聯一個商品」的限制，到今天正式解決，一張訂單底下可以自由記錄多個品項，各自的數量也各自獨立管理。

但這裡要誠實點出目前的狀態。客戶、訂單、訂單明細、商品之間的關聯，技術上都已經打通，訂單知道自己屬於哪個客戶，也知道自己底下有哪些明細，明細知道自己對應哪個商品。可是這幾個 Resource 目前還是分別各自打開才看得到彼此的關聯，商品 Resource 打開只看到商品自己的欄位，客戶 Resource 打開也只看到客戶自己的欄位，還沒有一個地方能讓人一次感受到這整套後台是串在一起運作的系統。

把商品、訂單、客戶串起來，第一次像個真正的系統，是接下來要處理的內容。