¿Que opinan de este componente para yii 2?

eh estado trabajando en un pequeño componente para yii 2, una forma diferente de trabajar con el AccessControl::class que se usa en el behaviors de todos los controladores.

  1. primera versión
    En la primer versión simplemente se agregaba un array donde el indice era el nombre de tu controlador la cual adentro de ese indice tenia un itemclass la cual pide el nombre de tu controlador y el segundo item excepcion pedía una array donde se agregaban las acciones que no se requerían de un inicio de sesión, adjunto una imagen de la primera version

introducir la descripción de la imagen aquí

Figura 1 captura de la primera version

2.Segunda versión en la segunda version cambie varias cosas

  • Primer el indice sigue siendo el nombre del controlador, pero a este puedes agregar mas cosas como la posiblidad de desactivar todo el controlador ya sea que el controlador estan en mantenimiento o simplemente de que esta desactivado,tambien de cambiar el layout de todo el controlador osea el controlador de login tendra un layout en todas sus actions tendran un layout espeficico
  • Segundo que en las actions puedes decir si solo sera de formato json y si este solo se puede acceder mediante ajax asi tambien de desactivar la accion o cambiar su layout, ademas no importaba si no definias esa accion esta siempre necesitaba de logeo o si no solo le especificabas que este no tendra logeo usando excepcion. adjunto imagen

introducir la descripción de la imagen aquí

Figura 2 captura de segunda version

3.Tercera version en esta versión es casi similar a la segunda pero con algunas diferencias como

  • Desactivar tu controlador o tu accion y agregar true o false si lo deseas activar o desactivar y un mensaje de porque esta desactivado asi como agregar una funcion
  • En las acciones y controladores agregar permisos ya sea usando funciones o usando un array pero este array debes agregarlo si tienes definido roles y permisos en tu yii\rbac\Rule
  • En el request puedas definir si la accion solo puedes usar ajax,post,get,put y delete,adjunto la siguiente imagen

introducir la descripción de la imagen aquí

Figura 3 Captura de la tercera version

¿Para los que usan yii que opinan de esto? trato de hacer algo diferente con yii algo que sea mas comodo para mis proyectos osea al crear un controlador o una accion no necesites usar un behaviors porque ya tienes la seguridad de que todo necesita logeo o puedes cambiar algunos apartados a tu gusto. Agradezco su tiempo por leer el post y agredezco sus opiniones acerca de esto

Son 5 am largas y acabo de terminar un proyecto, así que puede que diga muchas tonterías lol.

Viendo lo que muestras de la configuración, parece un componente que ha ido cubriendo lo que has ido necesitando. En mi opinión, lo que intentas tiene sus pros y sus contras, pero creo que hay más contras.

Poder definir el layout y el mantenimiento por acciones individuales es práctico. Te evita $this->layout perdidos por ahí y también ofrece una forma limpia de mostrar mensajes desde el controlador compatible con Yii::t. La configuración por array siempre es elegante.

A la vez, veo cosas que creo que te pueden dar problemas si sigues desarrollando el componente así, y creo que deberías pensar hacia dónde quieres llevar la funcionalidad.

Lo que creo más incómodo es que a nivel de esa funcionalidad, el componente (por cierto que los componentes son helpers de toda la vida pero con inyecciones de dependencias y cosas así) cubre configuraciones de varias partes estándard de una aplicación en un sólo array. Y estás mezclando el control de acceso con view y el request.

Aunque no es que sea un purista de la encapsulación o como se llame, se supone que cada clase debe encargarse de una sola cosa, incluidos los componentes, se supone también.

No sé cómo gestionas luego la configuración, pero lo lógico es que hagas un merge con la configuración parent de cada cosa, pero todo dentro de una misma clase AccessControl extendido.

En teoría teórica, deberías hacer un componente por tarea. Lo cual viene a quedarte como un behaviour o un trait que permita una configuración más sencilla. Esto se hace por varios motivos, pero en general porque los componentes son más pesados en memoria y pueden ralentizar todo en cargas altas y cosas de ese tipo, así que se mantienen para historias más concretas, como listas desplegables, comparar accesos de usuario y demás funciones apasionantes.

Eso de arriba también tiene que ver con el mantenimiento del componente. Empezó como una solución para flexibilizar el control de acceso de la aplicación pero le has ido añadiendo cosas, y eso hace que cada vez sea más pesado si mezclas clases y más difícil de mantener. Quizá deberías plantear la clase como un baseController que haga de puente para las nuevas funcionalidades que quieras agregar, sin estar instanciado eternamente, y que sea más ligero cuando se juega con varias clases a la vez.

Si le añades más funcionalidades, se irá a las miles de líneas cuando se ponga la cosa interesante. Mantener cada cosa en su clase facilita aislar errores y gestionar bugs sin afectar a varias funcionalidades a la vez.

También, al ser un proyecto propio, tarde o temprano añadirás parámetros más específicos y el componente irá siendo cada vez más hecho a tu medida, por lo que perderá uso general.

Si ahora el semidios ruso que supervisa Yii decide que las views se construyen al revés, puede que el componente falle entero por la configuración de una sola parte. y si mezclas las requests, puede que provoque problemas de seguridad.

Fuera de eso, como soy old school, si estoy en php no me fío de javascript y no dejaría un ajax only por ahí, pero es lo que hay hoy en día.

También en el ejemplo de la tercera imagen, donde devuelves una función anónima en el ‘disabled’ dentro de una sección ‘about’. Supongo que tienes que evaluar si la sección se muestra dependiendo de si es false o no, pero una función anónima de guerrilla puede devolver false por lo que sea y que todo haga cosas raras.

Creo que sería mejor poner un bool para enabled y luego poder pasar la configuración en otra propiedad. Pero bueno, eso ya es por decir.

En general, aunque la idea es práctica, creo que al final tendrás que hacer lonchas con las clases. Espero que te sirva, y es sólo mi opinión.