I'm having troubles getting my head around the active-state handling of a menu when the menu isn't used for routing.I come from Drupal where the menu system handles the routing as well. so setting active state and active-trail state is handled by the route (that acts as a menu rendering system as well).Now, a lot of PHP frameworks have Router classes that handle the routing. This seems a good separation since a Menu should not be aware of POST || OPTIONS || ... requests.But when writing the frontend, I found myself hard coding the menu. Or storing everything in the DB and passing those values to a view. What I don't like this approach is that you are kind of creating a copy of what you already wrote in your Router but now using the Menu class. An example:Route::get('/somewhere','routename.somewhere','showStuffController');Route::post('/somewhere','routename.somewhere','saveStuffController');Menu::add('label.somewhere','routename.somewhere');You are separating concerns here, so that is nice. But Menu depends heavily in Route to set its active state. The menu will also have to know about hierarchy to set active-trail.So yes, setting active trail, and active status classes is actually a view thing. But having if ( Route::currentName() === $menuitem->getRouteName() ) { print 'active'; }all over your views seem stupid. Then add all those annoying active-trail if's and it's a real bloat. Handling that before the view gets renders and setting an active-trail flag to true just seems so ugly the way I do it know (a foreach looping over all children that loop over all children, ...)My question is:Is there a pattern or a smart way to get this cleaner, better, ...? How should one handle the active-trail 'problem'?I was thinking of rendering child -> parent. So start with the ad the deepest level and then work my way up. But then the child knows about its parent but the parent knows nothing about his children (seems weird).
Menu building pattern
design patterns;php;trees