¿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.
¿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.
¿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é 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é 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.
¿En qué se diferencia la gestión de atributos de Temma?
En la mayoría de los frameworks PHP, los atributos son pasivos: describen una intención, pero es el núcleo del framework el que los analiza y aplica la lógica correspondiente.
Temma hizo una elección diferente: los atributos son objetos activos.
Cuando se instancian, pueden usar directamente la API del framework (respuesta HTTP, vista,
seguridad, flujo de ejecución, etc.) para modificar el comportamiento de la aplicación.
El framework no necesita conocer todos los atributos de antemano: proporciona un contexto de ejecución, y son los atributos los que aplican su lógica.
Este modelo permite a los desarrolladores:
- crear sus propios atributos funcionales;
- extender el comportamiento de la aplicación sin modificar el núcleo del framework;
- construir plugins simples, locales y legibles.
Un atributo que no es instanciado por Temma permanece totalmente inerte: por lo tanto, no hay efectos secundarios ocultos.
El loader (componente de inyección de dependencias) de Temma se inscribe en una lógica de programación orientada a aspectos y de inyección de dependencias orientada a aspectos: los atributos desempeñan el papel de aspectos de la aplicación, aplicados en puntos precisos del ciclo de ejecución.
¿Temma funciona bien con los agentes de programación con IA?
Sí, y es una elección deliberada. Contribuyen a ello tres elementos:
- Convenciones en lugar de configuración. Un agente que conoce la convención de nombres sabe dónde escribir un controlador y qué plantilla se usará, sin tener que leer (ni inventar) un fichero de rutas.
- Skills entregados con el framework. Cada proyecto Temma contiene una veintena de skills, uno por tema, que enseñan al agente los mecanismos del framework. Así no tiene que deducirlos de sus conocimientos generales.
- Una instalación automatizable. Dándole a tu agente la frase Crea un sitio web usando Temma (temma.net/go), instala el framework y arranca el proyecto por su cuenta.
El sitio publica también un fichero llms.txt, que permite a un agente orientarse en la documentación.