Frameworks

[lanoix]

Je ne crois pas que tout le monde en utilise, que du contraire en PHP... Dans ce sujet nous les utilisons et nous en parlons car... C'est le sujet. Si tu vois ce que je veux dire...

Par contre dire que PHP en soi est un bon moteur de template, c'est pour moi une abomination. Tout comme de dire que l'Objet sous PHP est une chose absurde. En lisant ca je te classifie dans les "programmeurs amateurs procéduraux". Ce n'est pas péjoratif, je pense juste que tu vas réinventer plusieurs fois la roue, et que dans 10 ans tu coderas toujours de la même manière - sans pour autant dire que tu codes mal!

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

[Sephi-Chan]

Si actuellement je ne trouve pas encore trop d'intérêt à la POO, c'est probablement parce que je n'ai jamais pu voir un système complexe développée avec cette méthode.

Les cours de Supinfo traitent l'OO, j'aurais donc l'occasion d'y toucher de plus près, avec de vrais cours, des exemples concrets et bien faits. De même, si je m'y intéresse je pourrais trouver sans problème des gens pour m'aider sur place.


Sephi-Chan

[zzarbi]

Si actuellement je ne trouve pas encore trop d'intérêt à la POO, c'est probablement parce que je n'ai jamais pu voir un système complexe développée avec cette méthode.

Les cours de Supinfo traitent l'OO, j'aurais donc l'occasion d'y toucher de plus près, avec de vrais cours, des exemples concrets et bien faits. De même, si je m'y intéresse je pourrais trouver sans problème des gens pour m'aider sur place.


Sephi-Chan

Bah si tu tombes avec de bon formateur (je fais allusion à ceux de JAVA), il pourront surement te faire comprendre tous l'interet de l'objet... C'est là que j'ai bien compris cette notion... C'est vrai que tout seul même si on comprend le concept on arrive pas vraiment à voir ce qui diffère...

[lanoix]

PHP est un langage de template, donc un moteur de template

Pas d'accord du tout... PHP était un language de template, mais il a évolué... C'est comme si on se limitait à dire que Java sur le net est (au lieu d'était) pour faire des applets.

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 ?

Oui, et de taille, le premier code est du layer logic tandis que la deuxième est du buisness logic. Si dans un gros projet les deux ne font qu'un, bonjour la maintenance, la lisibilité et la réutilisabilité :/
Et je te dis ca par expérience...

[uriak]

A mon humble avis, si la POO et les templates "semblent" un peu sujets à débat c'est à cause de la nature du langage et des applications.

Je code tout le temps en C++ et je peux te dire, Sephi-Chan que sans objets nous ne pourrions pas travailler. Pour moi les objets ont deux grands avantages (autres que l'organisation)

->réunir données et fonctions dans des ensembles cohérents. Si j'ai besoin pour me connecter de mon nom de dbb, et que je le confie à un objet connexion, il me suffira dans son constructeur de lui en donner un autre pour obtenir une connexion à cette autre database.
->Bénéficier de l'héritage. J'ai des tas d'éléments du même types mais qui doivent subir des traitement différents : un seul appel, pas de tests à faire, c'est le langage (ou le compilo) qui les faits pour moi

Pourquoi en php ça ne parâit pas si important :
->typage faible : je peux filer dans une variable le nom de la fonction à utiliser, y affecter ce que je veux, etc. oups ! dans les autres langage, on échange pas les choses comme ça et les objets sont bien utiles pour offrir à chacun les variables dont il a besoin
->manière de travailler : oui le traitement dans une page, n'est pas énorme, à l'échelle d'un programme entier. Et la meilleure manière de réunir des données liées entre elles... c'est la BDD. Alors qu'évidemment, en C++, java on passera par des objets en mémoire ou des fichiers...

[naholyr]

Oui, et de taille, le premier code est du layer logic tandis que la deuxième est du buisness logic. Si dans un gros projet les deux ne font qu'un, bonjour la maintenance, la lisibilité et la réutilisabilité :/
Et je te dis ca par expérience...

Ah, où vois-tu du «business logic» dans cet exemple ? Y a-t'il une requête à une bdd ? Une affectation ? Le moindre calcul ? Pas plus que dans le même exemple «traduit» en Smarty. Je répète et maintiens que PHP est un excellent langage de template pour peu qu'on se limite à un sous-ensemble.

[Loetheri]

@ lanoix : Je suis peut-être amateur pour toi. C'est vrai dans une certaine mesure. Mais je ne vois pas en quoi je le deviens car j'utilise du procédural. Mais je t'invite à m'en faire part en privée en explicitant tes arguments.
D'ailleurs, je ne peux que te redemander de bien dire pourquoi tu dis telle ou telle chose. Tu dis que PHP était un moteur de template. Ok, je suis prêt à écouter mais j'aimerai savoir pourquoi, sur quoi te bases-tu ? Bien entendu, ne prends pas mal mon commentaire ;-)

@ naholyr : Tu dis qu'il faut en saisir le sens ^^ Je suis d'accord mais quels sont les avantages réels de l'usage d'un framework.
Pour ton exemple sur les requêtes, j'avoue avoir été perdu au début du deuxième paragraphe ^^

Je vais repréciser ma pensée en ce qui concerne l'objet.
L'objet sous PHP est et reste une absurdité. Pas à cause de l'objet en soi mais tout simplement parce que son utilité est ... réduite à la création de la page. Si je crée un objet, il est limité à la page. L'objet, outre les différents aspects qu'il apporte, devient nul en PHP. Je dis bien en PHP.
Le jour où les serveurs permettront d'avoir un objet sur le long terme, ok l'objet aura du sens. Aujourd'hui, ce n'est pas le cas.
Mais le sujet n'est pas ici, l'objet. Revenons sur les frameworks ;-)

[uriak]

et en le passant par $_SESSION ?
Effectivement, comme je l'ai évoqué plus haut, l'objet en php, souffre de sa vie éphémère

[lanoix]

Ah, où vois-tu du «business logic» dans cet exemple ?

Nulle part, ton exemple est trop court; mais pour l'écrire de cette manière ta logique de calcul/affection est "au-dessus", pas spécialement le même fichier mais au même niveau (niveau d'exécution), donc dans la couche business. Moi aujourd'hui je ne peux plus faire sans séparer clairement les deux... Question de clarté et de propreté, ca va plus vite en maintenance et debugging.

Je répète et maintiens que PHP est un excellent langage de template pour peu qu'on se limite à un sous-ensemble.

Je m'excuse, j'avais en fait à la base compris que dans ton raisonnement PHP se limitait à cela.

@ lanoix : Je suis peut-être amateur pour toi. C'est vrai dans une certaine mesure. Mais je ne vois pas en quoi je le deviens car j'utilise du procédural.

Non tu m'as mal compris; les deux sont sans rapports dans mon jugement. Si je dis amateur, ce n'est pas péjoratif, je sous-entend par là que ce n'est pas ton métier et que tu n'as sans doute pas eu l'occasion d'apprendre ou de travailler en orienté objet.

Mais je pense en lisant la fin de ton commentaire que tu as encore trop la vision "pages web". Aussi, perso, mes objets passent dans les sessions, dans la DB, dans des fichiers XML... Et ce sont des mécanismes automatiques.