Weave Code
Form Handler Bundle Laravel Package
hostnet/form-handler-bundle
Symfony bundle that adds reusable form handler services to separate form processing from controllers. Define handlers for validation, persistence, and success/failure flow, keeping controller actions thin and form logic testable.
Hostnet form handler to provide an easier way of handling forms in actions
Frequently asked questions about Form Handler Bundle
- Is hostnet/form-handler-bundle a Laravel package?
- No. It is a Symfony bundle that registers through bundles.php and depends on Symfony's DI container and HttpKernel lifecycle. For a Laravel-only codebase, architecture fit is poor because Laravel already provides FormRequest, validation, route-model binding, and container-injected DTOs.
- Can I install hostnet/form-handler-bundle in Laravel with Composer?
- Not usefully. Composer may resolve Symfony components because Laravel already pulls some of them, but the bundle's extension points are Symfony-specific and inert under Laravel's request lifecycle. Do not bridge Symfony HttpKernel into Laravel's router; port the pattern instead.
- What problem does hostnet/form-handler-bundle solve?
- It moves Symfony form submission logic out of controllers into dedicated handler services. The bundle wires each form to its handler, runs validation, and routes the result to success or failure logic. That keeps controllers thin and makes submission logic reusable and unit-testable.
- How do I install and configure hostnet/form-handler-bundle in a Symfony app?
- Install it with Composer, enable the bundle in bundles.php, and define a handler service for each form. The bundle uses Symfony DI autoconfiguration to wire handlers, so verify the required interface or tag in the package docs and composer.json. Check supported PHP and Symfony versions before pinning it.
- Which Laravel versions support hostnet/form-handler-bundle?
- None officially. This is a Symfony bundle, not a Laravel package, so Laravel 11 or 12 support is not a meaningful compatibility question. Laravel ships some Symfony components but not the bundle system this package relies on.
- What are the best Laravel alternatives to this form handler pattern?
- Use a FormRequest subclass that validates input and returns a typed DTO, or adopt spatie/laravel-data for richer DTO hydration. Action classes and route-model binding can keep controllers thin without a Symfony-style resolver. Compare these on your two most complex forms before standardizing.
- Does hostnet/form-handler-bundle handle validation and 422 responses?
- It integrates with Symfony Form validation and routes validation results into success or failure flow. The exact 422 response behavior depends on your Symfony form and controller configuration, not on Laravel's validation exception handling. Treat hydration as separate from validation and use explicit form constraints plus allowlists for user input.
- How do I unit test form handlers built with this bundle?
- Handlers are services, so you can instantiate them in tests without booting the Symfony framework. Mock dependencies, pass representative form data and validation results, and assert the success or failure outcome. Add a small integration test for DI wiring if you adopt it.
- What maintenance and production risks should I check before adopting it?
- Ecosystem signal is weak: roughly 71 stars, 0 dependents, and a single-maintainer or agency profile, so assume you may become the maintainer. Risks include abandonment, undocumented coupling to Symfony Forms versions, and mass-assignment-shaped hazards when hydrating typed objects from user input. The MIT license helps because you can fork and vendor it, but pin PHP and Symfony versions and add CI before production use.
- Should I use hostnet/form-handler-bundle in a mixed Symfony and Laravel estate?
- Scope any evaluation to the Symfony application only. Do not attempt to bridge the bundle into Laravel's router or request lifecycle; the adapter cost will exceed the package value. For Laravel, reproduce the pattern with FormRequest returning a DTO or spatie/laravel-data, and only vendor an internal fork if a Symfony service genuinely needs it.
Weaver
How can I help you explore Laravel packages today?