در دنیای امروزی، ارتباط و تبادل اطلاعات بسیار مهم و حیاتی شدهاند. از جمله راههای ارتباطی میتوان به ارسال و دریافت درخواستها یا Request ها اشاره کرد. در مقاله حاضر، ما به بررسی صحبت کردن در مورد Request ها در فرم خواهیم پرداخت. این موضوع بسیار مهم است زیرا تأمین اطلاعات صحیح و دقیق از طریق Request ها میتواند به بهبود فرآیندهای مختلف در یک سازمان کمک کند.
Form Requests بیشتر به دلیل انتقال منطقی اعتبارسنجی شما از کنترلرهای وب به کلاسی شناخته می شوند که برای شما از قبل اعتبارسنجی می شود. من همیشه به شدت از آن ها استفاده می کنم. با این حال، چه کارهای دیگری می توانیم با درخواست های فرم انجام دهیم؟ بیاید یک نگاهی به آن بیندازیم
فراتر از افزودن متدها و فراخوانی آنها در داخل کنترلرها، چند روش وجود دارد که اغلب در درخواستهای فرم شما استفاده نمیشوند و میتوانید برای افزودن قدرتهای فوقالعاده به برنامهتان به آنها تکیه کنید.
آماده سازی ورودی شما برای اعتبارسنجی
این روش زمانی فوقالعاده است که باید قبل از شروع اعتبارسنجی درخواست را تغییر دهید یا موارد بیشتری را به آن اضافه کنید. داکیومنت ها نمونهای از ادغام یک slug با چیزی را نشان میدهند که مفید است، اما در مورد مثال دیگری چطور؟
protected function prepareForValidation(): void
{
$this->merge([
'locale' => $this->user()->locale,
]);
}
ما در حال ادغام locale کاربران احراز هویت شده در درخواست هستیم ، بنابراین ممکن است اعتبارسنجی پویا را بر اساس منطقه کاربر انجام دهیم. فرض کنید در حال حاضر محدودیت هایی در برنامه خود داریم، به این معنی که کاربران از آمریکا باید چیزهایی را در قالب خاصی اضافه کنند.اما من چند مورد استفاده را به عنوان یک توسعه دهنده دیده ام که ممکن است مفید بوده باشد.
حتی میتوانیم محتوا را به صورت پویا در این روش جایگزین کنیم.
protected function prepareInputForValidation(): void
{
$replace = match ($this->user()->locale) {
'en_GB' => 17.5,
'en_US' => 10.0,
'de_DE' => 12.5,
};
$this->replace([
'tax_percentage' => $replace,
]);
}
در اینجا، ما به صورت پویا درصد مالیات را بر اساس منطقه کاربر تغییر می دهیم. اگر نرخ های مالیاتی خاصی را به عنوان بخشی از مالیات واردات خود به عنوان توزیع کننده داشته باشید، مفید است.
پاس کردن اعتبارسنجی
همانند آماده سازی برای اعتبار سنجی، می توانیم داده های درخواستی را که پس از تایید تصویب شده است، استاندارد کنیم یا در قالب خاصی قالب بندی کنیم. به عنوان کسی که روزانه با داده ها کار می کند، این بسیار مفید است.
protected function passedValidation(): void
{
$this->replace([
'name' => Str::uppercase($this->name),
]);
}
باز هم، این ها مفیدترین مثال ها نیستند - اما اگر بخواهید می توانید کارهای زیادی انجام دهید، از تبدیل ویژگی ها به آبجکت ، برای کار با پول گرفته تا بررسی محتوا برای هرزنامه.
مجوز ناموفق
معمولاً زمانی که درخواست فرم شما با مجوز مواجه نمیشود، فریمورک AuthorizationException ایجاد میکند. برای 99٪ موارد استفاده، این تنها چیزی است که نیاز دارید. با این حال، چند مواقع مبهم وجود دارد که میخواهید از ایجاد استثنایی مانند این اجتناب کنید. فرض کنید که از یک API شخص ثالث، وب هوکها را میگیرید، و گرفتن یک استثنای مجوز، رفتارهای عجیب و غیرقابل کنترلی را در این شخص ثالث ایجاد میکند. درعوض، میتوانید با نادیده گرفتن این روش در درخواست فرم، بیصدا شکست بخورید.
protected function failedAuthorization(): void
{
Log::info('Failed authorization for webhook capture ....');
}
اینها تنها تعداد انگشت شماری از روش های موجود در یک درخواست فرم هستند، نه به ذکر همه روش هایی که با استفاده از پیش شناخت لاراول در دسترس هستند. اما همانطور که قبلاً اشاره کردم، میتوانیم روشهای خود را اضافه کنیم - به ما اجازه میدهد تا عملکرد درخواستهای فرم خود را کمی بیشتر گسترش دهیم. یک مثال عالی، کد منبع لاراول Breeze است، که در آن یک روش احراز هویت به LoginRequest اضافه میشود تا کد کنترلر را بتوان بیشتر سادهتر کرد.
بیایید به نمونه ای از یک کنترلر که من معمولاً می نویسم نگاه کنیم:
final class StoreController
{
public function __construct(
private readonly StoreCommand $command,
) {}
public function __invoke(StoreRequest $request): Responsable
{
try {
$this->command->handle(
instance: new Instance(
name: $request->string('name')->toString(),
),
);
} catch (Throwable $exception) {
throw new FailedToCreateInstance(
message: 'Failed to create a new instance.',
previous: $exception,
);
}
return new CreatedResponse();
}
}
این یک کنترلر ساده است که در آن از یک کلاس برای ارسال از طریق یک Data Object استفاده میکنم تا کد من را ثابت نگه دارد و آنطور که دوست دارم پاک شود. با تکیه بر درخواست فرم خود می توانیم کد خود را بیشتر ساده کنیم.
final class StoreController
{
public function __construct(
private readonly StoreCommand $command,
) {}
public function __invoke(StoreRequest $request): Responsable
{
try {
$this->command->handle(
instance: $request->dto(),
);
} catch (Throwable $exception) {
throw new FailedToCreateInstance(
message: 'Failed to create a new instance.',
previous: $exception,
);
}
return new CreatedResponse();
}
}
اما تصور کنید که ما در حال ساخت چیزی ده برابر پیچیده تر با بسیاری از فیلدهای درخواستی هستیم که باید به شی داده خود برگردانیم - کنترلر ما در کمترین زمان بزرگ و نامرتب می شود. تمام کاری که ما در اینجا انجام داده ایم این است که ایجاد Data Object خود را به روشی در درخواست فرم منتقل کنیم.
محدودیتهای کاری که میتوانید در درخواستهای فرم خود انجام دهید تنها با تخیل شما محدود میشود، اما مطمئن شوید که از آنها عاقلانه استفاده میکنید. آنها برای جایگزینی منطق برنامه شما وجود ندارند، به یاد داشته باشید! اطمینان از اینکه منطق برنامه شما همیشه در دسترس و قابل خواندن است و در دریای منطق فریمورک یا اعتبار request گم نمی شود، ضروری است.
نتیجه
در این مقاله به بررسی مهمی به نام "صحبت کردن در مورد Request ها در فرم" پرداختیم. مطالبی راجع به تعریف و اهمیت Request ها ارائه دادیم و سپس به مراحل صحبت کردن در مورد این درخواستها پرداختیم.
