Tomato Resource Laravel Package

Product Decisions This Supports

• Admin/back-office build-vs-buy. tomato-resource is the resource-definition layer of the TomatoPHP admin stack: one class per Eloquent model declares columns, form fields, filters, relationships, and actions, and a generator emits the migration, model, and CRUD wiring from that definition. The decision it informs is whether to standardize internal admin screens on Tomato Admin versus hand-rolling Laravel controllers/policies or buying into a mainstream admin framework (Filament, Nova, Backpack). It is only a real option if Tomato Admin is already (or is about to be) the panel of record.
• Roadmap sequencing. If the team is on Tomato Admin, this package is a prerequisite, not a feature: any roadmap item that ships an internal CRUD screen depends on it. That makes it an unblocking dependency to schedule early, not a standalone bet to debate. If the team is not on Tomato, it is a watch item and should not appear on the roadmap at all.
• Platform standardization. The strongest genuine product argument: adopting "one resource class per model" as a shared internal convention gives a single source of truth for schema, validation, and admin behavior, and reduces per-project reinvention of CRUD. This is a convention decision as much as a tooling decision, and it outlives the package.
• Scoping the use case. Fit is internal, back-office, low-design-stakes CRUD against a Laravel/Tomato codebase — reference data, support tooling, ops consoles. It is explicitly not a decision about customer-facing UI, public APIs, or general-purpose CRUD.
• Pilot go/no-go with a named fallback. The correct framing is a time-boxed pilot on one real resource with a pre-agreed alternative (plain Laravel controllers, or Filament/Nova). The countervailing signals are material: 1 star, 0 dependents, a single v1.0.0 tag dated 2023-10-04 with no release since, and release notes consisting of a changelog link. That reads as a narrow, ecosystem-coupled tool with a thin adoption base — not a safe default.
• Engineering estimation and staffing. Because the value is generated artifacts rather than runtime magic, effort estimates for admin screens shift from "one controller + views + policy per model" to "one resource definition + review per model." That changes sprint sizing and makes admin backlog predictable — which is the number a PM can actually put in a plan.

When to Consider This Package

Consider it when:

• You are already committed to Tomato Admin / TomatoPHP and need its resource layer. The package is not standalone — installed without tomato-admin, tomato-crud, and tomato-forms it yields a config file and a base class, and generated resources are consumed by those packages rather than rendering screens themselves.
• You have a backlog of repetitive internal CRUD (index/create/edit, filters, relationships, actions) and want a declarative single-file definition per model plus a generator that emits migration, model, and CRUD wiring.
• You value consistency and reduced per-screen hand-coding over UI polish. The field-schema → artifact pipeline is the product; the admin chrome comes from the parent panel.
• You can contain the coupling: generated files reviewed by hand and committed to version control, customizations kept in a subclassed base resource (not inline in generated files), and the generator run locally — never in CI or at deploy time.

Look elsewhere when:

• Your stack is not Laravel + Tomato. Portability is near zero; the abstraction assumes Tomato Admin's CRUD and form packages.
• You need a mature admin framework with broad documentation, an available hiring pool, and long support history. Filament or Nova are the honest comparisons, and this package does not compete on those axes.
• You need maintainer-continuity guarantees. One 1.0 tag from 2023, one star, zero dependents is a real continuity risk for anything business-critical or long-lived.
• Your CRUD surface is small. A handful of Laravel controllers plus policies — or a mature framework you already license — is cheaper than adopting an ecosystem and its drift.
• The screens are customer-facing or design-sensitive. Generated CRUD is functional, not styled beyond Tomato Admin defaults.

Adoption gates to clear before committing: verified compatibility with your Laravel/PHP/database versions (read composer.json — there is no documented support matrix); reviewed service providers, published migrations, and any tests; confirmation that generation into a populated app/ is non-destructive and that outputs are versioned; a documented exit path (your own base resource class as an interface boundary) so switching cost stays low; and a pinned constraint (1.0.*) rather than an open one. Treat generated migrations as a review artifact — unsupported field types tend to be dropped silently rather than raising an error, so a manual diff against the intended schema after every generation is a required control, not a debugging step.

How to Pitch It (Stakeholders)

For executives: tomato-resource is a component of the TomatoPHP admin ecosystem that turns a declarative resource definition into a working back-office CRUD screen — migration, model, table, form, filters, and routes. The business case is reduced hand-built admin work and a consistent internal pattern, not new customer-facing capability: fewer engineer-hours per internal screen and less divergence between admin pages. The honest caveat is adoption risk — one star, zero dependents, a single 1.0 release in October 2023 and nothing since — so the recommendation is a scoped, time-boxed pilot behind one internal tool with a named fallback, not a platform-wide commitment. Risk is containable because we pin the version, review and commit generated code, and validate on one real resource before expanding. It only makes sense if we are already invested in Tomato Admin; if we are not, the comparison is Filament/Nova or plain Laravel and we should evaluate those instead.

For engineering: the package provides a fluent, class-based resource definition plus a generator pipeline (field schema → migration, model, CRUD wiring) with builders for forms, tables, filters, relationships, and actions, translation files, and a published config controlling field types and generation paths. Integration is Composer plus publishable config, migrations, and lang files — then optimize:clear. It depends on tomato-admin, tomato-crud, and tomato-forms; if the panel doesn't render, the fault is almost always upstream in those, not here. Non-obvious operational rules: the generator owns artifact files, so commit its output and never run it in CI; keep custom logic in a subclassed base resource or trait because regeneration overwrites inline edits; watch for model/controller name collisions derived from table names before generating into a populated app/; and clear cache first when a new field doesn't appear in the UI. Authorization and server-side validation assumptions are undocumented — wire policies and validation explicitly at the controller layer rather than trusting generated types. Load-test index pages for eager-loading gaps before any high-traffic admin area depends on them. Treat the base resource class and the published config as the only two sanctioned extension points, and wrap the vendor base class behind our own so a future swap stays cheap.