A propos de SALT
Le framework SALT est un projet qui a muri pendant des années dans mon esprit.
J'ai utilisé et réalisé quelques framework, y compris dans d'autres languages (Java notamment) et j'ai été
longtemps bloqué dans la réalisation de mon framework PHP par le niveau d'abstraction qu'il devait fournir :
Un framework complexe qui cache trop l'implémentation et/ou qui invente un autre langage (de description ou de template)
pour simplifier le travail au développeur ne m'apparait désormais plus comme un framework idéal :
- Il oblige le développeur à subir une phase d'apprentissage supplémentaire
- Il "rend bête" le développeur en le rendant dépendant du framework
SALT a été créé dans une optique opposée : on simplifie le développement, mais pas trop.
Le développeur reste maître de l'échappement de ses variables pour l'affichage par exemple, mais on lui fournit
une API simple pour y penser.
De la même manière, vu que SALT s'interdit de créer un mini language, il ne proposera jamais les fonctions suivantes :
- Langage de template pour les pages, PHP fonctionne très bien pour ca.
Les templates de Symfony, Twig ou encore Smarty ne font au final que remplacer le langage PHP par un autre langage,
avec quelques améliorations peut être, mais qui ne valent pas le coup, de mon point de vue, de créer, parser et
interpréter un autre langage, même avec des systèmes de mises en cache ensuite.
Le seul cas où l'utilisation d'un template pourrait avoir une utilité c'est pour les énormes projets avec une équipe
de développeurs et une équipe de designers séparées, les designers ayant "juste" à apprendre
le langage de template.
Personnellement, je n'ai jamais rencontré ce cas... et quand on arrive aux limites du langage de template, on voit
fleurir dans les pages des morceaux de code PHP qui permettent de réaliser ce que le langage de template ne
permet pas.
Au final, le designer apprend à devenir développeur, quand ce ne sont pas déjà une seule et même personne au départ.
- Mapping des relations entre tables SQL
Le concept est super, et peut être bien utilisé, mais il souffre de 2 problèmes :
- La création d'un mini langage
Décrire les relations entre 2 tables est particulièrement complexe et est en général réalisé avec le
recours à un mini langage de description.
De plus cela ouvre d'autres possibilités qu'il est tentant d'implémenter ensuite, comme par exemple
le chargement automatique d'un objet lié, la liaison automatique d'objets liés lorsqu'ils sont remontés,
la vérification d'existence lors d'une mise à jour ou suppression d'objets, etc...
Tout cela se traduit par une complexité excessive du framework.
- Les performances
A partir du moment où le framework gère les liaisons entre les objets, le développeur a tendance à ne plus
s'en préoccuper: parce que c'est géré de manière complexe, ca le devient.
Du coup il va produire du code qui va se traduire par un chargement d'objet dans une boucle par exemple,
sans qu'il s'en aperçoive parce que le framework sera "intelligent"... et le développeur un peu moins.
A propos de l'auteur
Titulaire d'un BAC+5 en Informatique Fondamentale en 2004, et faisant du PHP depuis 2001 environ, je travaille
dans une SSII depuis 2005 dans laquelle j'ai pu développer mes compétences en Java, PHP, Ruby, etc...
Dans le domaine de l'informatique je m'intéresse à tout ce qui est sécurité, performance, et plus généralement
à la
beauté du code
Pour déclarer un bug concernant le framework SALT, utilisez le
formulaire de soumission de bug de GitHub
Pour toutes les autres demandes, vous pouvez me contacter à l'adresse fladnag at salt-php.org