Foire aux questions

Qui est à l'origine de Temma ? D'où vient son nom ? Quelle est sa licence ?

Temma a été développé par Amaury Bouchard, co-fondateur et directeur technique de la société française Fine Media, 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.

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.

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

Pourquoi un nouveau framework ?

Temma n'est pas si «nouveau». Il est utilisé en interne par la société Fine Media depuis 2007, sur plusieurs centaines de sites.

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, sans pour autant vous forcer à travailler d'une manière figée.

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

Parce qu'il est bien plus efficace d'utiliser phpMyAdmin pour cela.

Malgré tout, vous trouverez des contrôleurs en téléchargement sur temma.net qui peuvent combler une partie de ce besoin.

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 les «penseurs» actifs dans la communauté PHP, on ne peut pas remettre en question sa très large adoption par la majorité silencieuse de cette même communauté.

Si toutefois vous souhaitez utiliser un autre moteur de template, il est tout à fait possible d'utiliser une autre vue par défaut, parmi celles proposées par Temma (de manière native ou en téléchargement sur temma.net).

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

La question pourrait être inversée. Pourquoi proposer un ORM ? Habituellement, les raisons sont :

  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.

Plutôt que d'utiliser un ORM existant [1] ou de se baser sur le pattern Active Record [2], 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.

[1] : tel que Doctrine ou Propel
[2] : voir des frameworks comme Ruby on Rails ou CakePHP

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.
  • Plutôt que d'avoir un objet par table de la base de données, une même DAO peut gérer toutes les requêtes concernant plusieurs tables qui forment un ensemble logique. Cela réduit le nombre d'objets dans un projet, ce qui en facilite la maintenance.

Pour répondre point par point aux raisons citées plus haut :

  1. Plusieurs réponses :
    • Pour des requêtes simples (CRUD), 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.
    • 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. Pour passer d'une base de données à une autre, il faut penser à 2 choses :
    • Avoir une couche d'abstraction (légère) de la base de données. Temma utilise pour cela l'objet FineDatabase, afin d'éviter d'appeler directement les fonctions natives de telle ou telle base.
    • 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.

Dernier point important : Le recours aux DAO est proposé par Temma mais nullement imposé. Vous êtes libre d'utiliser un autre système (ORM, base noSQL, fichier texte, ...) si vous préférez.

Pourquoi le système de routage de Temma n'offre-t-il pas plus de possibilités ?

La fonctionnalité de routage intégrée à Temma est prévue pour être simple à utiliser. Elle permet de définir des contrôleurs virtuels qui pointent sur des contrôleurs réels.

Selon notre point de vue, un routage complexe est souvent une mauvaise idée. Cela crée une logique applicative qui se cache dans un fichier de configuration au lieu d'être gérée dans le code. Si cela semble plus souple en théorie, on se rend compte que cela rend la maintenance du code plus difficile en pratique.

Avec des contrôleurs correctement nommés, les besoins de routage diminuent. Sur la plupart des projets, ces besoins correspondent à des exceptions et non à un usage courant.

Si toutefois vous avez des besoins ultra-spécifiques qui requierts un routage élaboré, sachez que cela peut être mis en place en passant par un plugin qui «manipulera» les URLs et modifiera les noms du contrôleur et de l'action qui seront exécutés.
Vous pouvez le développer en fonction de vos besoin ou regarder du côté des extensions en téléchargement sur temma.net.