The introduction
In the previous chapter, I talked about using FormBuilder to let back-end developers quickly build front-end form pages, and for example, storing form data directly into the database in the Store method. This!!!! Very!!!! Dangerous! Danger!
This article will teach you how to correctly validate data submitted by a user’s form. It is the Laravel validator that has been used for more than a decade.
Review past
To get started, I reposted the previous section to see what it looked like in its original form:
public function store(Request $request)
{
$event = Event::create([$request->input()]);
flash('Event created! ')->success();
return redirect()->route('events.show')->with('event'.$event);
}
Copy the code
Event::create([$request->input()])) The form data for the Request Request is passed into the create method intact and written to the database.
Of course, in the Event model, I’ve added $fillable to mark fields that can write data, but that’s still not enough. Only specify fields that can be written, but what values to write are not filtered, whether a chunk is missing.
The user’s input was never directly usable, so I had to create a barrier, one layer at a time, where valid data was put in and invalid data was kept out.
Additional validation
Add some more code to the code above:
The request−>validate()∗∗ method instantiates a Validator object, and the ∗∗request->validate()** method instantiates a Validator object by default. By default, **request−>validate()∗∗ instantiates a Validator object, and all input data of ∗ Request ->input() is used as validation objects by default. What matters are the validation rules, and I’ll explain them to you one by one. The validation rules are all written in Laravel and ready to use.
Field name is a mandatory string of 10 to 50 characters:
'name'= >'required|string|min:10|max:50'.Copy the code
The max_CONTENT field is mandatory. It must be an integer with 2-5 digits. That’s between 10 and 99,999.
'max_attendees'= >'the required | integer | digits_between: 2, 5'.Copy the code
The validation for field description is not so much, only required, which requires a string:
'description'= >'required|string'
Copy the code
Error information is displayed in the view template
With validation rules in place, we need to carry error messages for validation failures. Because the error message is global, modify the view template file to take effect globally, append the following:
<div class="container">
@if ($errors->any())"div class="alert alert-danger">
<ul>
@foreach ($errors->all(a)as $error)
<li>{{ $error }}</li>
@endforeach
</ul>
</div>
@endif
@yield('content')
</div>
Copy the code
The $errors object contains all forms validation errors. This way, error messages are inherited in all views that use the template. It’s ** write once, work everywhere **.
To verify that the form validation is working, you can click submit on the blank form and output something like this:
The red warning is that $errors comes into play in the view template file.
Custom error message
Error messages are given by laravel’s built-in validation rules, and if you don’t find them detailed or satisfying, you can write your own. Let me rewrite the validation rules above.
Instead of using the $request->validate() method, use the Validator object to construct validation.
The code is as follows:
The most special is the :attribute placeholder in the Required validation rule. This is a placeholder for calling this validation rule in a field is passing in the character name.
And why? That’s how Validator is designed!
Write in the last
This article provided an initial introduction to the use of built-in rules for the Laravel validator and how to render validation information into view files. This section describes how to use custom authentication error messages.
Happy coding 🙂
I am a @programmer assistant, an original author in the IT field who focuses on programming knowledge and circle dynamics