รูปแบบการสร้างเมนู


9

ฉันมีปัญหาในการจัดการกับเมนูที่ไม่ได้ใช้ในการกำหนดเส้นทาง

ฉันมาจาก Drupal ที่ระบบเมนูจัดการการกำหนดเส้นทางเช่นกัน ดังนั้นการตั้งค่าสถานะที่ใช้งานและสถานะเส้นทางที่ใช้งานจะถูกจัดการโดยเส้นทาง (ที่ทำหน้าที่เป็นระบบการแสดงผลเมนูเช่นกัน)

ตอนนี้กรอบ PHP จำนวนมากมีคลาสเราเตอร์ที่จัดการการกำหนดเส้นทาง ดูเหมือนจะเป็นการแยกที่ดีเนื่องจากเมนูไม่ควรระวัง POST || ตัวเลือก || ... คำขอ

แต่เมื่อเขียนส่วนหน้าฉันพบว่าตัวเองเขียนโค้ดเมนูยาก หรือเก็บทุกอย่างใน DB และส่งค่าเหล่านั้นไปยังมุมมอง สิ่งที่ฉันไม่ชอบคือวิธีนี้คือคุณกำลังสร้างสำเนาของสิ่งที่คุณเขียนไว้ในเราเตอร์ แต่ตอนนี้ใช้คลาสเมนู

ตัวอย่าง:

Route::get('/somewhere','routename.somewhere','showStuffController');
Route::post('/somewhere','routename.somewhere','saveStuffController');

Menu::add('label.somewhere','routename.somewhere');

คุณกำลังแยกข้อกังวลที่นี่เพื่อที่ดี แต่เมนูขึ้นอยู่อย่างมากในเส้นทางเพื่อตั้งค่าสถานะการใช้งาน เมนูจะต้องรู้เกี่ยวกับลำดับชั้นเพื่อกำหนดเส้นทางการใช้งาน

ใช่แล้วการตั้งค่าเทรลแอคทีฟและคลาสสถานะแอคทีฟเป็นเรื่องของมุมมอง แต่มี

if ( Route::currentName() === $menuitem->getRouteName() ) { print 'active'; }

ทุกมุมมองของคุณดูโง่ ถ้าอย่างนั้นก็ให้เพิ่มแอคทีฟเทรลที่น่ารำคาญหากมันเป็นของจริง การจัดการสิ่งนั้นก่อนที่ภาพจะเรนเดอร์และตั้งค่าสถานะแอคทีฟเทรลให้เป็นจริงเพียง แต่ดูน่าเกลียดในแบบที่ฉันรู้

คำถามของฉันคือ:

มีรูปแบบหรือวิธีที่ชาญฉลาดในการทำความสะอาดนี้ดีกว่า ... ? หนึ่งควรจัดการ 'ปัญหา' เส้นทางที่ใช้งานอยู่ได้อย่างไร

ฉันกำลังคิดถึงเด็ก -> ผู้ปกครอง ดังนั้นเริ่มต้นด้วยโฆษณาในระดับที่ลึกที่สุดจากนั้นพยายามหาทาง แต่แล้วเด็กก็รู้เกี่ยวกับพ่อแม่ แต่พ่อแม่ไม่รู้อะไรเกี่ยวกับลูกของเขา (ดูแปลก)

คำตอบ:


1

เมื่อไม่มีการใช้เมนูสำหรับการกำหนดเส้นทาง

ฉันจะบอกว่าเส้นทางสามารถใช้สำหรับเมนู


ตามที่คุณได้ชี้ให้เห็นแล้วเราเตอร์จะเป็นสถานที่ที่ดีในการติดตั้งฉันไม่คิดว่ามันน่าเกลียดที่จะใช้เบ็ดซึ่งประเมินเมตาเมนูสำหรับหน้าปัจจุบันของแต่ละคำขอ

หากคุณทำให้มุมมองของคุณรับผิดชอบในการติดตามสถานะที่ใช้งานอยู่คุณไม่ได้แยกข้อกังวล มุมมองควรทำสิ่งที่พวกเขาทำเพื่อ - แต่ไม่จำเป็นว่าพวกเขายังจัดการสถานะเมนูของพวกเขา ข้อมูลเมตาของเมนูมักจะเป็นแอพพลิเคชั่นที่กว้างเหมือนกันและคุณต้องการเพียงแค่เส้นทางเพื่อให้สามารถค้นหาตัวเองและแสดงเมนูได้

ขึ้นอยู่กับเราเตอร์ของคุณและความต้องการของคุณฟังก์ชั่นที่ง่ายหรือคลาสที่ใช้ข้อมูลเมตาเมนูคงที่และเส้นทางปัจจุบันจะเพียงพอที่จะให้ข้อมูลทั้งหมดที่คุณต้องการในภายหลัง

เมตาเมนูของตัวเองไม่จำเป็นต้องเป็นวัตถุ โครงสร้างข้อมูลค่าคีย์แบบธรรมดาที่ไม่มีเมธอดควรเพียงพอในกรณีส่วนใหญ่

เบ็ดอาจสร้างวัตถุสถานะที่มีฟังก์ชั่นทั่วไปบางอย่างที่เกี่ยวข้องกับเมนูของคุณเช่น breadcrumbs, ความลึก, หน้าหลักหรือหน้าปัจจุบันและทำให้วัตถุนี้เป็นที่รู้จักในบริบทของคำขอ http ของคุณ คุณมีความเป็นไปได้ที่แตกต่างกันภายในตะขอ - แต่โดยทั่วไปแล้วมันเกี่ยวกับการรวบรวมเตรียมและส่งข้อมูลที่จำเป็นไปยังสิ่งที่รู้วิธีจัดการกับมัน

วิธีการนี้ปรับขนาดตามความต้องการของคุณและมีข้อได้เปรียบเล็กน้อย:

  1. ฐานข้อมูลของคุณไม่จำเป็นต้องจัดการกับข้อมูลที่คุณสามารถให้กับรันไทม์ด้วยต้นทุนที่ต่ำ
  2. คุณจะมีเมนู (เมตาดาต้า) ในที่เดียวซึ่งทำให้สามารถบำรุงรักษาได้
  3. หากคุณต้องการให้เมนูของคุณพึ่งพา 1: 1 ในเส้นทางของคุณอย่างสมบูรณ์คุณสามารถทำได้โดยการให้เมตาเมนูแบบไดนามิก
  4. หากเนื้อหาของคุณเติบโต (และเมนู) คุณสามารถย้ายข้อมูลนี้ไปยังเซสชันซึ่งอาจถูกเขียนลงในที่จัดเก็บค่าคีย์ด่วน
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.