Propel Crud Generator Bundle Laravel Package

Getting Started

Reality check first. spyrit/propel-crud-generator-bundle is a Symfony 2.x bundle for the Propel 1.x ORM. It has nothing to do with Laravel, Eloquent, Blade, or Artisan, and it cannot be installed into a Laravel application — its service provider equivalent (Spyrit\PropelCrudGeneratorBundle\SpyritPropelCrudGeneratorBundle) registers against Symfony's DI container and depends on PropelBundle, Twig, and the Symfony console. Treat this as a reference implementation, not a dependency.

The only situations where you "use" it:

1. You inherited a legacy Symfony 2.x app that already runs Propel and you need to scaffold a CRUD screen quickly.
2. You want to borrow its output shape to build an equivalent php artisan make:crud command for Laravel.

If case 1 applies, minimal steps are:

• composer require spyrit/propel-crud-generator-bundle in the Symfony project (note: the package is unmaintained; pin PHP to whatever the Symfony 2.x requirement allows, realistically 5.3–5.6).
• Register the bundle in app/AppKernel.php and ensure PropelBundle is registered and configured.
• Point Propel at your schema.xml and run php app/console propel:build so the model classes exist.
• Run the bundle's generator command (check Command/ in the bundle for the exact name — READMEs from this era are unreliable).

Where to look first: the bundle's Command/ directory and Resources/skeleton/ templates. That is the entire package. Everything it does is "read the Propel table metadata, render these skeleton files into your bundle/app directory."

First use case for a Laravel dev: scaffold one CRUD for a simple table (say posts) in a throwaway Symfony 2/Propel sandbox, then read the four generated artifacts (controller, routing, Twig views, FormType) side by side with what php artisan make:model -mcr plus a resource controller would give you. That comparison is the actual value.

Implementation Patterns

Scaffold-once, then hand-edit. The generator emits a starting point, not a maintained artifact. Commit your tree, run the generator, review the diff, then own the code. Never re-run the generator over files you've edited — treat its output like artisan make:* output that you immediately customize.

Map the generated artifacts to Laravel idioms. This is the pattern that makes the package useful to a Laravel developer at all:

Build a port, not an integration. If you want the productivity win in a Laravel app, the pattern is: write a custom Artisan command (php artisan make:crud {model}) that reads a migration or a JSON schema, then stubs the controller, FormRequest, routes, and Blade views from stubs/ in exactly the same shape this bundle produces. Laravel's Illuminate\Console\GeneratorCommand and stubs/ directory is the direct analogue of the bundle's Command/ + Resources/skeleton/ split.

Generate-then-layer workflow. In the legacy Symfony app, the pattern that works is: generate CRUD, then immediately add authorization checks, CSRF, and validation (the skeleton rarely has more than basic field listing). In Laravel terms this is the difference between make:controller output and a controller you'd actually ship — same gap.

Data-layer integration is the only sane bridge. If a Laravel app genuinely must share data with a Propel-based system, share the database and re-declare the schema as Eloquent migrations/models. Do not attempt to run Propel or this bundle inside Laravel, and do not try to invoke the Symfony command from Artisan.

Use it as a spec for your own generator. The cleanest workflow: dump one generated CRUD, annotate each file with the Laravel equivalent, and treat that annotated bundle as the requirements doc for your make:crud command. The bundle is small enough (a command plus templates) that reading it takes under an hour.

Gotchas and Tips

• Framework mismatch is fatal, not fixable. There is no service provider, no facade, no config file Laravel will read. Any attempt to composer require it into a Laravel project will at best fail autoload and at worst pull in Symfony 2 components that conflict with modern Laravel's Symfony 6/7 dependencies.
• EOL stack. Symfony 2 and Propel 1 are long unsupported. The PHP constraint alone will block installation on PHP 8. Treat every line of generated code as needing a security review before it touches production.
• Abandonment risk. 2 stars and 0 dependents means no issue tracker activity, no compatibility patches, no security fixes. If you depend on it in a legacy app, vendor/fork it into your repo so your build doesn't break when Packagist or GitHub changes.
• Schema is the source of truth. The generator reads Propel schema.xml. Wrong column types or missing foreign keys produce broken forms and controllers rather than errors — validate the schema (and run propel:build cleanly) before generating.
• Generator overwrites or clobbers. Run it on a clean git tree and inspect the diff. In the legacy Symfony app, generate into a fresh bundle or a scratch directory first, then copy files into place deliberately.
• Configuration is implicit. The bundle relies on PropelBundle being registered and Propel's runtime config being loaded before the command runs. If the generator errors out immediately, check AppKernel.php registration order and config.yml Propel settings before touching the bundle itself.
• Debugging is trivial once you realize there's no magic. Every emitted file comes from a template in Resources/skeleton/. When output is wrong, open the corresponding skeleton and read it. If you've forked the bundle, editing the skeleton is the intended extension point.
• Extension points are limited to templates and command subclassing. There's no event system or hook layer worth relying on. For anything beyond cosmetic changes, fork.
• Don't copy the generated CRUD verbatim into Laravel. The output has no authz, no policies, no CSRF handling in the Laravel sense, and no request validation beyond basic presence checks. Use it as a checklist, then write idiomatic Laravel (FormRequest, $this->authorize(), Route::resource()).
• For Laravel work, reach for the native tools instead. php artisan make:model -mcr, resource controllers, FormRequest, and a stubs/-driven custom command give you the same "schema → CRUD" leverage with a maintained stack. If you want batteries-included CRUD, filament/filament or backpack/backpack are the modern successors to what this bundle attempted in 2012.