Validation
Introduction
Maravel provides several different approaches to validate your application’s incoming data. By default, Maravel’s base controller class uses a ProvidesConvenienceMethods trait which provides a convenient method to validate incoming HTTP request with a variety of powerful validation rules.
In general, validation in Maravel works exactly like validation in Maravelith, so you should consult the full Maravelith validation documentation; however, there are a few important differences.
Differences From Maravelith
Form Requests
Form requests are now supported by Maravel. To use them with autowiring in the controller’s method, the bellow code must be uncommented in the \App\Application.
/**
* Uncomment to use \App\FormRequest
* @inheritdoc
* Used to avoid Illuminate\Support\ServiceProvider\FormRequestServiceProvider::boot
*/
protected function fireResolvingCallbacks($abstract, $object)
{
$this->fireCallbackArray($object, $this->globalResolvingCallbacks);
/** This avoids Illuminate\Support\ServiceProvider\FormRequestServiceProvider::boot */
if ($object instanceof \Illuminate\Http\FormRequest) {
\Illuminate\Http\FormRequest::createFrom($this['request'], $object);
$object->setContainer($this);
}
$this->fireCallbackArray(
$object,
$this->getResolvingCallbacksForType($abstract, $object)
);
/** This avoids Illuminate\Support\ServiceProvider\FormRequestServiceProvider::boot */
if ($object instanceof \Illuminate\Contracts\Validation\ValidatesWhenResolved) {
$object->validateResolved();
}
$this->fireAfterResolvingCallbacks($abstract, $object);
}
The reason it is commented is to avoid those two ifs executing on every resolve if FormRequest is not used.
Still, the \App\FormRequest can be used without the above code with maravel-rest-wizard or laravel-crud-wizard-free libs via a base Controller class:
protected function validateCreateRequest(Request $request): array
{
$formRequest = ResourceRequest::createFrom($request, new ResourceRequest(resource: $this->label));
$formRequest->setContainer(\app());// notice the diff vs Maravelith, no ->setRedirector($app->make(Redirector::class));
$formRequest->validateResolved();
return $formRequest->validated();
}
This will allow maravel-rest-wizard-decorator or laravel-crud-wizard-decorator-free libs to decorate the error messages keys. If the ValidationException is thrown from the method autowiring, the decorator middleware will not catch it, resulting in undecorated keys being presented on response.
The $this->validate Method
The $this->validate helper which is available in Maravel will always lead to a JSON response with the relevant error messages. This is in contrast to the Maravelith version of the method which will lead to a redirect response if the request is not an AJAX request. Since Maravel is stateless and does not support sessions, flashing errors to the session is not a possibility. If you would like to use redirects and flashed error data, you should use the full Maravelith framework.
Unlike Maravelith, Maravel provides access to the validate method from within Route closures:
use Illuminate\Http\Request;
$router->post('/user', function (Request $request) {
$this->validate($request, [
'name' => 'required',
'email' => 'required|email|unique:users'
]);
// Store User...
});
Of course, you are free to manually create validator instances using the Validator::make facade method just as you would in Maravelith.
The exists And unique Rules
If you would like to use the exists or unique validation rules, you should uncomment the $app->withEloquent() method call in your bootstrap/app.php file.
The $errors View Variable
Maravel does not support sessions out of the box, so the $errors view variable that is available in every view in Maravelith is not available in Maravel. Should validation fail, the $this->validate helper will throw Illuminate\Validation\ValidationException with embedded JSON response that includes all relevant error messages. If you are not building a stateless API that solely sends JSON responses, you should use the full Maravelith framework.