توجه! Symfony در برخورد اول شاید اعتیاد آور باشد! فصل سوم

توجه! Symfony در برخورد اول شاید اعتیاد آور باشد! فصل سوم

فصل سوم – Controller

 

هنوز بعد از گذشت دو قسمت با Symfony همراه هستید؟ آماده اید که به یکی از طرفداران Symfony تبدیل شوید! بدون هیچ مقدمه ای، یاد می گیریم که Controllerها چه وظایفی دارند!

 

برگشت پاسخ خام

 

سیمفونی، خودش را به عنوان یک فریم ورک Request-Response معرفی می کند. وقتی کاربر درخواستی (request) را به برنامه شما می فرستد، سیمفونی یک شیء Request برای کپسوله سازی تمام اطلاعات مرتبط با درخواست ایجاد می کند. به طور مشابه، نتیجه اجرا هر اکشن از هر کنترولر، یک شیء Response ایجاد می کند که سیمفونی محتوای HTML را تولید و به کاربر برگشت می دهد.

به این ترتیب تمام اکشن‌های این آموزش از میانبور $this->render() برای برگشت response استفاده می کنند. در این مورد، همچنین می توانید یک شیء Response برای برگشت هر نوع داده ایجاد کنید:

 

 

پارامترهای مسیر

 

بیشتر اوقات URL‌های برنامه شامل متغیرهایی نیز است. به عنوان مثال اگر بخواهید برای برنامه بلاگ خود این کار را انجام دهید، URL برای نمایش پست ها، می بایست شامل عنوان یا برخی شناسه های منحصر به فرد دیگر باشد تا برنامه تشخیص دهد دقیقا کدام پست را باید از دیتابیس استخراج و نمایش دهد.

 

در برنامه های سیمفونی، بخش متغیرها در بین آکولاد قرار می گیرد (/blog/read/{article_title}/). به هر متغیر نامی منحصر به فرد اختصاص داده می شود تا بعدا در controller مقدار هر کدام را استخراج کنیم.

 

اجازه دهید این ویژگی را با ایجاد یک اکشن جدید همراه با متغیرهایی نمایش دهیم. فایل src/AppBundle/Controller/DefaultController.php را باز کرده و متد جدیدی به نام helloAction با کدهای زیر اضافه کنید:

 

 

مرورگر خود را باز کرده و به آدرس http://localhost:8000/fabien مراجعه کنید تا خروجی حاصل از این متد جدید را مشاهده کنید. بجای اینکه نتیجه اکشن جدید را مشاهده کنید، با یک صفحه خطا رو به رو می شوید. همانطور که شاید حدس زده باشید، این خطا به این دلیل نمایش داده می شود چون سعی در نمایش قالب default/hello.html.twig که هنوز وجود ندارد را دارد.

 

برای این کار یک قالب جدید app/Resouces/views/default/hello.html.twig همراه با محتوای زیر ایجاد کرده:

 

 

حال دوباره آدرس http://localhost:8000/hello/fabien را در مرورگر اجرا کنید و خواهید دید که این قالب جدید همراه با دادهایی که از controller ارسال شده است نمایش داده می شود. اگر بخش آخر URL را تغییر دهید (به عنوان مثال http://localhost:8000/hello/thomas) و مرورگر را refresh کنید، صفحه پیام متفاوتی را نمایش خواهد داد. و اگر بخش آخر URL را حذف کنید (به عنوان مثال http://localhost:8000/hello) سیمفونی خطایی را به شما نمایش می دهد چون مسیر انتظار یک نام را دارد و آن را ارائه نداده اید.

 

با استفاده از فرمت

 

امروزه برنامه های وب باید این قابلیت را داشته باشند که بیش از یک صفحه HTML  ارائه دهند. از XML برای خوراک RSS یا وب سرویس‌ها، از JSON برای درخواست های Ajax استفاده می شود، همانطور که می بینید فرمت های مختلفی برای انتخاب وجود دارد. پشتیبانی از این فرمت‌ها در سیمفونی به لطف متغیر _format که فرمت درخواست شده توسط کاربر را ذخیره می کند امکان پذیر است.

 

اجازه دهید مسیر hello را با اضافه کردن متغیر _format با مقدار پیشفرض html ویرایش کنیم:

 

 

بدیهی است وقتی از چندین درخواست با فرمت های مختلف پشتیبانی می کنید، می بایست برای هر کدام از فرمت ها قالب ارائه دهید. در این مورد، می بایست قالب hello.xml.twig را ایجاد کنید:

 

 

حال وقتی به آدرس http://localhost:8000/hello/fabien مراجعه می کنید، یک صفحه HTML خواهید دید چون html به عنوان قالب پیشفرض ما تعریف شده است. وقتی به آدرس http://localhost:8000/hello/fabien.html مراجعه کنید، همین صفحه HTML را دوباره مشاهده می کنید، بخاطر این است که شما صریحا قالب html را درخواست کرده اید. در آخر، اگر به آدرس http://localhost:8000/hello/fabien.xml مراجعه کنید خواهید دید که قالب جدید XML در مرورگر نمایش داده می شود.

 

سیمفونی بطور خودکار برای فرمت‌های مختلف بهترین هدر Content-Type را برای response انتخاب می کند. برای محدود کردن فرمت های پشتیبانی شده، از گزینه requirements در حاشیه نویسی @Route() استفاده کنید:

 

 

حال اکشن hello در آدرس هایی مثل /hello/fabien.xml یا /hello/fabien.json پیدا می شود، اما اگر آدرسی مثل /hello/fabien.js را درخواست کنید با صفحه 404 روبرو می شوید، به این خاطر است که در متغیر _format فرمت js اضافه نشده است.

 

هدایت (redirect)

 

اگر می خواهید کاربر را به یک صفحه دیگر منتقل کنید، از متد redirectToRoute() استفاده کنید:

 

 

متد redirectToRoute() نام مسیر و آرایه ای دلخواه از پارامترها را به عنوان آرگومان قبول می کند و کاربر را بسته به این آرگومان‌ها به صفحه دیگر انتقال می دهد.

 

نمایش صفحه خطا

 

خطاها به ناچار در هنگام اجرای هر برنامه وب دیده می شود. در این مورد از خطاهای 404، سیمفونی شامل یک میانبر مفید است که به شما اجازه می دهد در controller خود استفاده کنید:

 

 

برای خطاهای 500، تنها لازم است از یک استثنا PHP در داخل controller استفاده کنید و Symfony آن را به یک صفحه 500 تبدیل کند:

 

 

گرفتن اطلاعات از Request

 

گاهی اوقات controller شما نیاز به دسترسی اطلاعات مربوط به درخواست کاربر دارد، مثل زبان، آدرس IP یا پارامترهای کوئری. برای دسرسی به این داده ها، لازم است آرگومان جدید از نوع Request را به اکشن اضافه کنید. اسمی که برای این آرگومان جدید انتخاب می شود مهم نیست، اما باید با توجه به نوع Request و وظیفه ای که بر عهده دارد نامگذاری شود (توجه داشته باشید که از دستور use برای وارد کردن کلاس Request استفاده شود).

 

 

در این قالب، شما همچنین به شی Request از طریق متغیر app.request که بطور خودکار توسط سیمفونی ارائه می شود دسترسی دارید:

 

 

تداوم دادها در Session

 

سیمفونی شامل یک شی Session عالی است که نشان دهنده کاربر است (آیا یک کاربر واقعی است که با مرورگر کار می کند، ربات است، یا یک وب سرویس). بین دو درخواست، سیمفونی ویژگی‌ها را با استفاده از جلسه‌ها در PHP در یک cookie ذخیره می کند.

 

ذخیره و بازیابی داده‌ها از session را می توان از هر کنترولری استخراج کرد:

 

 

شما همچنین می توانید flash message ها را ذخیره کنید که با هر درخواست جدید بطور خودکار پاک می شوند. اینها وقتی مفید هستند که می خواهید یک پیام با موفقیت انجام شده را قبل از انتقال کاربر به صفحه دیگر نمایش دهید:

 

 

و می توانید پیام flush را در قالب بصورت زیر مشاهده کنید:

 

 

سخن پایانی

 

این تمام چیزی است که به آن نیاز دارید، من حتی مطمئن نیستم که شما 10 دقیقه کامل را برای این پست صرف کرده باشید. شما بطور خلاصه با بسته نرم افزاری در بخش اول آشنا شدید و تمام ویژگی‌هایی که تاکنون بخشی از هسته فریم ورک سیمفونی است را یاد گرفته اید. اما باید از این بسته نرم افزاری تشکر کرد، همه چیز در سیمفونی می تواند توسعه یا جایگزین شود. این چیزی است که در فصل بعدی به آن می پردازیم.