Tag codeigniter - Userlinux.net

Es algo que todavía no llego a entender ni asimilar. He pasado la mayor parte de la tarde para configurar la nueva versión 2.0 de CodeIgniter-Reactor con varias librerías que, para mi forma de desarrollar, son indispensables en cualquier framework de programación orientado a web:

• HMVC: Gracias a la librería de Wiredesignz podemos ordenar nuestro código en módulos y simplificar la lógica de la aplicación.
• ModulesModule: Ahora que todo será un módulo, no vendría mal un módulo encargado de ejecutar las tareas más comunes de los módulos (instalar, desinstalar, actualizar...). Un módulo de módulos.
• SettingsModule: No me gusta cargar la configuración desde ficheros config/*, por comodidad y para que el usuario pueda cambiar cualquier parámetro ajustable de una aplicación, prefiero hacerlo en base de datos y cachearlo a disco si es necesario. Me quedo con la librería de PyroCMS.
• ThemesModule: Otra característica imprescindible sería tener una aplicación themeable y que desde un interfaz de administración se pueda cambiar tranquilamente el aspecto de la misma. Para ello podemos hacer uso de este módulo capaz de instalar y desinstalar themes.
• TemplateLibrary y TagsLibrary: Una vez hemos decidido hacer la aplicación modular y themeable siguiendo el patrón MVC, un buen lenguaje de template para que los diseñadores no se vuelvan locos con el lenguaje dinámico sería un punto más.
• MigrationsLibrary: Una vez lo pruebas se convierte en musthave. Se trata de una librería para hacer migraciones de versiones en base de datos. Gestiona los cambios entre versiones de forma sencilla.

A mi modo de ver los esquemas organizativos MVC -junto con muchos otros factores- han cambiado a mejor la organización y estructuración del código fuente de un proyecto. Separar en capas las distintas partes de un trabajo (datos, lógica y vista) se antoja un proceso crítico, laborioso pero divertido a la vez.

Por otro lado a veces nos encontramos con situaciones en las que el MVC se convierte en un híbrido entre lo que es y lo que debería haber sido, en este punto hay una clara diferencia entre los desarrolladores que optan por la rama práctica y los que bajo ningún concepto intentan mezclar capas.

Durante el último medio año, desde que CodeIgniter 2.0 ha visto publicada su versión de desarrollo en BitBucket la pregunta de "¿cuándo será estable?" ha rondado sobre los usuarios de este framework. La verdad es que CodeIgniter 2.0 es estable desde hace unos meses. Alguien desde EllisLab (la empresa que se encarga de su desarrollo) pudo haber congelado ya la versión 2.0 (hg tag v2.0; hg push) pero todavía no se han decidido.

CodeIgniter 2.0 es una nueva release, lo que significa una ocasión perfecta para EllisLab en lo que se refiere a cambios "mayores" que puedan afectar a la compatibilidad hacia atrás. Un ejemplo de esto son los nuevos Models, que ahora necesitan extender la clase CI_Model en vez de la antigua Model. Es un cambio más que aceptable para una nueva release y es normal que se piensen las cosas dos veces antes de lanzarse.

No es aconsejable su uso puesto que los parámetros $_GET son un foco de problemas pero hay veces que la fuerza puede más que la razón. CodeIgniter los trae deshabilitados por defecto pero se pueden activar de forma muy sencilla. En nuestro config ponemos el uri_protocol como PATH_INFO:

$config['uri_protocol'] = "PATH_INFO";

Y cada vez que queramos tirar de ellos, en el controlador correspondiente tan solo tendremos que hacer algo tal que así:

parse_str($_SERVER['QUERY_STRING'],$_GET);

De esta forma minimizamos el riesgo al controlador donde queramos usar este tipo de parámetros. Así de sencillo y sin condensadores de fluzo ni cosas raras.

Desde la época de CakePHP no había vuelto a probar otro framework de desarrollo libre -en serio-. Este último mes he empezado un par de pequeños proyectos con CodeIgniter, más que por los proyectos en sí, por ver cómo se desenvuelve el fw según mis necesidades y valorar su futuro uso.

Como primera valoración me está gustando, fácil de configurar e instalar, con una curva de aprendizaje exponencial -como la mayoría- y muy estructurado en cuanto a código y esqueleto de aplicación, MVC estricto, sin parámetros GET por defecto -seguro-, no hay que usar la consola...

Aunque hay otras cosas que no acabo de ver como por ejemplo el uso de la librería form_validation() con varios formularios en el mismo script, pero imagino que será cuestión de buscar un poco más.

Seguro que surgen más problemas según vaya profundizando en el desarrollo, porque de buenas a primeras he de decir que compensa seguir profundizando. Como primera toma de contacto -y viniendo de un $don_nadie como yo- voy a tener la osadía de otorgarle un notable (pero alto).