메뉴를 라우팅에 사용하지 않을 때 메뉴의 활성 상태 처리를 둘러 보는 데 문제가 있습니다.
메뉴 시스템도 라우팅을 처리하는 Drupal에서 왔습니다. 따라서 활성 상태 및 활성 트레일 상태 설정은 경로 (메뉴 렌더링 시스템의 역할도 함)에 의해 처리됩니다.
이제 많은 PHP 프레임 워크에는 라우팅을 처리하는 라우터 클래스가 있습니다. 메뉴가 POST를 인식해서는 안되기 때문에 이것은 분리가 잘되는 것 같습니다 || 옵션 || ... 요청.
그러나 프론트 엔드를 작성할 때 메뉴를 열심히 코딩하는 것을 발견했습니다. 또는 DB에 모든 것을 저장하고 해당 값을 뷰에 전달합니다. 이 접근 방식이 마음에 들지 않는 것은 라우터에 이미 작성한 내용의 사본을 만들고 있지만 Menu 클래스를 사용하고 있다는 것입니다.
예를 들면 :
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'; }모든 견해가 바보처럼 보입니다. 그런 다음 성가신 액티브 트레일을 모두 추가하면 실제 팽창입니다. 뷰가 렌더링되기 전에 처리하고 active-trail 플래그를 true로 설정하면 내가 아는 방식이 너무 추한 것 같습니다 (모든 자식을 반복하는 모든 자식을 반복하는 foreach, ...)
내 질문은 :
이 청소기를 더 좋게 만드는 패턴이나 현명한 방법이 있습니까? ... 액티브 트레일 '문제'를 어떻게 처리해야합니까?
나는 아이-> 부모를 렌더링하려고 생각했습니다. 광고에서 가장 깊은 수준으로 시작한 다음 내 방식대로 작업하십시오. 그러나 그 아이는 부모에 대해 알지만 부모는 그의 아이에 대해 아무것도 알지 못합니다 (이상한 것처럼 보입니다).