Frameworks

[naholyr]

L'objet n'est pas une absurdité, il permet simplement de penser le programme d'une manière différente : on pense avant tout en terme d'acteurs (qui fait des actions) et plus en terme d'actions (qui ont des acteurs). Cela parait très similaire, ça l'est. Si l'objet te parait absurde, c'est parce que PHP en fait une implémentation incorrecte. Si tu faisais de l'objet Javascript, Python, ou même Java, tu comprendrais sa puissance Je ne vais pas faire un laïus à ce propos, je pense que tu as déjà du en lire beaucoup : si personne ne t'a convaincu jusqu'alors je n'y arriverai pas, toi seul peux te convaincre et je suis persuadé que ça viendra. Question de temps (comme pour les frameworks).



Je rejoins en revanche Loetheri sur la notion de moteurs de templates, autant le concept de moteur de templates est bon (séparer la couche présentation de la couche métier), autant son implémentation est en général stupide, seul Savant a suivi la bonne voie : ne pas réinventer la roue.
Il faut savoir que PHP au départ, c'est un moteur de template pour Perl. Au départ il n'y avait que les <?=$variable?>, les <? opération() ?> et les <? structure(): ?> ... <? endstructure ?>. Puis le nombre d'opérations se sont étoffées, si bien qu'il a pu donner naissance à PHP3, etc…
PHP est un langage de template, donc un moteur de template qui utilise un langage autre que PHP lui-même ajoute une surcouche bien inutile, entre

Code :

Salut {$prenom},
Tes infos :
{foreach from=$infos item=value key=key}
- {$key} = {$value}
{/foreach}

et

Code :

Salut <?php echo $prenom ?>,
Tes infos
<?php foreach ($infos as $key => $value): ?>
- <?php echo $key ?> = <?php echo $value ?>
<?php endforeach ?>

à part la longueur des balises, vois-tu la moindre différence ?

Quand on parle d'utiliser PHP en tant que moteur de template en utilisant include(), je ne pense pas que ce soit la panacée, un moteur apporte une logique en plus comme la gestion du cache. Par contre, PHP en tant que langage de template (pour les fichiers de la vue) me parait la meilleure solution. Si je dois mettre un mot en majuscules, on est d'accord que ça fait partie de la vue. Moi programmeur PHP je saurai instantanément que "<?php echo strtoupper($valeur) ?>" va résoudre ça, alors que moi utilisateur de Smarty (mais forcément moins que de PHP) je vais de voir chercher dans le manuel (déjà que pour PHP j'ai tout le temps le nez fourré dedans alors que j'en fais toute la journée) pour trouver "{$valeur|upper}"
PHP a une "autre" casquette (qui est en réalité la plus ancienne) : il est vraiment un langage de template, il suffit de se limiter à un sous-ensemble du langage complet.



Concernant le niveau nécessaire à l'utilisation d'un framework, je rejoins pascalje, je pense qu'il faut un bon bagage avant :
- Déjà d'en saisir l'intérêt, tout simplement
- Ne pas devenir dépendant d'un framework, car comme ça a été dit précédemment, si on commence à apprendre un langage en même temps qu'un framework, il me parait difficile de pouvoir changer de framework un jour prochain. Par exemple je défie tous les nouveaux venus de Ruby de coder sans Rails derrière...
- Ne pas avoir l'impression que tout est magique. Il n'y a rien de pire pour l'apprentissage et de plus frustrant quand il y a une moulinette qui tourne derrière et qu'on a aucune idée de ce qu'elle fait ni comment...



Pour le nombre de requêtes générées, c'est en effet un problème récurrent des frameworks. Pour ce faire Symfony utilise un système très bien fichu basé sur Propel : lors de la générationd des classes il définit quatre fichiers :
- La classe "mère" qui va être ecrasée à chaque fois qu'on régénère le modèle
- La classe "principale" qui hérite de la classe mère, qui ne sera jamais ecrasée (seulement créee initialement vide si elle n'existe pas)
- Et deux classes (sous le même modèle de classe "mère" et de classe "principale") avec uniquement des méthodes statiques.
Les deux premières classes représentent les actions au niveau d'un élément du modèle (exemple : changer le mot de passe d'un utilisateur), les deux autres représentant les actions au niveau du modèle lui-même (exemple : récupérer la liste des utilisateurs dont le login commence par "n").
Grâce à ce système où la classe "principale" n'est qu'une surcharge d'une classe auto-générée, on peut modifier les méthodes (par exemple surcharger setPassword() pour qu'il fasse le cryptage automatiquement avant le stockage) mais également en créer de nouvelles : par exemple récupérer plein d'infos d'un coup avec une grosse jointure, ça se fera dans la classe statique en ajoutant une nouvelle méthode qui va faire sa grosse requête en utilisant le système de requête de Propel (on peut bien évidemment changer le système d'accès à la base de données si on n'aime pas celui par défaut, c'est l'avantage de la modularité au passage ).

Tu auras donc ta requête qui t'en épargne plein d'autres, sans perdre en souplesse au niveau de l'accès à la base de données, ni en t'éloignant du modèle de base. Tout ceci est très souple.


Notez qu'on parle de Symfony, mais n'importe quel moteur de template doit savoir faire ce genre de chose j'imagine. Le critère déterminant dans le choix d'un framework pour moi c'est la documentation d'abord et avant tout ! ensuite la taille et la réactivité de la communauté (c'est souvent proportionnel, mais pas toujours).