Barrapunto

Vaya por delante que no tengo mucha idea, pero estoy buscando un framework PHP con el que jugar. Symfony suena bien, pero buscando por Internet suena mucho CakePHP.

CakePHP está fuertemente inspirado en Ruby On Rails y parece bastante potente; he leído comentarios que achacan a Symfony cierta complejidad (muchos ficheros de configuración y directorios muy poblados).

Por otro lado parece que Symfony viene con Prototype/Scriptacoulus, al igual que CakePHP. Perfecto para quien use dicho framework JavaScript, pero aquellos que preferimos otro (Mootools en mi caso) parece que CakePHP es más fácil de utilizar usando otra libería JavaScript.

En fin, esto es el resultado de un rato de enredar leyendo por Internet, así que puedo estar muy equivocado. Se agradecen opiniones y correcciones.

Resulta que hace muuucho tiempo empecé a crear una metodología estándar para mis aplicaciones con php (porque si te pones con php "a pelo" te salen unas patatas de espanto).

Php no es ni bueno ni malo ... pero la verdad es que "para hacerlo bueno" hay primero que trabajar mucho (o sea, montarte un "framework").

Con el tiempo acabé construyendo mi propio framework que al final tiene ideas similares a otros (no por copiarlas -ni sabía que existían-, sino porque por lo visto al final llegamos todos a soluciones parecidas para problemas parecidos).

Quizá pueda ser de ayuda a los "nuevos" que empiezan con estas cosas, así que aquí os dejo estos "diez mandamientos"

+++++++++++++++++++++++++++++
ESTOS SON LOS DIEZ MANDAMIENTOS DE LO QUE HAY QUE HACER PARA USAR EL PHP "en serio"
++++++++++++++++++++++++++++++
(sólo dejo las "ideas generales" ... porque en realidad el asunto se puede llevar hasta el virtuosismo con tiempo y experiencia acumulada):

1. Separa "visores" (el html) de los "operadores" (el código php de verdad)

2. El "operador" se encargará de recoger parámetros, conectarse a database, y lo mejor es que pongas los datos en un array. Y al terminar llama al "visor" (bastaría con un include). Si eres un poco fino, con el tiempo cambiarás el array por una clase DataView (o como quieras llamarla), que en el fondo es el array+escapes y alguna funcionalidad adicional.

3. El visor debería ser código HTML que como mucho tenga for{..} recorriendo los arrays (ningún otro php aquí) O sea, el único php del visor es un "echo" y algún "for" y punto final.

4. No seáis tontos, y dejaros de gilipolleces de plantillas smarty y similares: el HTML con un mínimo de PHP del tipo (echo $data['titulo']) es la mejor plantilla del universo (y no hace falta poner más capas de software aquí tontamente).

5. Añade un frontend, un punto de entrada forzoso para todo, que distribuya el juego, con una posible comprobación depermisos según módulos (esta idea da para mucho: desde aquí se pueden hacer includes a los operadores y visores, controlar accesos, controles de seguridad centralizados, posibilidad de caché y un huevo de cosas -imposibles de hacer fuera de este enfoque-).

6. Es conveniente que tengas un sistema de identificación de usuarios "estándar" incorporado en todo este tinglado. Puedes hacerlo si todo pasa por el frontend, porque al comprobar la falta de permisos se puede derivar el flujo al "vigilante" para identificar, y luego volver al flujo original (esta idea tan tonta vale millones ...para el que la sepa entender bien)

7. Luego vienen las mejoras. Podrás añadir hasta sistemas de cachés (esto es complejo, porque las cachés deben inutilizarse al cambiar datos de database, lo que requieren clases DbManager que automaticen esas cosas ...) Pronto verás también la necesidad de una clase para lidiar con los formularios (validaciones automáticas, y demás). Una clase History para gestionar los inevitables url-back de muchas páginas también. Y otras cuestiones que te irán surgiendo (y que como mejor se tratan es encapsuladas en sus clases). Una buena clase Session para la persistencia también se te hará pronto necesaria (o sea, reconstruir usuario conectado y datos de session y similar).

8. Divide el código en carpetas que sean "módulos". Un módulo para una cosa, y otra para otra.

9. Separa los visores de los operadores (o sea, separados en carpetas diferentes). De echo, todos los operadores deberían estar en una carpeta, y todos los visores en otra. Si haces esto, descubrirás que se puede tener una aplicación con múltiples interfaces. (y por lo que más quieras: los visores html nunca tienen ningún códi