Filament SDK Integration

When using Tagixo in Filament-based admin panels, follow the SDK adapter pattern.

Core principle

• Core builder logic remains in Tagixo.
• Filament package provides panel/resource wiring.

That separation is what keeps your content portable across hosts.

Integration model

In a Filament adapter, the responsibilities should mirror Primix:

• host page lifecycle comes from Filament
• content persistence stays in your app
• Tagixo still owns bootstrap, rendering, module registry, PropTypes, and preview behavior

Typical plugin registration pattern

use Ccast\TagixoFilament\TagixoFilamentPlugin;

$panel->plugins([
    TagixoFilamentPlugin::make(),
]);

Asset publication

The ccast/tagixo core package ships its own pre-built dist/ directory. Consumer apps copy it into public/ via:

php artisan vendor:publish --tag=tagixo-assets --force

The Filament SDK Blade layout (tagixo-filament::layout) references the bundle with asset('vendor/tagixo/builder.js') — no @vite(), no manifest lookup, no Vite/npm toolchain in your app. Re-run with --force after every Tagixo upgrade.

The SDK uses Livewire as reactivity layer (not LiVue — that's the Primix path). Module render events and notifications flow through Livewire's dispatch() and Filament\Notifications.

Bridge trait pattern

Tagixo integration is split across two traits to keep content portable:

• Ccast\Tagixo\Concerns\InteractsWithVisualBuilder — framework-agnostic core (mount, load, save, structure dispatch). Ships in ccast/tagixo. Do not modify.
• Ccast\TagixoFilament\Concerns\InteractsWithVisualBuilderFilament — Filament-side bridge: implements 4 abstract methods (notifySuccess, notifyError, dispatchBuilderEvent, skipBuilderRender) plus #[On] Livewire handlers that bridge the builder Vue → Livewire boundary.

The BuilderPage abstract class shipped by the SDK already uses both traits. Extending it gives you the right wiring without re-applying the trait pair yourself. Switching to Primix means swapping the bridge trait (InteractsWithVisualBuilderPrimix), not rewriting your page class.

You can scaffold a starter page with:

php artisan make:builder-page MyResource/Pages/EditMyResourceBuilder --context=page --panel=Admin

Typical page classes

Filament adapter workflows usually expose:

• standalone builder pages
• resource-bound builder pages

Both should implement the same persistence contract:

• load structure JSON
• save structure JSON
• pass context explicitly

What should stay stable across SDKs

Whether you use Primix, Filament, or a custom host:

• stored JSON shape should remain the same
• render endpoints should remain the same
• context and layout variant semantics should remain the same
• module and PropType registration should remain the same

That is the real value of the core-first architecture.

Recommended implementation rules

1. Keep entity persistence in your app models/repositories.
2. Do not fork core render logic into Filament pages.
3. Use core bootstrap API payload as source of truth.
4. Enforce access control at resource/page layer.
5. Keep preview routing explicit and test it under real auth/session conditions.

Migration strategy from Primix to Filament (or vice versa)

Because Tagixo is core-first:

• your stored JSON structure remains reusable
• your render artifacts stay compatible
• only panel adapter code changes

Reminder

The exact Filament adapter API can evolve across releases. Before implementing against it:

• check the installed package version in your lock file
• read the adapter README shipped with that version
• verify available page/resource abstractions before scaffolding your own classes

If an official adapter is not available in your current stack, build your Filament host around the same contracts described in the standalone and Primix pages.