فروم یک چیز پیچیده است. مطمئناً از موضوعات و پاسخ ها تشکیل شده است ، اما چه چیز دیگری به عنوان بخشی از یک فروم ممکن است وجود داشته باشد درمورد پروفایل ها ، یا اشتراک های موضوع ، یا فیلتر یا اعلان های(notifications) به صورتreal-time ؟ همانطور که معلوم است ، یک فروم یک پروژه عالی برای تقویت پایه برنامه نویسی شماست. در این بخش، ما میخواهیم یکی را از A تا Z بسازیم.
بیایید با بررسی حداقل شرایط لازم برای یک فروم شروع کنیم.اگر به آن فکر کنید ، ما نمی توانیم بدون کاربران ، موضوعات و پاسخها یک فروم ایجاد کنیم.
اکنون که داده seed خود را در اختیار داریم ، می توانیم سراغ یک ویژگی کوچک برویم: "یک کاربر باید بتواند موضوعات را بخواند." همینقدر ساده! ما با یک تست اولیه شروع می کنیم ، و سپس آن را گسترش میدهیم..
اکنون که یک ویژگی اصلی برای خواندن موضوعات انجمن اضافه کرده ایم ، می توانیم در ادامه مشاهده همه پاسخ های مرتبط با هر موضوع را شروع کنیم. مانند گذشته ، ما برای نتیجه مطلوب خود با یک تست شروع خواهیم کرد.
ما عملکردهای لازم را برای ارائه یک متن با تمام پاسخ های مربوطه اعمال کرده ایم ، اما هنوز به کاربر اجازه نداده ایم که یک پاسخ را تایپ کند و آن را به سرور ارسال کند. بیایید از همین حالا شروع کنیم.
اکنون که ما end-point را برای اضافه کردن پاسخ جدید تست کرده ایم ، تنها مرحله باقی مانده ایجاد HTML برای فرم است. در این فرآیند ، ما همچنین مطمئن خواهیم شدکه فقط کاربران لاگین کرده قادر به دیدن آن هستند.
تا الان کاربر می تواند موضوعات را بخواند و پاسخ دهد ، اما آنها هنوز توانایی انتشار موضوعات خود را ندارند. بیایید این قسمت را بررسی کنیم.
بهتر است که روند نوشتن تست ها را تا حد ممکن از نظر انسانی طبیعی انجام دهیم. هر چه ساختن یک تست دشوارتر باشد، احتمال اینکه شما به راحتی انجام ندهید، بیشتر است.
اکنون که تست های endpoint ما تمام شده اند ، می توانیم فرم HTML را برای انتشار موضوع جدید بسازیم. با این حال ، در این فرایند در برخی موارد استثناء دچار مشکل خواهیم شد. خوشبختانه ،Adam Wathan راه حل مفیدی دارد که ما می توانیم آن را پیاده سازی کنیم.
در حال حاضر ، همه موضوعات به صورت "global" است . در حالت ایده آل ، ما باید هر موضوع را به یک کانال اختصاص دهیم. به این ترتیب ، برای یک دولوپر فروم ، ما می توانیم به راحتی موضوعات را توسط PHP یا JavaScript یا سرور فیلتر کنیم.
ما هنوز هیچ منطقی برای اعتبار سنجی برای فروم خود ننوشتیم. این بدان معنی است که یک کاربر می تواند با انواع داده های نامعتبر یک درخواست را ارسال کند ، و ما آن را در بانک اطلاعاتی قراردهیم. بیایید این مسئله را در این قسمت حل کنیم.
اکنون که همه موضوعات را با یک کانال مرتبط کرده ایم ، اکنون می توانیم اپدیت های ضروری UI را انجام دهیم تا کاربران بتوانند موضوعات را توسط کانال مورد نظر خود فیلتر کنند.
در این قسمت ، ما باید در صفحه "ایجاد موضوع" کمی کار انجام دهیم. ما ابتدا لینکی به نوار پیمایش یا navigation bar اضافه می کنیم و سپس به سراغ تغییر فرم خود ، می رویم. به طور خاص ، ما باید بازخورد خطای اعتبارسنجی را ارائه دهیم ، و اطمینان حاصل کنیم که در صورت ایجاد خطای اعتبارسنجی ، متنی که کاربر در قسمتهای مختلف فرم وارد می کند ، یادآوری می شود..
در حال حاضر ، ما دو کوئری مختلف SQL برای واکشی کلیه کانالها به طور مستقیم در لایه view خود داریم. بیایید در این آموزش آن را با استخراج یک view composer اختصاصی رفع کنیم.
اگر هر کاربر بتواند لینکی داشته باشد که فقط موضوعاتی را که شخصاً ایجاد کرده است را ببینید خیلی خوب است. و حتی فراتر از آن ، چرا نمی توان امکان مشاهده موضوعات کاربر را فراهم کرد؟ بیایید در این آموزش این را بررسی کنیم.
از آنجایی که به نظر می رسد فیلتر جزء مهم برنامه ما خواهد بود ، بیایید زمانی را برای ریفکتور را صرف کنیم. خوشبختانه ، ما مجموعه ای از تست ها را برای پشتیبان گیری از هر مرحله از راه داریم ، پس می توانیم به اندازه کافی جسور باشیم. هیچ ترسی از شکستن برنامه وجود ندارد.
برای اطلاعات متنوع ، مانند زمان انتشار موضوع ، تعداد پاسخ ها و موارد دیگر ، باید یک sidebar به هر صفحه موضوع اضافه کنیم. علاوه بر این ، باید pagination را به برنامه خود اضافه کنیم. چه اتفاقی می افتد وقتی که یک موضوع بیش از صد پاسخ داشته باشد؟ بیایید مطمئن شویم که پیوندهای pagination مناسب را به کار می بریم.
اگر کاربران توانایی فیلتر کردن همه موضوعات با محبوبیت بیشتر را داشته باشند خیلی خوب است. به این ترتیب ، فعال ترین موضوعات همیشه بالا قرار میگیرند. بیایید یک تست بنویسیم و سپس این feature را اجرا کنیم.
این امر مفید خواهد بود اگر کاربران معتبر (authenticated ) بتوانند توانایی پاسخگویی به موضوعات مورد علاقه خودشان را داشته باشند. بیایید پیاده سازی این قابلیت ها را با استفاده از روابط polymorphic شروع کنیم.
اکنون که فرآیند کامل favoriting a reply را تست کرده ایم ، می توانیم به سمت ایجاد فرمی برای پردازش این اکشن برای یوزر برویم. در این فرآیند، در مورد N+1 problem بحث خواهیم کرد.
میخواهیم مسئله N + 1 را مرور کنیم ، زیرا مربوط به Eloquent است. برای این کار ، Laravel Debugbar را نصب می کنیم تا بتوانیم کوئری های دقیق SQL را که برای هر بار صفحه اجرا می شود ، تجزیه و تحلیل کنیم. همانطور که یاد خواهید گرفت ، چندین گام ساده وجود دارد که می توانیم برای کاهش تعداد کوئری های خود توسط ده ها نفر استفاده کنیم.
در این بخش به بررسی global Eloquent scopes می پردازیم.
اگر هر کاربر در انجمن ما دارای صفحه پروفایل مرتبط باشد بسیار مفید خواهد بود. به این ترتیب ، می توانیم اطلاعات بیشتری درباره آنها ، از جمله موضوعاتی که آنها شخصاً ایجاد کرده اند ، بررسی کنیم.
یکی از قابلیت های ساده ای که ما هنوز پیاده سازی نکرده ایم ، گزینه حذف موضوعات است. اگر "John Doe" موضوعی را ایجاد کند و بعداً نظر خود را تغییر دهد ، اجازه دهید آن را به طور کامل حذف کند.
باید مراقب باشیم که سهواً هیچ یک از کاربران رجیستر شده در انجمن نتواند همه موضوعات را حذف کند. بیایید یک policy class ایجاد کنیم تا مطمئن شویم که این اتفاق نمی تواند رخ دهد.
در این قسمت، ما از TDD برای هدایت یک activity feed استفاده خواهیم کرد. برای مثال می توانیم track کنیم که کاربر موضوع جدیدی در انجمن ایجاد می کند یا پاسخی ارسال می کند. مثل همیشه، با ابتدایی ترین پیاده سازی ممکن شروع خواهیم کرد.
اکنون که کد لازم برای ثبت کلیه activity های مربوطه را نوشتیم، در این قسمت می توانیم آن را به صفحه پروفایل کاربر ارائه دهیم و همه رکوردهای مربوطه را بر اساس تاریخ آنها گروه بندی کنیم.
در حال حاضر، ما یک Eloquent query در کنترلرخود داریم. بیایید از TDD برای استخراج آن در Activity model استفاده کنیم.
به نظر میاد یک باگ در activity feed خود داریم. اگر موضوعی را حذف کنیم چه اتفاقی می افتد؟ آیا این کار باعث حذف کلیه activity های مربوطه در این فرآیند می شود؟ و در غیر این صورت، چه اتفاقی می افتد که می خواهیم صفحه پروفایل کاربر را مشاهده کنیم؟بیایید یک تست رگرسیون بنویسیم تا بفهمیم.
در این قسمت، ما با استفاده از Vue یک سیستم flash messaging را پیاده سازی خواهیم کرد. به این ترتیب، هنگامی که یک کاربر اکشن مهمی را انجام می دهد، می توانیم flash message کنیم تا نتیجه را نشان دهد.
At the moment, a user's activity feed will exclusively display a timeline of their own threads and replies. Let's extend that in this episode to include any replies that they've favorited.
We're still missing a very basic piece of functionality. Any authorized user should be able to delete a reply. Let's implement that in this episode.
We're starting to realize that each individual forum reply should have a decent amount of behavior associated with it. With that in mind, in this episode we'll create a dedicated Vue component for a reply, and then implement the necessary functionality to quickly edit the body of a reply without requiring a page refresh.
Now that each reply is wrapped within a dedicated Vue instance, we can easily swap out the traditional form for deleting the reply with a snappier AJAX version that doesn't require a page refresh.
We have one last piece of the puzzle, when it comes to our Reply component. The favoriting functionality still consists of a traditional form. Let's turn that into a dedicated Favorite component to clean things up.
I think we've introduced a couple of bugs related to adding and removing activity. Let's work through them in this episode and patch things up, before moving on to a new feature.
In this episode, we'll do a decent amount of refactoring to push toward a more data-centric approach, when it comes to our Vue components. As part of this refactor, we'll need to figure out how to rewrite inline-templates that use Blade into JavaScript.
Now that we're thinking in terms of Vue collections, we can easily turn the form for publishing a new reply into its own component. This way, when the user submits the form, we can simply perform an AJAX call to persist the data, and then push to the "replies" collection - which will, in response, automatically trigger a re-render.
Since we're now rendering all replies with JavaScript, we can no longer depend upon rendering pagination links on the server-side. To compensate, let's create a dedicated paginator Vue component to handle all the necessary logic behavior.
I've learned from running the Laracasts forum that users often want to filter all threads according to those that have not yet received replies. Let's add that very functionality in this episode.
It would be useful if users could subscribe to any number of threads in our forum. That way, each time a reply is left, the user will immediately be notified. Let's get started implementing this very functionality.
Jeffrey Way
Jeffrey Way
Jeffrey Way
Jeffrey Way
Jeffrey Way
Jeffrey Way
