Validator Bundle Laravel Package

Getting Started

• Install with Composer, pinning a constraint that matches your Symfony version:

  composer require toa/validator-bundle
  

  Given the package targets Symfony2, expect a constraint like ~2.0 or dev-master and a PHP requirement of 5.3–7.x.

• Register the bundle in app/AppKernel.php:

  public function registerBundles()
  {
      $bundles = array(
          // ...
          new Toa\ValidatorBundle\ToaValidatorBundle(),
      );
  }
  

  Confirm the exact class name and namespace from the package's composer.json (autoload.psr-4 / autoload.psr-0) before assuming Toa\ValidatorBundle — the vendor name in the Composer package (toa) may not match the PHP namespace.

• Where to look first, in order:

  1. README.md — treat as aspirational; this package has zero stars and zero dependents, so nothing here is battle-tested.
  2. DependencyInjection/Configuration.php and DependencyInjection/*Extension.php — this is the authoritative list of config keys under the bundle's root alias.
  3. Resources/config/services.xml (or services.yml) — the authoritative list of service IDs you can actually fetch.
  4. composer.json of both this bundle and toaotc/Validator — version constraints and PHP floor.

• First use case: wire the bundle's validator service into a controller action and validate a simple DTO or entity, then dump the result to confirm the service is registered and behaving as expected:

  $validator = $this->get('toa.validator'); // verify ID via container:debug
  $result = $validator->validate($someDto);
  

  Run php app/console container:debug (Symfony 2.x) and grep for toa to find the real service IDs before writing integration code.

Implementation Patterns

• Service injection over container lookups. Once you identify the service ID, constructor-inject it into your own services and tag them normally. Container fetches ($this->get(...)) work but make the bundle hard to swap later.
• Validate at the boundary. The natural fit is validating command/DTO objects in a service layer or form-handler before persistence, keeping controllers thin. If the upstream validator returns a result object rather than throwing, branch on it explicitly rather than relying on exceptions.
• Run alongside Symfony's Validator, not instead of it. Symfony2's validator service handles constraints/annotations; this bundle is a separate validation engine. Use Symfony's validator for entity/form constraints and this bundle for domain-rule validation, or write a thin adapter that exposes its rules as a Symfony ConstraintValidator.
• Config-driven rules. If the DI extension exposes a configuration tree, define rules under the bundle's root key in app/config/config.yml and let the extension build the validator service. Keep environment-specific rule sets in config_dev.yml / config_prod.yml.
• Testing. Unit-test rule classes directly against the upstream toaotc/Validator API (fast, no kernel). For wiring, use Symfony's KernelTestCase/WebTestCase to boot the kernel and assert the service resolves — this catches DI misconfiguration that unit tests miss.
• Upgrade path. Treat Symfony 2.8 LTS as the realistic target. If you need Symfony 3+, plan to fork: copy the service definitions into your app's services.yml and drop the bundle registration, since auto-wiring and services.yaml defaults won't apply.

Gotchas and Tips

• Symfony2-only assumptions. Older bundles rely on services.xml, explicit public: true services, and the app/console layout. Don't expect PSR-4 autoloading of services, autoconfigure, or Flex recipes.
• Namespace mismatch risk. Composer package name and PHP namespace frequently diverge in small bundles. Verify the bundle class path from composer.json before editing AppKernel.php; a wrong new ... line produces a confusing "class not found" at boot.
• Zero dependents means zero community knowledge. There will be no StackOverflow answers, no issue threads, and no downstream examples. Budget time to read the source rather than searching.
• Check upstream health. toaotc/Validator may be abandoned or pin an old PHP version. Run composer why-not php <your-version> and inspect the upstream repo's last commit date before committing to it.
• Service ID discovery. IDs may be dot-prefixed, underscored, or fully-qualified class names depending on the bundle's age. container:debug | grep -i toa (or debug:container on newer consoles) is faster than reading XML by hand.
• Failure semantics are undocumented. Determine early whether validation failures throw, return a boolean, or return a result object with an error collection — the controller/service glue differs substantially. Write one throwaway script that triggers a failure and var_dumps the outcome.
• Extension point is the DI extension, not the vendor tree. Add a compiler pass or override service definitions in your app config rather than patching files under vendor/. If the bundle's extension doesn't expose what you need, decorate the service in your own services.yml.
• Config key ambiguity. If the root alias isn't obvious from the bundle name (e.g. toa_validator vs. toa_validator_bundle), the Configuration.php getConfigTreeBuilder()->root(...) call is the single source of truth.