Wzór budowania menu

Mam problem z obejściem obsługi menu w stanie aktywnym, gdy menu nie jest używane do routingu.

Pochodzę z Drupal, gdzie system menu obsługuje również routing. więc ustawianie stanu aktywnego i stanu aktywnego szlaku jest obsługiwane przez trasę (która działa również jako system renderowania menu).

Teraz wiele frameworków PHP ma klasy routerów, które obsługują routing. To wydaje się być dobrym rozwiązaniem, ponieważ menu nie powinno być świadome testu POST || OPCJE || ... prośby.

Ale pisząc frontend, mocno zakodowałem menu. Lub przechowywanie wszystkiego w bazie danych i przekazywanie tych wartości do widoku. Nie podoba mi się to podejście, ponieważ tworzysz kopię tego, co już napisałeś w routerze, ale teraz używasz klasy Menu.

Przykład:

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

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

Rozdzielasz tutaj obawy, więc to miłe. Ale Menu w dużym stopniu zależy od trasy, aby ustawić stan aktywny. Menu będzie musiało również wiedzieć o hierarchii, aby ustawić aktywny ślad.

Tak więc, ustawienie aktywnej ścieżki i aktywnych klas statusu jest w rzeczywistości sprawą widoku. Ale mając

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

wszystkie twoje poglądy wydają się głupie. Następnie dodaj wszystkie te irytujące szlaki aktywne, jeśli to jest prawdziwy wzdęcie. Radzenie sobie z tym, zanim widok zostanie zrenderowany, a ustawienie flagi aktywnego szlaku na prawdę wydaje się tak brzydkie, jak to wiem (foreach zapętla wszystkie dzieci, które przewijają się nad wszystkimi dziećmi ...)

Moje pytanie brzmi:

Czy istnieje wzór lub sprytny sposób na uzyskanie tego czystszego, lepszego, ...? Jak należy poradzić sobie z „problemem” aktywnego szlaku?

Myślałem o renderowaniu dziecka -> rodzica. Więc zacznij od reklamy na najgłębszym poziomie, a potem idź w górę. Ale wtedy dziecko wie o swoim rodzicu, ale rodzic nic nie wie o swoich dzieciach (wydaje się dziwny).

gdy menu nie jest używane do routingu

Powiedziałbym, że dla menu można użyć routingu .

Jak już wskazałeś, router byłby fajnym miejscem do podłączenia. Nie sądzę, że byłoby brzydkie użycie haka, który ocenia meta menu dla bieżącej strony przy każdym żądaniu.

Jeśli uczynisz swoje poglądy odpowiedzialnymi za śledzenie stanu aktywnego, nie rozdzielisz obaw. Widoki powinny robić wszystko, do czego zostały stworzone - ale nie jest konieczne, aby zarządzały także stanem menu. Metadane menu są zwykle takie same dla całej aplikacji i potrzebujesz jedynie trasy, aby móc się zlokalizować i wyświetlić menu.

W zależności od routera i twoich potrzeb prosta funkcja lub klasa, która pobiera statyczne metadane z menu, a bieżąca trasa wystarczyłaby, aby dostarczyć wszystkie potrzebne informacje.

Sama meta menu niekoniecznie musi być obiektem. Prosta struktura danych kluczowych wartości bez metod powinna w większości przypadków wystarczyć.

Hak może utworzyć obiekt stanu z niektórymi typowymi funkcjami związanymi z twoim menu, takimi jak bułka tarta, głębokość, strona nadrzędna lub bieżąca strona i sprawić, że ten obiekt będzie znany w kontekście twojego żądania http. Wewnątrz haka masz różne możliwości - ale ogólnie chodzi o gromadzenie, przygotowywanie i przekazywanie niezbędnych danych do czegoś, co wie, jak sobie z tym poradzić.

To podejście dostosowuje się do twoich potrzeb i ma kilka zalet:

1. Twoja baza danych nie musi zajmować się danymi, które możesz zapewnić w czasie wykonywania przy niskich kosztach
2. Będziesz mieć swoje menu (meta) w jednym miejscu, co sprawia, że ​​można je utrzymać
3. Jeśli chcesz, aby Twoje menu całkowicie opierało się na trasach w stosunku 1: 1, możesz to osiągnąć poprzez dynamiczne udostępnianie menu
4. Jeśli twoja treść rośnie (a zatem i menu), możesz przenieść te dane do sesji, które mogą zostać zapisane w szybkim magazynie wartości kluczowych