Je répond ici, sur linuxfrench, ils ont la fâcheuse tendance à censurer tous ceux qui ne sont pas de leurs avis.
1_ Problème des passwords de DB dans le script:
Soit disant que ce n'est pas bien que l'administrateur puisse lire ces données. Si un appelle une personne administrateur c'est qu'elle doit pouvoir administrer le site. Si tout le site c'est un gros exécutable compilé appelé en cgi et que l'admin peut rien faire ce n'est plus vraiment un admin. De plus, l'accès à la DB est relatif au site, l'admin à donc accès à la partie de DB qu'il doit pouvoir consulter/modifier afin, je me répète, d'administrer son site. Donc à mon avis c'est un faux problème. Si on tient vraiment à masquer tout ça et à limiter l'admin à une gestion de template HTML par exemple, on peut grâce à certains outils préinterprêter le PHP et ainsi masquer le code et les accès.
2_ problème de vitesse
C'est aussi à mon avis un faux problème de rejeter les problèmes de vitesse sur le PHP, alors que ceux qui font des pages savent que le gros problème se sont le très grand nombre de requêtes SQL pour chaques pages. A moins de calculer la 10'000ème décimale de PI sur chaques pages, arriver à faire ramer du PHP sans accès à des DBs est très très difficile (sur une machine 'standard' et une page PHP simple, la génération de la page prend en gros moins d'un centième de seconde, ce qui représente environ 400'000 pages par jour tout de même). Les solutions pour la vitesse existent: mécanisme de cache dont certains sont gratuis, préinterprétation, ... mais comme dit précedemment, en général le problème vient surtout des accès aux DB. Pour améliorer cela on peut générer du html à partir de PHP et d'accès au DB, et une fois généré, on le stocke sur le disque et pendant X minutes on envoie le HTML plutot que de le refaire. Bien sûr, ce mécanisme ne peut pas s'appliquer à toutes la page ou à toutes les pages, mais on peut par exemple générer un menu qui ne change quasi jamais via ce système plutot que de le calculer à chaques pages. Certains système de templates utilisent aussi ce mécanisme.
3_ Séparer le contenu de la présentation
Au début, on met tout dans le PHP, c'est effectivement nul. Ensuite on fait des systèmes de gestion (en PHP) qui stockent le html séparément, dans des bases sql ou sous forme de fichiers. Le peu de données générées et écrites sur la pages directement par le PHP peuvent être formatée en métant un indicateur de class dans l'output et en le reliant avec une style sheet. Sans compter les systèmes de template comme Smarty, FastTemplate, qui servent justement à faire que des tierces personnes puissent bosser sur le site et uploader du pseudo HTML sans problèmes. Donc oui, on peut séparer à 99% le contenu de la présentation, il suffit juste de programmer les outils pour, ou d'utiliser ceux très bons qui existent déjà.
4_ Typage, puissance du language
C'est vrai que les débutants en prog aiment bien le non typage. Quand on a des projets plus gros à faire, parfois on aimerait bien pouvoir comme signalé dans l'article pouvoir bénéficier d'une meilleure analyse syntaxique grâce au typage. L'autre avantage du typage est l'optimisation, mais le PHP n'étant pas compilé cela n'entre pas en ligne de compte. En même temps, les fautes sont passablement bien signalée en PHP si on active tous les warnings et en pratique on trouve et résoud les problèmes aussi vite que dans un language typé.
Voilà, je ne suis donc pas convaincu par cet article. Je trouve dommage que l'auteur cherche tjs à illustrer des points négatifs alors qu'il sait pertinnement bien que pour la plupart des exemples évoqués il y a des solutions à mon avis viables.
Je signale encore juste que dans les prochaines versions de PHP (4.3 je crois), il y aura de grandes améliorations au niveau de language, côté orientation objet, classes avec constructeur/déstructeur... ça n'a rien à voir avec l'article mais ça montre que PHP bouge très vite et va vraiment dans le bon sens.
# Quelques remarques
Posté par RB . En réponse à la dépêche Apache/PHP et IIS/ASP : pas si bons ?. Évalué à 10.
1_ Problème des passwords de DB dans le script:
Soit disant que ce n'est pas bien que l'administrateur puisse lire ces données. Si un appelle une personne administrateur c'est qu'elle doit pouvoir administrer le site. Si tout le site c'est un gros exécutable compilé appelé en cgi et que l'admin peut rien faire ce n'est plus vraiment un admin. De plus, l'accès à la DB est relatif au site, l'admin à donc accès à la partie de DB qu'il doit pouvoir consulter/modifier afin, je me répète, d'administrer son site. Donc à mon avis c'est un faux problème. Si on tient vraiment à masquer tout ça et à limiter l'admin à une gestion de template HTML par exemple, on peut grâce à certains outils préinterprêter le PHP et ainsi masquer le code et les accès.
2_ problème de vitesse
C'est aussi à mon avis un faux problème de rejeter les problèmes de vitesse sur le PHP, alors que ceux qui font des pages savent que le gros problème se sont le très grand nombre de requêtes SQL pour chaques pages. A moins de calculer la 10'000ème décimale de PI sur chaques pages, arriver à faire ramer du PHP sans accès à des DBs est très très difficile (sur une machine 'standard' et une page PHP simple, la génération de la page prend en gros moins d'un centième de seconde, ce qui représente environ 400'000 pages par jour tout de même). Les solutions pour la vitesse existent: mécanisme de cache dont certains sont gratuis, préinterprétation, ... mais comme dit précedemment, en général le problème vient surtout des accès aux DB. Pour améliorer cela on peut générer du html à partir de PHP et d'accès au DB, et une fois généré, on le stocke sur le disque et pendant X minutes on envoie le HTML plutot que de le refaire. Bien sûr, ce mécanisme ne peut pas s'appliquer à toutes la page ou à toutes les pages, mais on peut par exemple générer un menu qui ne change quasi jamais via ce système plutot que de le calculer à chaques pages. Certains système de templates utilisent aussi ce mécanisme.
3_ Séparer le contenu de la présentation
Au début, on met tout dans le PHP, c'est effectivement nul. Ensuite on fait des systèmes de gestion (en PHP) qui stockent le html séparément, dans des bases sql ou sous forme de fichiers. Le peu de données générées et écrites sur la pages directement par le PHP peuvent être formatée en métant un indicateur de class dans l'output et en le reliant avec une style sheet. Sans compter les systèmes de template comme Smarty, FastTemplate, qui servent justement à faire que des tierces personnes puissent bosser sur le site et uploader du pseudo HTML sans problèmes. Donc oui, on peut séparer à 99% le contenu de la présentation, il suffit juste de programmer les outils pour, ou d'utiliser ceux très bons qui existent déjà.
4_ Typage, puissance du language
C'est vrai que les débutants en prog aiment bien le non typage. Quand on a des projets plus gros à faire, parfois on aimerait bien pouvoir comme signalé dans l'article pouvoir bénéficier d'une meilleure analyse syntaxique grâce au typage. L'autre avantage du typage est l'optimisation, mais le PHP n'étant pas compilé cela n'entre pas en ligne de compte. En même temps, les fautes sont passablement bien signalée en PHP si on active tous les warnings et en pratique on trouve et résoud les problèmes aussi vite que dans un language typé.
Voilà, je ne suis donc pas convaincu par cet article. Je trouve dommage que l'auteur cherche tjs à illustrer des points négatifs alors qu'il sait pertinnement bien que pour la plupart des exemples évoqués il y a des solutions à mon avis viables.
Je signale encore juste que dans les prochaines versions de PHP (4.3 je crois), il y aura de grandes améliorations au niveau de language, côté orientation objet, classes avec constructeur/déstructeur... ça n'a rien à voir avec l'article mais ça montre que PHP bouge très vite et va vraiment dans le bon sens.