5

Estoy trabajando en una revisión de una aplicación de CakePHP que construí con CakePHP 1.2. Me actualicé a 1.3 y estoy considerando alejarme del paradigma de enrutamiento de administrador para mi aplicación. Estoy descubriendo que algunos de mis controladores se están volviendo extremadamente grandes debido a las funciones duplicadas para la interfaz y el administrador. Mi intuición es que es mucho más limpio crear un conjunto de controladores de administración y soltar el enrutamiento de administrador todos juntos, pero quería obtener información sobre lo que otros están haciendo y qué funcionalidad, si es que hay alguna, me voy a perder. dejando caer el enrutamiento.Mejores prácticas de CakePHP: administrador con o sin enrutamiento

¿Cuáles son las mejores prácticas consideradas para una aplicación CakePHP robusta (u otra estructura MVC) en este sentido?

+0

he conseguido dos sugerencias para dejar la ruta, lo cual me inclino a hacer, pero tan pronto como empecé a probar esto, siento que choco contra una pared de ladrillos. En una aplicación no estructurada, simplemente crearía un nuevo directorio "admin" y pondría todos mis controladores específicos de administrador allí, muchos de los cuales tendrían el mismo nombre que los controladores front-end y, por lo tanto, se accedería a ellos: "/ admin/usuarios/agregar ". No encuentro ninguna forma de hacer algo similar con Cake. ¿Es mi única opción/admin_users/add? – seth

Respuesta

0

No se moleste con el enrutamiento de administrador si no se ajusta a su situación. Tampoco lo estoy usando, las rutas de administrador no se ajustan a mi aplicación. El código de duplicación es un desperdicio de esfuerzo.

Puede usar las reglas de ACL para roles finos, o simplemente verificar el rol (indicador de administración) en beforeFilter() del controlador o en la primera línea de una acción.

Tengo una función Componente checkRole (array()), que se llama en la primera línea de mis acciones. Si el usuario actual no tiene las funciones proporcionadas, registra y finaliza la solicitud.

0

Pondría en segundo lugar el uso de ACL/roles para cosas reales de administración, y probablemente no use enrutamiento de administración en producción. A veces conservo un enrutamiento de administrador andamiado (con un código adicional mínimo) para cosas de administración de bajo nivel, accesible solo para mí, pero probablemente no sea lo mejor en una aplicación de producción robusta.

Editar después del comentario: No es óptimo, pero es posible que pueda juntar algo que aparecerá como desee en las URL, y también se organizará en carpetas. No he podido probarlo todavía, pero esta es la idea:

Cree una carpeta "admin" en su carpeta de controladores y para el administrador de usuarios, cree un archivo de controlador users_admin_controller.php. Contraen la estructura de la carpeta, por lo que aún no puede tener los mismos nombres que su directorio raíz, pero aún puede separarlos en una carpeta.

Esta voluntad por defecto hacer una situación /admin_users/add tipo, pero que puede ser ajustado con la segunda parte, algunos de enrutamiento:

Router::connect('/admin/users/:action', array('controller'=>'admin_users')) 

Esto tendría que hacerse para cada sección de administración - no es ideal, pero no se puede encontrar una mejor manera sin modificar el código de Cake.

+0

Entonces, ¿cómo se ven las URL de la sección de administrador? Siento que esto sería una obviedad, excepto que no hay una buena manera de colocar controladores en subdirectorios a los que se accede a través de/subdir/control/action (por ejemplo,/admin/users/add). ¿Acabas de nombrar todos tus controladores de administrador con "admin" antes (por ejemplo,/admin_users/add)? – seth

+0

Si usa ACL/roles, solo hay páginas/acciones que solo son accesibles para los administradores o que tienen una funcionalidad adicional con los administradores. Pero lo que creo que estás preguntando es al usar el andamio, o con las secciones de administración. Allí, puede usar "enrutamiento de administrador" para tener los admin/users/add como desee. Consulte el manual de CakePHP: http://book.cakephp.org/view/46/Routes-Configuration#Prefix-Routing-544 Con eso, solo tiene una función 'admin_add' en su controlador de usuario, al que se accede a través de '/ admin/users/add', y luego una función' add' normal a la que se accede a través de '/ users/add'. – cincodenada

+0

Entiendo completamente (y he implementado) ACL/Roles y no estoy usando andamios. Solo tengo muchos controladores frontales/administrativos que serían iguales. Me gustaría poner los controladores de administración en un subdirectorio "/ admin" y hacer que las URL parezcan "/ admin" sin usar prefijos. – seth

0

He usado ACL para mi aplicación y me parece mucho mejor que usar enrutamiento de administrador. Es mucho más fácil. Si realmente quieres un prefijo, puedes hacerlo con un enrutamiento normal.

+0

Terminé usando el prefijo ACL + (que en realidad no es un cambio desde mi implementación original). Todavía estoy bastante molesto por cómo Cake maneja las estructuras de directorios y los nombres de archivos y enlaces. Sería ideal si un controlador estuviera en un directorio "admin" que se convertiría en parte de la ruta de la url. – seth

1

Sugeriría que simplemente separe la aplicación de front-end y el administrador en dos aplicaciones separadas (/app y /admin). Solo piense en admin como una aplicación de front-end simple, haciendo todo el trabajo "sucio" con la base de datos.

Al hacerlo, podrá acceder a su administrador con el prefijo/admin en la URL o establecer DocumentRoot a/admin/webroot y acceder a admin utilizando el subdominio (es decir, admin.myapp.com).

Para evitar la duplicación de código del modelo, se puede poner sus modelos en alguna carpeta compartida (es decir /vendors/core/models) y añadir este camino para modelar caminos en bootstrap.php archivos (App::build('models' => array(VENDORS . 'core/models/')) para CakePHP 1.3, $modelPaths = array(VENDORS . 'core/models/') para CakePHP 1.2).

Para añadir más admin o cosas específicas aplicación a los modelos, se podía extender los modelos básicos en/modelos, mediante la carga de modelo básico, y se amplía:

App::import('Model', 'CoreModelName'); 

class CustomCoreModelA extends CoreModelA 
{ 
    function specificMethod() {} 
} 

que se podrían hacer para los componentes compartidos, comportamientos , etc.

+1

sobre el uso de dos aplicaciones, estaría de acuerdo y es algo que tengo en mente. pero poner modelos en los vendedores es un hack feo. en su lugar, use APP :: build en la aplicación para señalar los archivos de modelo en otra aplicación. hay problemas con esto especialmente cuando se trata de complementos. muy lento buscando en tantos directorios. – dogmatic69

+0

Tienes razón, poner modelos compartidos en/vendors es feo y hacky, usar otros directorios de modelos de aplicaciones para buscar modelos suena mejor. El único problema es la falta de espacios de nombres, de esa manera tendría que ponerle un prefijo a todos sus modelos de administrador. ¿Qué hay del rendimiento? Bueno, debes elegir entre tener una arquitectura limpia y fácil de mantener o una aplicación increíblemente rápida, pero con muchos inconvenientes arquitectónicos. – ljank

1

he creado aplicaciones con enrutamiento de administrador y no, y la versión no es siempre un desastre. si algunos de sus métodos son los mismos, puede hacer lo siguiente.

function add(){ 
$this->_add(); 
} 

function admin_add(){ 
$this->_add(); 
} 

function _add(){ 
... your code ... 
} 

podría apostar que no es todo el código que es el mismo, y no usar de administración de enrutamiento que va a terminar con una gran cantidad de código haciendo if(... is admin ...) { echo 'blaa'} else { echo 'foo'; }