Foire aux questions

Temma est utilisé en production par des entreprises dont les serveurs ne peuvent pas toujours suivre le rythme de sortie des versions de PHP.

En conséquence, nous avons choisi de rester compatible avec la version de PHP fournie dans l'avant-dernière version LTS (support long-terme) de la distribution Linux Ubuntu.

Le composant d'injection de dépendances de Temma fonctionne selon un schéma très classique. En soi, il est similaire à d'autres composants comme PHP-DI (voir Understanding Dependency Injection), sauf qu'il intègre la gestion de cas particuliers propres à Temma.

Le composant de Temma peut être utilisé comme un Service locator ou en faisant de l'autowiring. L'usage typique est d'utiliser le service locator dans les contrôleurs, et de faire de l'autowiring avec les objets métiers.
Il est toutefois possible d'utiliser le service locator dans tous les objets d'une application, ce qui comporte des avantages (voir In Defense of Service Locator), au prix d'un couplage plus fort du code.

Les raisons invoquées pour l'utilisation d'un ORM sont habituellement :

1. Ne pas avoir besoin d'écrire de requêtes SQL.
2. Manipuler uniquement des objets.
3. Pouvoir changer de bases de données au besoin.

Voici comment Temma y répond :

1. Pour des requêtes sur une seule table, les DAO de Temma ne nécessitent pas d'écrire de requêtes SQL. Pour des requêtes plus complexes (jointures, regroupements, ...), il est toujours plus efficace d'écrire les requêtes "à la main".

   Pour pallier à leurs problèmes de performances, les ORM proposent des langages dérivés du SQL (HQL pour Hibernate, DQL pour Doctrine). Les développeurs doivent toujours écrire leurs requêtes, sauf qu'elles sont traitées par une couche intermédiaire (avec sa syntaxe spécifique et ses lenteurs associées).

   Quels que soient les développements effectués, il faudra bien aller voir en base de données si tout est stocké correctement. Et donc, il faudra bien taper des requêtes SQL. Un développeur Web qui n'en est pas capable aura vite des soucis.

2. Si la volonté de ne manipuler que des objets peut se comprendre dans certains environnements, le “PHP way of life” s'accomode très bien du transfert de données à base de simples listes et tableaux associatifs. C'est la manière la plus souple et rapide d'architecturer ses développements en PHP.

   On peut d'ailleurs remarquer que même les développeurs qui ne veulent manipuler que des “entités” (les objets représentant les données en base) utilisent des tableaux associatifs lorsqu'ils se connectent à des APIs externes. Pourtant, on pourrait se dire que les données doivent toujours être manipulées de la même manière, peu importe leur source.

3. La vraie couche d'abstraction est constituée par les DAO. Le code métier qui y fait appel n'a pas à être modifié, même en cas de modifications profondes qui imposent de changer les requêtes présentes dans les DAO.

Plutôt que d'utiliser un ORM existant comme Doctrine ou de se baser sur le pattern Active Record, Temma utilise le pattern Data Access Object (DAO en abrégé). Celui-ci est à la fois plus efficace dans son exécution et plus simple à employer.

L'utilisation des DAO est limpide :

• Pour récupérer les données d'un enregistrement dans une table, on appelle une méthode de la DAO. On récupère un tableau associatif, qui propose une clé pour chaque champ dans la table.
• Quand on récupère plusieurs enregistrements d'une table, on obtient une liste de tableaux associatifs. On peut itérer dessus avec toutes les fonctions natives de PHP comme foreach. C'est simple, clair, efficace.
• En évitant de convertir chaque ligne de résultat d'une requête en objet, on évite de consommer inutilement de la mémoire et de faire des traitements supplémentaires.

Smarty est le standard de facto des moteurs de template en PHP.

Il présente plusieurs qualités :

• Une syntaxe simple et claire, facilement assimilable par des infographistes éloignés de la logique de développement.
• Des possibilités d'extension faciles à mettre en œuvre, avec la création de filtres en PHP.
• Des performances qui peuvent être ajustées en ajoutant du cache sur des fragments de templates.

Même si la critique de Smarty semble être à la mode chez certains “penseurs” actifs dans la communauté PHP (principalement ceux qui finissent par proposer des clones de Smarty), on ne peut pas remettre en question sa très large adoption par une majorité silencieuse de cette même communauté.

Parce qu'il sera plus efficace d'utiliser PhpMyAdmin, PhpPgAdmin, PhpRedisAdmin, Adminer…

Ce n'est pas le rôle d'un framework d'offrir ce genre de fonctionnalité. Le rôle d'un framework, c'est d'offrir les bases techniques qui permettent de développer ces outils.

Les attributs qui ont un underscore au début de leur nom sont créés automatiquement par Temma :

• $this->_session est créé par le framework, sauf si la configuration désative explicitement les sessions.
• $this->_loader est toujours créé par le framework, pour gérer l'injection de dépendance.

Contrairement à cela, les attributs d'accès aux sources de données ont le même nom que ce qui a été défini dans la section dataSources de la configuration (voir la documentation).

Ces noms dépendent entièrement de votre configuration. Par exemple, la connexion à la base de données peut s'appeler autrement que "db" (vous pouvez choisir "database", "sql", "mysqlserver3", ou autre).
Toutefois, notez bien que le plugin de mise en cache s'attend à ce que la connexion au cache s'appelle effectivement "cache" et pas autrement.

Dans la plupart des frameworks PHP, les attributs sont passifs : ils décrivent une intention, mais c’est le cœur du framework qui les analyse et applique la logique correspondante.

Temma a fait un choix différent : les attributs sont des objets actifs.
Lorsqu’ils sont instanciés, ils peuvent utiliser directement l’API du framework (réponse HTTP, vue, sécurité, flux d’exécution, etc.) pour modifier le comportement de l’application.

Le framework n’a pas besoin de connaître tous les attributs à l’avance : il fournit un contexte d’exécution, et ce sont les attributs qui appliquent leur logique.

Ce modèle permet aux développeurs de :

• créer leurs propres attributs fonctionnels ;
• étendre le comportement de l’application sans modifier le cœur du framework ;
• construire des plugins simples, locaux et lisibles.

Un attribut qui n’est pas instancié par Temma reste totalement inerte : il n’y a donc pas d’effet de bord caché.

Le loader (composant d'injection de dépendances) de Temma s’inscrit dans une logique de programmation orientée aspects et d’injection de dépendances orientée aspects : les attributs jouent le rôle d’aspects applicatifs, appliqués à des points précis du cycle d’exécution.