Шаблон меню

У меня возникают проблемы с обработкой меню в активном состоянии, когда оно не используется для маршрутизации.

Я из Друпала, где система меню также обрабатывает маршрутизацию. поэтому установка активного состояния и состояния активного маршрута обрабатывается маршрутом (который также действует как система рендеринга меню).

Сейчас многие PHP-фреймворки имеют классы Router, которые обрабатывают маршрутизацию. Это кажется хорошим разделением, так как Меню не должно знать о POST || ВАРИАНТЫ || ... Запросы.

Но когда я писал интерфейс, мне было трудно кодировать меню. Или хранить все в БД и передавать эти значения в представление. Что мне не нравится в этом подходе, так это то, что вы как бы создаете копию того, что вы уже написали в своем маршрутизаторе, но теперь используете класс Menu.

Пример:

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

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

Вы разделяете проблемы здесь, так что это хорошо. Но меню сильно зависит от маршрута, чтобы установить его активное состояние. Меню также должно знать об иерархии, чтобы установить active-trail.

Так что да, настройка активного следа и классов активного состояния на самом деле вещь для просмотра. Но имея

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

все ваши взгляды кажутся глупыми. Затем добавьте все эти надоедливые активные-следы, если это - и это настоящий раздув. Обработка этого до того, как представление получает рендеринг, и установка флага active-trail в true, кажется мне таким уродливым, как я это знаю (цикл foreach, охватывающий все дочерние элементы, который циклически обрабатывает все дочерние элементы, ...)

Мой вопрос:

Есть ли шаблон или умный способ сделать это чище, лучше, ...? Как справиться с проблемой активного маршрута?

Я думал о рендеринге ребенка -> родитель. Так что начните с рекламы самого глубокого уровня, а затем двигайтесь вверх. Но потом ребенок знает о своем родителе, а родитель ничего не знает о своих детях (кажется странным).

когда меню не используется для маршрутизации

Я хотел бы сказать , что маршрутизация может быть использована для меню.

Как вы уже указали, маршрутизатор был бы хорошим местом для подключения. Я не думаю, что было бы некрасиво использовать хук, который оценивает мета меню для текущей страницы при каждом запросе.

Если вы делаете свои взгляды ответственными за отслеживание активного состояния, вы не разделяете проблемы. Представления должны делать все, для чего они созданы, но не обязательно, чтобы они также управляли состоянием своего меню. Метаданные меню обычно одинаковы для всего приложения, и вам нужен только маршрут, чтобы найти себя и отобразить меню.

В зависимости от вашего маршрутизатора и ваших потребностей, простая функция или класс, который принимает некоторые метаданные статического меню и текущий маршрут, будет достаточным для предоставления всей необходимой вам информации впоследствии.

Сама мета меню не обязательно должна быть объектом. В большинстве случаев достаточно простой структуры данных значения ключа без методов.

Хук может создать объект состояния с некоторыми общими функциями, связанными с вашим меню, такими как хлебные крошки, глубина, родительская страница или текущая страница, и сделать этот объект известным в контексте вашего http-запроса. У вас есть разные возможности внутри хука - но обычно речь идет о сборе, подготовке и передаче необходимых данных кому-то, кто знает, как с этим справиться.

Этот подход соответствует вашим потребностям и имеет несколько преимуществ:

1. Ваша база данных не должна иметь дело с данными, которые вы можете предоставить во время выполнения с низкими затратами
2. Вы будете иметь свое меню (мета) в одном месте, что делает его легко обслуживаемым
3. Если вы хотите, чтобы ваше меню полностью зависело от маршрутов 1: 1, этого можно добиться, предоставляя мета-меню динамически
4. Если ваш контент растет (и, следовательно, меню), вы можете переместить эти данные в сеанс, который может быть записан в хранилище значений быстрого ключа