Con los proyectos conjuntos de SURFORCE-BASE, SURFORCE-LIBRARY y SURFORCE-MODULES se buscó tener de alguna forma una "arquitectura" común para aprovechar en cada nuevo proyecto. Evolucionando la idea original, SURFORCE-CORE sustituye a SURFORCE-BASE, este último funcionaba como un template que permitía usarlo como "base" pero luego lo modificábamos y tendríamos uno distinto para cada nuevo proyecto.
Ahora, con "CORE", la idea es usar siempre el mismo, como una aplicación que irá mejorando, y que tendrá todas las funcionalidades básicas para sistemas simples y repetitivos, como CMS o Admin's, y que posteriormente se diferenciarán no en el CORE (que es el mismo), sino, en su configuración y en sus módulos.
Esta primera versión resuelve varios problemas que surgieron durante el desarrollo de distintos proyectos:
- A diferencia de BASE, que todo partía de la raíz del proyecto, ahora el "document root" para el servidor Apache es solo el directorio "html" y el resto de la aplicación queda oculto en un nivel no accesible desde el exterior (seguridad, configuración sugerida por Zend).
- El CORE puede ser igual, pero los módulos deben poder ser dinámicos: generalmente todos los bootstrap (index.php) de sistemas ZF incluyen varias líneas "a fuego" donde se especifica la ruta donde encontrar los controllers para cada módulo. Esto fue sustituido por una carga dinámica donde obtiene la lista de módulos a partir del config.ini (archivo que será siempre distinto según el proyecto).
- Diferenciación de ambientes Desarrollo / Producción: como bien supo enseñarnos sistemas como Ruby On Rails, ahora se crean por lo menos dos ambientes, uno de desarrollo y otro de producción, con distintas configuraciones de bases de datos y distintos niveles de mensajes de error (por ejemplo, en producción no se envían a pantalla mensajes de error).
- Mayor configuración a partir del config.ini: definición de flags como debug (para habilitar rutinas de mayor detalle en los logs), ambiente de desarrollo (poder diferenciar distintas bases de datos), id de aplicación (poder contar con una única tabla de menú para posibilitar un menú dinámico a partir del id de aplicación), módulo de arranque por defecto, timezone, etc.
- El módulo "default" contendrá toda la información común para todos los proyectos: el layout por defecto, models genéricos (como el manejo de usuarios de la aplicación, etc), login a la aplicación, administración de los usuarios, etc.
- Carga dinámica de porciones de css y javascripts por controller: en la práctica me he dado cuenta que uno o más javascripts para todo el sitio era -en la mayoría de los casos- poco flexible (principalmente trabajando en un equipo de varios desarrolladores). Por consiguiente se agregó la posibilidad que por cada controller el layout busque un archivo con el mismo nombre del controller en ejecución pero con extensión .js y/o .css, permitiendo trabajar más libres de tener que mantener una nomenclatura común para absolutamente todo el sitio y estar cargando con funciones o estética que solo se aplican en controllers específicos (evitar que se repitan nombres de funciones, id's, etc).
- Se agregan cuadros de mensajes genéricos para el sistema: lo cual permiten enviar al usuario mensajes de información, alertas, etc, con un simple div, que a su vez se puede animar con jQuery para poder capturar la atención del usuario.
En resumen
Creo que se ha hecho un avance interesante que puede beneficiarnos a todos, tener una estructura genérica que resuelva los problemas comunes que encontramos a la hora de crear aplicaciones muy similares, y con simple configuración o creación de módulos poder cambiar su comportamiento y ser más productivos.
Destaco lo "simple", sin entrar en grandes extensiones complejas de código, con un poco de creatividad bien aplicada se pueden obtener beneficios sustanciales en la productividad de un equipo de trabajo.
En los próximos días iré agregando más información y tal vez hasta un screencasts contando un ejemplo completo de instalación y prueba.
PD: están todos invitados a participar en el foro de discusión y colaborar con su desarrollo.
12 comentarios:
Enrique,
los scripts para el core *.sql de la database "surforcecore" no estan subido al svn, no?
Que tal Socendani ;-)
Noup, aún no está la base de datos, en un rato la estoy subiendo.
La idea es que tenga la estructura para contener a los usuarios, aplicaciones y menús para las mismas.
A partir de ahí tengo que probar que todo funcione y avisarles.
Por ahora sirve para ver y entender la idea de "arquitectura", el código de carga en el bootstrap, config.ini y layout's (a grandes rasgos).
Dame un rato que ya subo lo que falta.
Estimado Socendani:
Listo, ahora es funcional:
- estuctura de la base de datos
- loguea y desloguea
- y menú dinámico
Listo para ser usado, solo tendrías que crearte un módulo nuevo, heredar de Zsurforce_ControllerAdmin para estar dentro del login o Zsurforce_Controller solo si es un módulo público.
De esta forma ya puedes aprovechar lo hecho en el Core, solo deberás agregar en el config.ini el nuevo módulo.
Todos los comentarios bienvenidos ;-)
Hola!
Vengo siguiendo tu blog hace un par de meses, ya que también soy desarrollador PHP... y quiero llegar a ser senior sin morir en el intento.
Leyendo muy por encima tu post, se me antojo SURFORCE muy parecido a symfony. Distintos entornos, ficheros para las configs... se basan en algo parecido?
Muy bueno el blog, por cierto.
Saludos.
Que tal Mr. Ed.:
> Vengo siguiendo tu blog hace un
> par de meses, ya que también soy
> desarrollador PHP... y quiero
> llegar a ser senior sin morir en
> el intento.
Es un trabajo de todos los días ;-)
> Leyendo muy por encima tu post,
> se me antojo SURFORCE muy
> parecido a symfony. Distintos
> entornos, ficheros para las
> configs... se basan en algo
> parecido?
La verdad que no, en sí "CORE" no es un Framework, el framework es Zend pero lo que estamos armando es el corazón de una arquitectura, un "motor genérico" para un proyecto con las funcionalidades típicas que tendrás que hacer en cualquier aplicación que inicies: zona pública, privada, usuarios, permisos, etc. Lo vamos a implementar una vez, de forma genérica, y luego lo podremos usar entre varios proyectos (esto es algo que ya estoy aplicando actualmente con el código existente).
Esta es una de las ventajas de Zend, nos brinda los componentes base y luego podemos contruir algo de más alto nivel sin estar atados a una filosofía estricta de trabajo.
La idea es aprovechar otras experiencias para implementarlas. No conozco Symfony más allá de los manuales, parte de las configuraciones que nombras recuerdo haberlas visto en RoR, otras, como la carga de los módulos de Zend a partir del config simplemente fue jugando un rato con el código hasta que nos dimos cuenta que se podía hacer ;-)
Toda idea o colaboración, bienvenida, es otro proyecto libre y ya existe un foro para participar.
> Muy bueno el blog, por cierto.
Gracias, si es útil, más me reconforta ;-)
Hola Enrique.
ok. updating y funcionando..
bueno, intento ir siguiendo aunque muy lentamente (2 criaturas muy pequeñas en casa dejan poco tiempo libre)
lo del BootStrap es un poco la idea esta?
bootstrap de zsamer
no acabo de ver el por qué del set_include_path, sobretodo por qué default/models ¿?
y para que sirve "Zend_Session_Namespace"? no lo acabo de ver...
con los Layouts me pierdo ¿cómo se cambia de layout?.. la verdad es que es complicado, que hay de aquello del kiss?
bueno.. seguiré mirando.. un gran trabajo kike, como siempre :-)
Estimado Socendani:
> bueno, intento ir siguiendo
> aunque muy lentamente (2
> criaturas muy pequeñas en
> casa dejan poco
> tiempo libre)
Bueno, estás contando la historia de mi vida, dos nenas de 3 y 5 años (una de ellas del estilo Lara Croft, perfiere los Power Rangers que las muñecas). ;-)
Trato hacer todo cuando ellas duermen, así que soy emprendedor-noctámbulo ;-)
> lo del BootStrap es un poco la
> idea esta? bootstrap de zsamer
El "bootstrap" es el index.php de una aplicación Zend, donde defines todo lo que necesita para arrancar, ya que es un diseño "modular", la aplicación a pesar que responder por varias url's, siempre es redireccionada hacia index.php.
En muchos ejemplos verás que todo está en index.php, lo único que hice fue crear una clase para ordenar un poco el código y que fuera más entendible cada paso.
> no acabo de ver el por qué del
> set_include_path, sobretodo por
> qué default/models ¿?
Sirve para agregar en tu path las rutas donde buscar por defecto tus componentes, como ser, la libería Zend (no necesitas poner toda la ruta completa para acceder a ella).
El módulo Default servirá para agregar todo lo común y habitual del sistema, en el caso de "models", podrá ser el modelo Usuario para manejo de todo lo que tenga que ver con ellos y el sistema.
> y para que sirve
> "Zend_Session_Namespace"? no lo
> acabo de ver...
Simplemente crear una sesión en PHP pero a través de una clase que ofrece más funcionalidad que session_start('nombredesession');
En la configuración decides si siempre que levante la aplicación lo hace con sesión (generalmente si haces sistemas de admin's que requieren login de usuarios).
> con los Layouts me pierdo ¿cómo
> se cambia de layout?.. la verdad
> es que es complicado, que hay de
> aquello del kiss?
Por defecto el sistema usa Default/layouts/mail.phtml. Imagínalo como un template que te da la estructura de tu sitio. Posteriormente por cada módulo podrás cambiarlo según tus necesidades.
No es tan complejo, solo requiere leer un poco de conceptos, MVC, Zend y particularmente la idea de los Layouts.
> bueno.. seguiré mirando.. un
> gran trabajo kike, como siempre
> :-)
Gracias, espero que antes del fin de semana estar armando un poco más de documentación.
Saludos!
Hola enrique, ya estas en brasil?
bueno mi comentario es si tenes pensado armar alguna documentacion como las que usabas en tus cursos que estaban muy buenas.
Si bien la mayoria de la gente que visita tu blog es senior o super senior jaja, estaria bueno tener una documentacion con ejemplos, y demas del proyecto para la gente que nos estamos iniciando en el mundo de los FW
un abrazo
Siempre es una buena noticia que salgan adelante proyectos como éste que intentan hacernos la vida más fácil.
Por mi parte, estoy implementando un framework en PHP basado en componentes, pronto saldrá a la luz, ya te avisaré por correo, me gustaría mucho tu opinión. El framework que estoy escribiendo se basa en el mismo principio que el tuyo, no repetir lo que siempre hay que repetir mil veces.
Os mantendré informados, jeje, hasta otra!!!
Enrique me pasas el foro para participar!
SaluDOS! Pac-Man
Estimado Pac-Man:
Ya agregué en el sitio de Code Google el foro:
http://groups.google.com/group/surforce-core
Gracias Enrique,
De donde bajo los archivos para poder probar los surforce ....,
Puede ser posible algun ejemplo, tutorial, etc de implementación, para cuando puedas ?
SaluDOS coordiales!
Publicar un comentario