Patrón de construcción del menú


9

Tengo problemas para entender el manejo del estado activo de un menú cuando el menú no se utiliza para el enrutamiento.

Vengo de Drupal, donde el sistema de menús también maneja el enrutamiento. Por lo tanto, la ruta maneja el estado activo y el estado de ruta activa (que también actúa como un sistema de representación de menú).

Ahora, muchos frameworks PHP tienen clases de enrutador que manejan el enrutamiento. Esto parece una buena separación ya que un Menú no debe estar al tanto de POST || OPCIONES || ... peticiones.

Pero al escribir el frontend, me encontré codificando el menú. O almacenar todo en la base de datos y pasar esos valores a una vista. Lo que no me gusta de este enfoque es que estás creando una copia de lo que ya escribiste en tu enrutador pero ahora estás usando la clase Menú.

Un ejemplo:

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

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

Estás separando las preocupaciones aquí, así que eso es bueno. Pero el menú depende en gran medida de la ruta para establecer su estado activo. El menú también tendrá que saber acerca de la jerarquía para establecer el seguimiento activo.

Entonces, sí, establecer rutas activas y clases de estado activo es realmente una cuestión de visualización. Pero teniendo

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

todo sobre tus puntos de vista parece estúpido. A continuación, agregue todos esos molestos si-senderos activos y es una verdadera hinchazón. Manejar eso antes de que la vista se muestre y establecer un indicador de ruta activa en verdadero parece tan feo como lo sé (un foreach que recorre a todos los niños que recorre a todos los niños, ...)

Mi pregunta es:

¿Existe un patrón o una forma inteligente de obtener este limpiador, mejor, ...? ¿Cómo se debe manejar el 'problema' del camino activo?

Estaba pensando en hacer niño -> padre. Así que comience con el anuncio al nivel más profundo y luego vaya ascendiendo. Pero entonces el niño sabe acerca de su padre, pero el padre no sabe nada acerca de sus hijos (parece extraño).

Respuestas:


1

cuando el menú no se usa para enrutar

Yo diría que el enrutamiento se puede usar para el menú.


Como ya señaló, el enrutador sería un buen lugar para conectarse. No creo que sea feo usar un enlace que evalúe el meta menú para la página actual en cada solicitud.

Si hace que sus puntos de vista sean responsables del seguimiento del estado activo, no separe las preocupaciones. Las vistas deben hacer lo que sea que estén hechas, pero no es necesario que también administren su estado de menú. Los metadatos del menú suelen ser iguales para toda la aplicación y solo necesita la ruta para poder ubicarse y representar el menú.

Dependiendo de su enrutador y sus necesidades, una función o clase simple que tome algunos metadatos del menú estático y la ruta actual sería suficiente para proporcionar toda la información que necesita después.

El menú meta en sí no necesariamente debe ser un objeto. Una estructura de datos de valor clave simple sin métodos debería ser suficiente en la mayoría de los casos.

El enlace puede crear un objeto de estado con algunas funcionalidades comunes relacionadas con su menú, como migas de pan, profundidad, página principal o página actual y dar a conocer este objeto en el contexto de su solicitud http. Tiene diferentes posibilidades dentro del gancho, pero generalmente se trata de recopilar, preparar y pasar los datos necesarios a algo que sepa cómo manejarlo.

Este enfoque se adapta a sus necesidades y tiene algunas ventajas:

  1. Su base de datos no necesita tratar con datos, que puede proporcionar en tiempo de ejecución con bajos costos
  2. Tendrás tu menú (meta) en un lugar que lo hace mantenible
  3. Si desea que su menú confíe completamente 1: 1 en sus rutas, puede lograrlo proporcionando meta menú dinámicamente
  4. Si su contenido crece (y, por lo tanto, el menú), puede mover estos datos a la sesión, que podrían escribirse en un almacén de valores de clave rápida
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.