FormCatalog

Corex\Forms\Catalog\FormCatalog · class · Forms layer

Every form CoreX knows about, from every source, in one list. Before this existed each screen derived its own list from the flow table alone, so a form registered in code through {@see FormRegistry} — the documented way to declare one — was invisible unless the site added a corex_submission_filter_options hook of its own. Discovery is the framework’s job, not the site’s. WordPress-free by construction: flows and code forms are already pure domain objects, and the two things that genuinely need the database (submission counts, third-party entries) arrive through injected seams. That keeps the merge — which is where the interesting rules live — unit-testable.

Public API

__construct(FlowRepository $flows, FormRegistry $forms, ?SubmissionCounts $counts)

registerProvider(FormCatalogProvider $provider): void

all(): array

The catalog: one entry per slug, richest source winning, sorted by label.

shadowed(): array

The entries a higher-precedence source displaced. Kept rather than discarded because a slug collision is usually a mistake somebody wants to find out about, and diagnostics is the honest place to say so — not a duplicate row.

find(string $slug): ?FormCatalogEntry