Frontbundle Maker Laravel Package

Getting Started

Install the package via Composer and publish its assets so the generator templates are available in your app:

composer require <vendor>/<package>
php artisan vendor:publish --tag=<package>-views   # or --provider="<Vendor>\<Package>\<Package>ServiceProvider"

Look first at the published template directory — index.tpl.php is the file that drives the generated index view, and it is the file touched by 1.0.5. Everything else (config, stubs, other actions) is secondary until you understand what that template emits.

First use case: generate (or re-generate) a resource's index page and confirm it renders a DataTable instead of a plain HTML table.

php artisan <package>:generate <Model> --views

Then visit the generated route and check the browser console/network tab — you should see the DataTables library initialising against the table markup emitted by index.tpl.php.

Implementation Patterns

Override, don't edit vendor files. Publish the views and edit the copy under resources/views/vendor/<package>/. In 1.0.5 the shipped index.tpl.php changed to support DataTables; keeping a published override means you control the diff rather than being surprised by it.

Regenerate vs. hand-edit. Two workflows are common:

• Generator-first: keep index.tpl.php as the single source of truth, tweak the template, then re-run the generator for each model. Best when you have many similar resources.
• Scaffold-then-own: generate once, then treat the output as normal application code and stop re-running the generator. Best when each index view diverges (custom filters, computed columns).

Pick one per project; mixing them causes silent overwrites of hand edits.

Server-side vs. client-side DataTables. If the generated table is small, client-side initialisation in the template is fine. For large tables, swap the initialiser for a server-side ajax config pointing at an existing or generated endpoint, and make sure the JSON shape matches DataTables' expected data / recordsTotal / recordsFiltered keys.

Compose the template rather than duplicating it. Extract the table head, row markup and the <script> init block into partials included from index.tpl.php. This keeps the generated output consistent and makes the DataTables upgrade path a one-file change.

Pair generation with a form request / policy. The generated index is a view only; authorisation still belongs in the controller ($this->authorize('viewAny', Model::class)) so the DataTable doesn't leak rows the user can't see.

Gotchas and Tips

• Published templates shadow vendor updates. This is the big one for 1.0.5. If you published index.tpl.php on an earlier version, composer update will not change your copy — the DataTables update is in the vendor file only. Diff vendor against your published version before assuming you have the fix.
• Re-publish deliberately. vendor:publish --force will overwrite your customisations. Diff first, or re-publish to a scratch tag and copy across.
• Asset dependencies are not installed for you. The template emits DataTables markup, not the JS/CSS. Confirm jQuery + DataTables are loaded (CDN or npm/Vite) before debugging "table renders but isn't a DataTable".
• Stale view cache. After changing templates, php artisan view:clear — compiled Blade views can mask template edits, especially in local dev with opcache enabled.
• Column alignment. Adding or removing a <th> in the template without matching the <td> count in the row partial yields misaligned sorting and search. Keep both in one partial so they change together.
• Escaping. Generated PHP/Blade stubs frequently interpolate model attributes directly. Verify the template uses {{ }} (or e()) rather than raw output for user-controlled fields.
• Extension points. Most packages in this shape expose a config array for stub paths and a --force/--stub style flag on the command. Check config/<package>.php before forking the command; the path is usually configurable there.
• Version pin. If you depend on the DataTables-ready markup, pin ^1.0.5 so a template regression in a later patch doesn't silently break your generated views.