¿Por qué un nuevo framework?
Temma no es “nuevo”. Se usa desde 2007 en varios cientos de sitios (incluyendo Ooreka, Skriv y Rolis).
El objetivo inicial de Temma es volver a las bases de un framework MVC: acelerar el desarrollo permitiendo a los desarrolladores concentrarse en lo esencial de su trabajo, sin tener que reimplementar lo mismo una y otra vez.
Perder de vista este objetivo, añadiendo funcionalidades innecesarias u obligando al uso de reglas muy estrictas, obligaría a pasar por un aprendizaje largo y una implementación complicada.
Temma ofrece, por tanto, un entorno que permite desarrollar rápidamente tus sitios web, brindando un framework eficiente, sin añadir complejidad innecesaria.
¿Cuál es la historia detrás de Temma?
Temma fue creado en 2007 por Amaury Bouchard, cofundador y director técnico del sitio Ooreka durante 10 años, para los desarrollos realizados internamente en su empresa.
Su objetivo era crear un framework ligero pero totalmente funcional, que facilitara el trabajo de los desarrolladores sin exigir un aprendizaje largo o doloroso, y que permitiera separar claramente el trabajo de desarrollo del de integración HTML/CSS.
Inicialmente, Temma significaba « TEMplate MAnager », lo que ya mostraba que el objetivo principal era facilitar la gestión entre el código de negocio y las plantillas. Desde entonces, el framework se ha desarrollado y ofrece un verdadero entorno MVC.
¿Cuál es la filosofía de Temma?
El objetivo de Temma es proporcionar herramientas fáciles de asimilar, sencillas de usar y eficaces.
No es un framework elitista. Aplica el “PHP way of life”, es decir, un enfoque zen del desarrollo, sin extremismo ni dogmatismo.
Temma no está gestionado por una empresa. Es un proyecto de código abierto impulsado por una asociación sin ánimo de lucro, que no busca generar beneficios. Las decisiones se toman en interés de los usuarios, no por intereses financieros.
¿Cuál es la licencia de Temma?
El código fuente de Temma se publica bajo los términos de la licencia MIT.
Por lo tanto, puedes usar Temma sin limitación en tus desarrollos, sea cual sea su licencia (libre o propietaria).
¿Por qué usar Temma en lugar de frameworks como Symfony, Laravel o Laminas?
Estos frameworks imponen una curva de aprendizaje bastante ardua, obligando a asimilar conceptos que les son propios.
Así, uno se convierte en un desarrollador Symfony (u otro), y ya no en un “desarrollador PHP”.
Y al mismo tiempo, los conceptos simples que deberían ser gestionados por el framework se vuelven innecesariamente complejos (intenta crear plugins con Symfony, tendrás que desarrollar un event listener…).
¿Por qué usar Temma en lugar de micro-frameworks como Silex, Lumen o Slim?
Estos micro-frameworks pueden parecer más sencillos de implementar a primera vista. Pero, al mezclar el enrutamiento y los controladores como lo hacen, hacen que el código sea menos legible, y por tanto más difícil de mantener con el tiempo.
Y para aquellos que se basan en frameworks pesados (Symfony para Silex, Laravel para Lumen), el resto de tu código sigue sufriendo la pesadez subyacente.
¿Por qué Temma no está basado en la última versión de PHP?
Temma se usa en producción en empresas cuyos servidores no siempre pueden seguir el ritmo de lanzamiento de las versiones de PHP.
En consecuencia, hemos elegido seguir siendo compatibles con la versión de PHP proporcionada en la penúltima versión LTS (soporte a largo plazo) de la distribución Linux Ubuntu.
¿Por qué Temma usa Smarty como motor de plantillas?
Smarty es el estándar de facto de los motores de plantillas en PHP.
Presenta varias cualidades:
- Una sintaxis simple y clara, fácilmente asimilable por diseñadores gráficos alejados de la lógica de desarrollo.
- Posibilidades de extensión fáciles de implementar, con la creación de filtros en PHP.
- Un rendimiento que puede ajustarse añadiendo caché en fragmentos de plantillas.
Aunque la crítica hacia Smarty parezca estar de moda entre algunos “pensadores” activos en la comunidad PHP (principalmente aquellos que terminan proponiendo clones de Smarty), no se puede cuestionar su amplia adopción por una mayoría silenciosa de esa misma comunidad.
¿Por qué Temma no genera una interfaz de administración de la base de datos?
Porque será más eficiente usar PhpMyAdmin, PhpPgAdmin, PhpRedisAdmin, Adminer…
No es el papel de un framework ofrecer este tipo de funcionalidad. El papel de un framework es ofrecer las bases técnicas que permiten desarrollar esas herramientas.
¿Por qué Temma no ofrece un ORM?
Los motivos habitualmente invocados para el uso de un ORM son:
- No tener que escribir consultas SQL.
- Manipular únicamente objetos.
- Poder cambiar de base de datos según sea necesario.
Así es como Temma responde a esto:
-
Para consultas sobre una sola tabla, los DAO de Temma no requieren escribir consultas SQL. Para consultas más complejas (uniones, agrupaciones, ...), siempre es más eficiente escribir las consultas "a mano".
Para paliar sus problemas de rendimiento, los ORM proponen lenguajes derivados de SQL (HQL para Hibernate, DQL para Doctrine). Los desarrolladores siempre deben escribir sus consultas, salvo que estas son procesadas por una capa intermedia (con su sintaxis específica y sus lentitudes asociadas).
Sea cual sea el desarrollo realizado, habrá que ir a comprobar en la base de datos si todo se almacena correctamente. Y por lo tanto, habrá que escribir consultas SQL. Un desarrollador web que no sea capaz de hacerlo pronto tendrá problemas.
-
Si la voluntad de manipular únicamente objetos puede entenderse en ciertos entornos, el "PHP way of life" se acomoda muy bien a la transferencia de datos basada en simples listas y arrays asociativos. Es la forma más flexible y rápida de estructurar tus desarrollos en PHP.
Por cierto, se puede observar que incluso los desarrolladores que solo quieren manipular "entidades" (los objetos que representan los datos en la base de datos) usan arrays asociativos cuando se conectan a APIs externas. Sin embargo, se podría pensar que los datos siempre deberían manipularse de la misma manera, sin importar su origen.
-
La verdadera capa de abstracción está constituida por los DAO. El código de negocio que los invoca no tiene que ser modificado, incluso en caso de modificaciones profundas que obliguen a cambiar las consultas presentes en los DAO.
En lugar de usar un ORM existente como Doctrine o basarse en el patrón Active Record, Temma utiliza el patrón Data Access Object (DAO, abreviado). Este es a la vez más eficiente en su ejecución y más simple de emplear.
El uso de los DAO es cristalino:
- Para recuperar los datos de un registro en una tabla, se llama a un método del DAO. Se obtiene un array asociativo, que ofrece una clave para cada campo de la tabla.
- Cuando se recuperan varios registros de una tabla, se obtiene una lista de arrays asociativos. Se puede iterar sobre ella con todas las funciones nativas de PHP como foreach. Es simple, claro, eficiente.
- Al evitar convertir cada línea de resultado de una consulta en un objeto, se evita consumir memoria innecesariamente y realizar procesamientos adicionales.
¿Por qué algunos atributos de los controladores tienen un guion bajo al principio del nombre, mientras que otros no?
Los atributos que tienen un guion bajo al principio de su nombre son creados automáticamente por Temma:
- $this->_session es creado por el framework, salvo que la configuración desactive explícitamente las sesiones.
- $this->_loader siempre es creado por el framework, para gestionar la inyección de dependencias.
A diferencia de esto, los atributos de acceso a las fuentes de datos tienen el mismo nombre que el definido en la sección dataSources de la configuración (ver la documentación).
Estos nombres dependen enteramente de tu configuración. Por ejemplo, la conexión a la base de datos puede llamarse de otra forma que
"db" (puedes elegir "database", "sql", "mysqlserver3", u otro).
Sin embargo, ten en cuenta que el plugin de caché espera que la conexión a la caché
se llame efectivamente "cache" y no de otra manera.
¿Cómo funciona la inyección de dependencias de Temma?
El componente de inyección de dependencias de Temma funciona según un esquema muy clásico. En sí, es similar a otros componentes como PHP-DI (ver Understanding Dependency Injection), salvo que integra la gestión de casos particulares propios de Temma.
El componente de Temma puede usarse como un Service locator
o haciendo autowiring. El uso típico es utilizar el service locator en los controladores, y hacer
autowiring con los objetos de negocio.
Sin embargo, es posible usar el service locator en todos los objetos de una aplicación,
lo que tiene ciertas ventajas (ver
In Defense of Service Locator),
al precio de un acoplamiento más fuerte del código.