Let’s modify the request stub to suit the needs of our application. Modify the file so that it looks like this:

<? php

namespace App \ Http \ Requests;

use Illuminate \ Foundation \ Http \ FormRequest;

class UploadFileRequest extends FormRequest
{
   / **
    * Determine if the user is authorized to make this request.
    *
    * @return bool
    * /
   public function authorize ()
   {
       return true;
   }

   / **
    * Get the validation rules that apply to the request.
    *
    * @return array
    * /
   public function rules ()
   {
       return [
           'fileName' => 'required | string',
           'userFile' => 'required | file'
       ];
   }
}

Not a lot of changes, but note that the authorize () method now returns true instead of false. This method decides whether or not to allow the request to log into the application. If this parameter is set to false, the request will not log in (which is usually a method on the controller). This would be a very convenient place to do any checks for user authorization or any other logic that might decide if a request can move to a controller. For now, we just return true so that everyone and everything can use the query.

The other method, rules (), is where all the magic comes into play regarding validation. The idea is simple: return an array containing a set of rules as:

'formFieldName' => 'constraints this field has separated by pipe characters (|)'

There are many different check constraints that Laravel supports out of the box. For a complete list of these, check out the online documentation here . For our application, there will be two fields for loading, which are sent via a POST request from the form in the front-end. The fileName parameter must be included in the body of the form (that is, required) and used as the name of the file under which we will store the file in the storage (this is done in the controller – we will return to it a little later). We also specify that the filename should be a string by adding a pipe character (|) and the word “string”. Constraints are always limited to pipes, which allows you to specify any additional criteria for a given field on one line! What a power!

The second parameter, userFile, is the actual file that the user uploads from a form on a web page. UserFile is also required and must be a file. Note. If we expected the uploaded file to be an image, we would instead use an image constraint, which would restrict the file types accepted as one of the popular image types (jpeg, png, bmp, gif, or svg). Since we want to allow the user to upload any type of file, we’ll just stick to the file check limit.

That’s all there is to the request object. Its main purpose is simply to maintain an acceptable set of criteria (constraints) that the form body parameters must satisfy in order to delve deeper into the application. It should also be noted that these two fields (userFile and filename) must also be specified inside the HTML as input fields (with the field name matching the name inside the request object).

You might ask: of course, this defines the characteristics of what a form request should contain, but where is the actual validation of these constraints done? We will deal with this further.

Leave a Reply

Your email address will not be published. Required fields are marked *

Leave a Reply

Your email address will not be published. Required fields are marked *