メニュー構築パターン
メニューがルーティングに使用されていない場合、メニューのアクティブ状態の処理に頭を悩ませています。 メニューシステムがルーティングも処理するDrupalから来ました。したがって、アクティブ状態とアクティブトレイル状態の設定は、ルートによって処理されます（これはメニューレンダリングシステムとしても機能します）。 現在、多くのPHPフレームワークには、ルーティングを処理するルータークラスがあります。メニューはPOSTを認識してはならないため、これは良い分離のようです|| オプション|| ... リクエスト。 しかし、フロントエンドを書いているとき、メニューをハードコーディングしていることに気づきました。または、すべてをDBに保存し、それらの値をビューに渡します。このアプローチが嫌いなのは、ルーターで既に書き込んだもののコピーを作成しているが、現在はMenuクラスを使用していることです。 例： Route::get('/somewhere','routename.somewhere','showStuffController'); Route::post('/somewhere','routename.somewhere','saveStuffController'); Menu::add('label.somewhere','routename.somewhere'); ここで懸念を分離しているので、それは素晴らしいことです。しかし、MenuはRouteに大きく依存して、アクティブ状態を設定します。メニューは、アクティブトレイルを設定するための階層についても知る必要があります。 つまり、アクティブなトレイルとアクティブなステータスクラスを設定することは、実際にはビューのことです。しかし、 if ( Route::currentName() === $menuitem->getRouteName() ) { print 'active'; } あなたの意見の至る所で愚かに思えます。次に、迷惑なアクティブトレイルをすべて追加します。ビューがレンダリングされる前にそれを処理し、active-trailフラグをtrueに設定することは、私が知っている方法では非常に醜いようです（すべての子をループするforeachループ、...） 私の質問は： このよりきれいな、より良い、...を得るパターンまたはスマートな方法はありますか？アクティブトレイルの「問題」をどのように処理する必要がありますか？ 子->親のレンダリングを考えていました。したがって、最も深いレベルの広告から始めて、次の段階に進みます。しかし、子供はその親について知っていますが、親は自分の子供については何も知りません（変なようです）。