Respect Validation Bundle Laravel Package

Getting Started

Register the bundle the usual Symfony 2 way, after installing via Composer:

composer require tear/respect-validation-bundle

// app/AppKernel.php
public function registerBundles()
{
    $bundles = array(
        // ...
        new Tear\RespectValidationBundle\TearRespectValidationBundle(),
    );
}

There is normally nothing to configure — the bundle's job is to make Respect\Validation\Validator available as a container service so you can inject it instead of relying on the static v:: facade. First thing to do after install is read the bundle's DependencyInjection/ directory and services.xml (or services.yml) to confirm the exact service id, because that's what you'll reference everywhere:

grep -r "class\|service id" vendor/tear/respect-validation-bundle/DependencyInjection

The first realistic use case is validating a plain array or DTO coming in from a Form DataMapper, a console command, or an importer — anywhere you already have raw data and want the fluent Respect rules without building a full Symfony Form for it:

use Respect\Validation\Validator as v;

$payload = ['email' => '[email protected]', 'age' => 42];

$result = $this->get('tear.respect_validation')   // or whatever your service id is
    ->key('email', v::email())
    ->key('age', v::intType()->between(1, 120))
    ->validate($payload);

Implementation Patterns

Inject the validator, don't call v:: statically in services. The main reason to install the bundle (rather than just respect/validation on its own) is container integration. In a Symfony 2 service, Respect\Validation\Validator is essentially a stateless factory of rule objects, but injecting it makes your code testable and keeps your DI definitions in one place:

# services.yml
services:
    app.registration_handler:
        class: AppBundle\Handler\RegistrationHandler
        arguments: ['@tear.respect_validation']

DTO / boundary validation before persistence. Respect rules map cleanly onto DTO properties, and this is the lowest-friction way to use the bundle day-to-day:

public function validate(RegistrationInput $input): void
{
    v::attribute('email', v::email()->notEmpty())
        ->attribute('password', v::stringType()->length(8, 64))
        ->assert($input);
}

Compose rules as named factories. Rather than repeating chains across handlers, define small methods or classes that return a Validator instance. This keeps tests and controllers consistent:

final class UserRules
{
    public static function registration(): v
    {
        return v::key('email', v::email())
                ->key('name', v::stringType()->notEmpty()->length(1, 255));
    }
}

Bridge into Symfony's Validator where it fits. If a Form uses the standard validator service and you want Respect rules there, write a small Constraint that delegates to v:: in its validate() method. This lets you keep the bundle in the background while still using @Assert\-style annotations for other fields. For one-off controller checks, however, direct use is simpler and the bundle adds nothing — so use it where it naturally reduces friction, not everywhere.

Validate nested structures with key() / attribute() / each(). This is where Respect shines compared to Symfony's validator for array-based data (e.g. CSV import rows, JSON APIs, message payloads):

$rowRules = v::key('sku', v::alnum()->noWhitespace()->length(3, 20))
              ->key('qty', v::intType()->positive())
              ->key('price', v::floatType()->positive());

v::each($rowRules)->assert($rows);

Gotchas and Tips

Confirm the service id before writing anything else. The bundle has zero stars and minimal documentation; the actual service id and class names are the bundle's contract, and they are not standardised. Read Resources/config/services.yml (or the Extension class) first, and note it in your team's docs — future upgrades or a forked copy will otherwise break silently.

Symfony 2 is EOL, and Respect\Validation has moved on. The bundle was written for the Symfony 2.7–3.x era, and current Respect\Validation releases (2.x/3.x under respect/validation) changed namespaces and APIs (e.g. stringType(), intType() instead of older aliases, plus a different exception hierarchy). Pin versions in composer.json and verify which Respect major version the bundle's composer constraint actually pulls in. Mixing a newer Respect in with the bundle's service definition is the most likely failure mode.

Namespace collision between the bundle and the library. Tear\RespectValidationBundle\... wraps Respect\Validation\Validator. If you only need the static facade you don't need the bundle at all — just require the library. Only keep the bundle if you are genuinely wiring the service into the container; otherwise you're carrying a stale dependency for no benefit.

Catch Respect\Validation\Exceptions\ValidationException, not GroupedValidationException by default. assert() throws a specific exception per rule, and the bundle doesn't change that. If you want aggregated errors, use ->validate() and inspect getMessages(), and be explicit about which exception type your caller catches — otherwise a caller checking for ValidationException will miss the grouped case.

Error messages are per-rule and English by default. Respect ships translations, but wiring them into the Symfony translator is your job with this bundle — the bundle typically doesn't bridge translations for you. Wrap rule chains in a factory that calls setName() on rules and feeds getMessages() through $translator->trans() if you need localised output.

Debugging is best done outside the container. When a rule chain fails unexpectedly, reduce it to a one-liner in php -r with pure v:: — that isolates whether the issue is the rule chain or the bundle wiring. If the rule works standalone but not through the service, the problem is almost always a stale container cache (app/console cache:clear --env=dev) or a service definition pointing at the wrong class.

Treat it as an extension point, not an abstraction. The cleanest long-term move on a legacy project is to wrap the bundle's service behind your own thin validator interface. That way replacing a two-file abandoned bundle with a maintained alternative, or upgrading Respect, is a single class change rather than a grep across every handler.