F.A.Q.

Réponses aux questions usuelles

Présentation

Pourquoi un nouveau framework ?

Temma n'est pas “nouveau”. Il est utilisé depuis 2007 sur plusieurs centaines de sites (dont Ooreka, Skriv et Rolis).

Le but initial de Temma est de revenir aux fondements d'un framework MVC : accélérer les développements en permettant aux développeurs de se concentrer sur l'essentiel de leur travail, et de ne pas avoir à réimplémenter la même chose encore et encore.

Perdre de vue cet objectif, en ajoutant des fonctionnalités inutiles ou en contraignant à l'utilisation de règles très strictes, forcerait à passer par un apprentissage long et une mise-en-œuvre compliquée.

Temma propose donc un environnement permettant de développer rapidement vos sites Web, en offrant un cadre efficace, sans pour autant apporter une complexité inutile.

Qui est à l'origine de Temma ?

Temma a été développé par Amaury Bouchard, co-fondateur et directeur technique du site Ooreka pendant 10 ans, pour les développements réalisés en interne dans son entreprise.

Son but était de mettre en place un framework léger, qui facilite le travail des développeurs sans nécessiter pour autant un apprentissage long ou douloureux, et qui permette de séparer clairement le travail de développement de celui d'intégration HTML/CSS.

D'où vient le nom de Temma ?

Initialement, Temma signifiait « TEMplate MAnager », ce qui montrait bien que le but premier était de faciliter la gestion entre le code métier et les templates. Depuis, le framework s'est étoffé et offre un véritable environnement MVC.

Quelle est la licence de Temma ?

Le code source de Temma est publié sous les termes de la licence MIT.

Comparaisons

Pourquoi utiliser Temma plutôt que des frameworks comme Symfony, Zend Framework ou Laravel ?

Ces frameworks imposent une courbe d'apprentissage assez ardue, obligeant à assimiler des concepts qui leurs sont propres.

On devient alors un développeur Sympfony (ou autre), et non plus un “développeur PHP”.

Et en même temps, les concepts simples qui devraient être gérés par le framework deviennent inutilement complexes (essayez de faire des plugins avec Symfony, vous devrez développer un event listener…).

Pourquoi utiliser Temma plutôt que des micro-frameworks comme Silex, Lumen ou Slim ?

Ces micro-frameworks peuvent sembler plus simples à mettre en œuvre de prime abord. Mais en mélangeant le routage et les contrôleurs comme ils le font, ils rendent au contraire le code moins lisible, et donc plus difficile à maintenir dans la durée.

Et pour ceux qui sont basés sur des frameworks lourds (Symfony pour Silex, Laravel pour Lumen), le reste de votre code subit toujours la lourdeur sous-jacente.

Technique

Pourquoi Temma utilise-t-il Smarty comme moteur de template ?

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é.

Pourquoi Temma ne génère-t-il pas d'interface d'administration des données en base ?

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.

Pourquoi Temma ne propose-t-il pas un ORM ?

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.
  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.

Pourquoi certains attributs des contrôleurs ont un underscore au début de leur nom (_session, _loader), alors que d'autres n'en ont pas (db, cache) ?

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 configurationdé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.