在上一篇文章中，我们学会了如何将信息发送到服务器并将任务保存在表中。但是，如果用户发送错误的信息或将任务标题字段留为空怎么办？我告诉你了！在这种情况下，我们将遇到以下页面：

要解决此问题，我们需要在添加新记录之前确保请求的数据正确。我们可以评估使用Laravel的request Helper函数中的Laravel验证属性输入的信息。

请求验证

为此，让我们回到控制器中的商店功能，并定义一组规则以评估输入的信息。

第一个规则是检查是否需要任务标题，以便用户无法发送空名称。

public function store()
{
    request()->validate([
        'title' => 'required'
    ]);

    $task = new Task();
    $task->title = request('title');
    $task->save();
    return back();
}

现在，如果我们将标题字段留为空并发送请求，我们将看到上一个错误页面未显示，并且只有该页面刷新。但是，如果我们要显示与用户请求相关的错误并维护程序的用户界面，则需要显示错误变量。错误变量包含JSON数据，并且在评估阶段拒绝我们的请求时，它将向我们返回相关的错误消息。

要显示来自评估阶段的错误消息，我们需要对与我们创建任务相关的刀片文件进行一些更改。通过这样做，当我们发送带有空字段的请求时，我们将看到以下结果：

让我们添加一些其他规则，例如字符限制：

或确保未重复任务标题（尽管通常用于用户名或内部站点地址，但我们在这里将其用于教育目的）：

您还可以考虑其他信息的其他条件，该信息的列表可以在Laravel官方Doc here中找到。

您可能注意到的另一件事是，当用户在其请求中遇到错误时，该字段就会清除。为了防止这种情况，有一个称为旧的有用的辅助功能，它允许您返回用户先前输入的值。让我们将其添加到我们的表格中：

现在，让我们向我们的任务模型添加另一个属性，即任务描述，它让用户更适合一个任务，但是此属性绝对不需要，我们希望用户将其添加为可选数据。

要做到这一点，我们需要在项目中添加另一个缓解措施，以将另一列添加到任务表中！

在开发尚未开发但尚未发布的项目时，请记住这一重要提示。至关重要的是要保持迁移简单，并避免创建太多单独的迁移文件。拥有许多迁移可能会使跟踪和理解数据模型属性变得困难。在为实时的，可以生产的应用程序添加更改时，必须创建一个新的迁移。因为，至关重要的是避免意外重置任何现有数据。

但是在这里，仅出于学习目的，我添加了另一个迁移：

php artisan make:migration add_description_to_tasks_table

正如您在跟踪函数中看到的那样，我只在我们的任务表中添加一列：

/**
 * Run the migrations.
 */
public function up(): void
{
    Schema::table('tasks', function (Blueprint $table) {
        $table->text('description')->after('title')->nullable();
    });
}

/**
 * Reverse the migrations.
 */
public function down(): void
{
    Schema::table('tasks', function (Blueprint $table) {
        $table->dropColumn('description');
    });
}

您注意到，您可以使用after方法来指定要添加列的确切位置。此外，您可以使用nullable属性允许列包含空值。尽管您还可以通过default方法为列设置默认值，但是它建议使用nullable，因为它对查询速度更加优化。但是，请注意，有些情况，例如布尔列，其中使用nullable可能不可行或不合适。

现在让我们运行并检查结果：

一切都很好，但是描述不在！

Laravel提供了用于使用数据库的方便方法，但某些方法存在局限性，尤其是在使用SQLite时。不幸的是，SQLite不支持将列插入表中的特定位置。因此，即使您在Laravel中使用after方法，该列也不会按预期在指定的列之后立即放置。这是Sqlite本身的限制，它不是可以通过Laravel方法直接解决的。

幸运的是，此限制仅适用于SQLite数据库。如果您使用PostgreSQL或MySQL，您会遇到此

为了解决此问题，我们可以删除最后的迁移，并且随着更改任务迁移文件。我们可以用：
重置所有表

php artisan migrate:reset

，假设我们有一些数据将它们重置为重置，所以这里的解决方案是回滚所有迁移文件！

回滚最后迁移您可以使用以下命令：

php artisan migrate:rollback 

和回滚一定数量的迁移：

php artisan migrate:rollback --step=<steps_count>

我只是删除了最后一个迁移文件，然后在任务迁移文件中进行更改，您会在运行php artisan migrate命令后看到我们所需的更改！

我添加了一些用于描述的规则，您可以在以下图片中看到，一切正常：

那太简单了吗？嗯！

现在让我们添加另一个字段？到期日和时间呢？为此，让S添加另一个名为expired_at的时间列，它也是无效的

Schema::create('tasks', function (Blueprint $table) {
    $table->id();
    $table->string('title');
    $table->text('description')->nullable();
    $table->timestamp('expired_at')->nullable();
    $table->timestamps();
});

这是让任务再次迁移表：

php artisan migrate:rollback
php artisan migrate

然后，我们必须将存储功能更新为Bellow：

public function store()
{
    request()->validate([
        'title' => 'required|min:3|max:120|unique:tasks,title',
        'description' => 'nullable|min:3|max:255',
        'expired_at' => 'nullable|date|after:now'
    ]);

    $task = new Task();
    $task->title = request('title');
    $task->description = request('description');
    $task->expired_at = new \DateTime(request('expired_at'));
    $task->save();

    return redirect("/");
}

有几个要考虑的要点。首先，当您需要在Laravel中验证日期时，可以使用内置日期验证规则。让我们在下面评论它们：

日期：此验证规则检查给定输入是有效的日期：

'date_field' => 'required|date'

date_format：此规则验证输入是否匹配特定日期格式：

'date_field' => 'required|date_format:Y-m-d',

之后此规则确保输入日期是指定日期之后的：

'date_field' => 'required|date|after:2023–01–01', // or maybe tommorow

after_or_equalð此规则验证输入日期是否等于指定日期或之后：

'date_field' => 'required|date|after_or_equal:2023–01–01',

此规则确保输入日期是指定日期之前的：

'date_field' => 'required|date|before:2023–01–01',

tre_or_equalð此规则验证输入日期是否等于指定日期或之前：

'date_field' => 'required|date|before_or_equal:2023–01–01',

通过使用这些日期格式验证规则，您可以确保输入日期符合您在Laravel应用程序中指定的标准。

第二点是将Execred_at数据铸造为确切的DateTime PHP数据类型。有时，Laravel也不会自动识别数据类型，即使我们验证数据类型。为了解决它，我们可以使用DateTime助手类。或在数据模型内施放！怎么样？！

当我们创建Task模型时，我们实际上创建了一个雄辩的模型，这在Laravel中是一个了不起的功能。但是，到目前为止，我们尚未对其进行任何修改。默认情况下，我们创建的每个雄辩的模型都存储在我们Laravel项目的app/models目录中（请注意，此位置可能在较旧版本中有所不同）。为了将数据投入我们的模型，我们需要通过在casts变量中添加规则来进行一些更改，例如：

protected $casts = [
    'expired_at'  => 'datetime'
];

通过此定义，我们不再需要使用Datetime类：

public function store()
{
    request()->validate([
        'title' => 'required|min:3|max:120|unique:tasks,title',
        'description' => 'nullable|min:3|max:255',
        'expired_at' => 'nullable|date|after:now'
    ]);

    $task = new Task();
    $task->title = request('title');
    $task->description = request('description');
    $task->expired_at = request('expired_at');
    $task->save();

    return redirect("/");
}

请注意，您不需要为created_at和updated_at列铸造，因为Laravel默认情况下会处理它们。但是，总的来说，被认为是明确定义所有数据模型并相应地将其施放的最佳实践：

protected $casts = [
    'title'       => 'string',
    'description' => 'string',
    'created_at'  => 'datetime',
    'updated_at'  => 'datetime',
    'expired_at'  => 'datetime'
];

这种方法可确保您清楚地了解每个模型的属性及其各自的数据类型。请记住，在现实世界项目中，有时通过仅依靠迁移来确定数据模型的所有字段可能会具有挑战性。

这是结果：

每次您需要浏览项目时，您都可以找到here！

就是这样！希望您发现这个教程愉快！