avantages et inconvenient de PHP?

[Mihamina Rakotomandimby]

Bonjour,

PHP fait partie des langages que j'utilise souvent.
Mais je n'ai pas encore ma petite idée de ses avantages et inconvénients.
Pour le moment, les petites choses que je fais avec (et qui de toutes
façons sont faisable dans presque n'importe quel langage) ne me
permettent pas d'en connaitre ses limites ou ses grandeurs.

Peut-être auriez-vous des liens qui en parlent dans vos bookmarks? Si
vous pouviez les communiquer pour qu'on en discute...

Merci d'avance.

[Bruno Desthuilliers]

Post by Mihamina Rakotomandimby
Bonjour,

Salut R12Y

Post by Mihamina Rakotomandimby
PHP fait partie des langages que j'utilise souvent.
Mais je n'ai pas encore ma petite idée de ses avantages et inconvénients.
Pour le moment, les petites choses que je fais avec (et qui de toutes
façons sont faisable dans presque n'importe quel langage) ne me
permettent pas d'en connaitre ses limites ou ses grandeurs.
Peut-être auriez-vous des liens qui en parlent dans vos bookmarks? Si
vous pouviez les communiquer pour qu'on en discute...

Rapidement, et de mon point de vue personnel à moi qui est probablement
très biaisé (en d'autres termes : si vous avez un fort attachement
affectif à PHP, ne lisez surtout pas ce post, ou alors à vos risques et
périls - voilà, vous êtes prévenus).

Les deux avantages de PHP sont
- que c'est disponible sur la grande majorité des hébergement grand public
- que ça permet à n'importe quel bricoleur d'ajouter rapidement quelques
bricoles dynamiques dans un site statique.

Quant aux inconvénients, heu, comment dire... bon, en vrac:

Déjà, ne cherche pas la moindre cohérence dans le langage, il n'y en a
pas - il n'y a jamais eu le moindre travail de conception du langage, la
syntaxe est bricolée au petit bonheur, il n'y a aucune convention de
nommage dans les fonctions de la bibliothèque standard, ni dans l'ordre
des arguments, bref même après 6 ans d'utilisation quasi-quotidienne, je
suis toujours obligé d'aller chercher dans la doc même pour les
fonctions de bases (manipulations de chaines et de tableaux entre autres).

Je ne m'étendrai pas sur le laxisme du langage en matière de typage et
de gestion des variables non déclarées (et pourtant, j'ai une expérience
certaine des langages dynamiques), ni sur l'absence totale de gestion
des espaces de nommage.

Il y a aussi le modèle d'exécution, qui fait qu'il faut reconstruire le
monde entier à chaque requête. Ce qui n'est pas un problème (et c'est
même plutôt adapté) tant qu'on reste à très bas niveau et sur des choses
simple, mais ça n'aide pas vraiment quand on souhaite factoriser /
abstraire son code, ce qui est une nécessité sur n'importe quelle appli
non-triviale (du moins si on espère pouvoir gérer la maintenance et les
évolutions...).

Enfin, les deux avantages cités plus haut ont pour corrolaire que le
niveau moyen du code PHP disponible sur le web (et donc servant
d'exemple aux débutants...) est au mieux médiocre. Sans vouloir être
méchant, sur toutes les applis PHP sur lesquelles j'ai eu à intervenir
jusqu'ici, il n'en y a pas *une* qui ne soit truffée de WTF majeurs et
d'erreurs de grand débutant (nb : lire la suite avant de réagir sur ce
point, merci).

<troll>En bref, PHP, c'est le nouveau basic. </troll>

Bon, ceci étant dit, en matière de développement web, j'aime encore
mieux PHP que Java (même si la tendance semble être de plus en plus
d'essayer de faire du Java en PHP - no comment...).

Et non, pas la peine de me le dire, je le sais : un bon développeur
arrivera à faire quelque chose de raisonnablement propre avec n'importe
quel langage, un mauvais fera de la merde de toutes façons.

Pour être honnête, et à mon grand regret, un des effets secondaires de
la popularité croissante de Python, et particulièrement de Django, est
qu'on commence à voir le même problème dans un langage / environnement
où le niveau moyen était jusque là plutôt correct. Bref, ce n'est pas
dans l'absolu un problème intrinsèque au langage lui-même (même si on ne
peut pas dire que PHP encourage spécialement les bonnes pratiques), mais
un corrolaire de sa popularité.

Bon, voilà, j'ai mon gilet pare-balles ignifugé, j'attend le retour de
flammes !-)

[Eloims]

Post by Bruno Desthuilliers

Post by Mihamina Rakotomandimby
Bonjour,

Salut R12Y
PHP fait partie des langages que j'utilise souvent.
Mais je n'ai pas encore ma petite idée de ses avantages et inconvénients.
...........
Bon, voilà, j'ai mon gilet pare-balles ignifugé, j'attend le retour de
flammes !-)

Ton gilet pare-balles ne devrait pas etre utile.
si quelqu'un défend inconditionnellement le PHP, oubliant tous ces
défauts, le plus probable c'est qu'il ne connaît que ce langage et n'a
jamais jeté un oeuil sur les autres solutions.


je fais d'ailleurs parti des programmeurs grand partisan des framework
"a la Struts" qui ont vu le jour depuis PHP5 (symfony pour ne pas le
citer, que j'utilise tous les jours dans mon stage).

Je pense que ce que j'aime aussi dans ce langage, bien que cela soit
aussi sa faiblesse) c'est que c'est parti de pas grand chose.

Chaque version a apporte un vrai lot de nouveautés et on est toujours
agréablement surpris (bon ok, PHP6 se limite a nous donner l'unicode, et
a devenir un peu plus strict sur certaines saletes des versions
précédentes: bye bye register globals, mais c'est un pas de plus vers un
vrai langage bien rigoureux)

Apres c'est vrai que comme dans tous les langages "grand public" on voit
tres souvent des choses effarantes qui sont écrites et publiées un peu
partout sur le net...

Mais apres tout, c'est plutôt une bonne chose, ca nous montre que ca
marche vraiment bien, et ca met la possibilité de publier du contenu a
la portee de presque tout le monde, ce qui est quand même le principe du
web.
Si on demande a un débutant en programmation de faire quelque chose de
simple en Ruby On Rails (syntaxe tres moche a mon goût) ou avec les
solutions J2E (comprendre le fonctionnement de la POO, faire marcher
Tomcat, coder sous Eclipse, et trouver un hebergeur compatible), il a
peu de chances de s'en sortir, PHP permet de tout faire en 2 secondes!


En plus, bien qu'on trouve de tout sur le net, la doc de php.net est
impeccable.

Je pense que d'ici qques annees php deviendra beaucoup plus rigoureux
sur le typage des variables (ca commence deja d'ailleurs, mais pas
encore sur les types natifs).

et pour ce qui est d'utiliser des variables non declares ou des index
non définis dans une map, c'est deja regle depuis 1 moment.

longue vie donc au PHP :p

Ce qui m'inquiete plus c'est ses défauts de base, difficiles a changer
maintenant.

Genre en effet, a chaque requete on repart de zero, tout les fichiers
sont re-pars'es, la config de l'appli qui tourne recharg'ee etc
Bon il y a des histoires pour faire du byte code avec le php je crois?
ou au moin des systeme de cache, mais c'est une fausse solution pour
recuperer d'un cote ce qu'on pert de l'autre.

Pis bon PHP c'est pas fait pour supporter des charges enormes non plus
(jme suis toujours demand'e comment ils font chez facebook d'ailleur
pour que ca tienne leur truc)

[Sylvain SF]

Post by Eloims
Apres c'est vrai que comme dans tous les langages "grand public" on voit
tres souvent des choses effarantes qui sont écrites et publiées un peu
partout sur le net...

savoir que certains peuvent commettre çi ou ça avec tel langage
n'apprend pas grd chse sur ce langage - ce n'est pas un inconvénient
*de* PHP si certains codent comme des anes.

Post by Eloims
ca met la possibilité de publier du contenu a la portee de presque
tout le monde

c'est en effet une caractéristique plus significative.

comparé à des J2E, WebObjects, ou autre dotnetteries MS, PHP a
l'énorme avantage de permettre gratuitement avec n'importe quel
serveur libre d'implémenter ce qui requiert moultes dépenses ailleurs.

Post by Eloims
Genre en effet, a chaque requete on repart de zero, tout les fichiers
sont re-pars'es, la config de l'appli qui tourne recharg'ee etc

choix du langage, pas défauts du langage.

on parle ici de pages ouèbes générées par un serveur http, le module
PHP devrait-il garder un contexte (d'un des N visiteurs) en mémoire
alors que rien ne permet de savoir si la prochaine page (requête)
sera faite dans 2 sec. ou 2 heures ?
doit-on cacher ce contexte alors que le serveur apache d'une part et
l'OS d'autre part participent déjà à la gestion de mise en cache des
fichiers souvent lus ?

Post by Eloims
Bon il y a des histoires pour faire du byte code avec le php je crois?
ou au moin des systeme de cache, mais c'est une fausse solution pour
recuperer d'un cote ce qu'on pert de l'autre.

hmm, non, une compilation des définitions de classes PHP serait en
effet un truc significatif pour améliorer le traitement des scripts,
bcp plus que le cache des instances de ces classes.

Sylvain.

[Denis Beauregard]

Post by Sylvain SF

Post by Eloims
Genre en effet, a chaque requete on repart de zero, tout les fichiers
sont re-pars'es, la config de l'appli qui tourne recharg'ee etc

choix du langage, pas défauts du langage.
on parle ici de pages ouèbes générées par un serveur http, le module
PHP devrait-il garder un contexte (d'un des N visiteurs) en mémoire
alors que rien ne permet de savoir si la prochaine page (requête)
sera faite dans 2 sec. ou 2 heures ?
doit-on cacher ce contexte alors que le serveur apache d'une part et
l'OS d'autre part participent déjà à la gestion de mise en cache des
fichiers souvent lus ?

Il y a 30 ou 40 ans, l'informatique fonctionnait de cette façon.
Quand on lançait un logiciel, c'est-à-dire quand on insérait une
pile de cartes perforées dans le lecteur, tout se faisait à partir
de zéro. Tout ? Pas vraiment car on pourrait conserver certaines
valeurs. C'est la même chose en PHP.

Un moteur de recherche peut par exemple conserver les résultats d'une
recherche précédente en mémoire. Cela a toutefois un coût, celui
d'inscrire dans la base de données ou sur le disque ces résultats.
Je pense qu'en général, le coût est moindre de recommencer à zéro
que de conserver les résultats précédents. Par ailleurs, c'est un
choix du programmeur de conserver ou pas ces résultats puisque PHP
permet de conserver des variables en mémoire. Donc, ce n'est pas
réellement un inconvénient du langage.

En fait, quand on repense à d'autres applications comme un
questionnaire sur plusieurs pages, et à leur mise en oeuvre en
PHP, je vois mal le problème de repartir à zéro puisque c'est un
bon exemple où, du point de vue des données, on ne repart pas à zéro.

Le problème restant serait alors celui de la non-compilation du PHP
et c'est une question de mise en oeuvre et non de langage...


Denis

[Eloims]

Post by Sylvain SF

Post by Eloims
Apres c'est vrai que comme dans tous les langages "grand public" on
voit tres souvent des choses effarantes qui sont écrites et publiées
un peu partout sur le net...

savoir que certains peuvent commettre çi ou ça avec tel langage
n'apprend pas grd chse sur ce langage - ce n'est pas un inconvénient
*de* PHP si certains codent comme des anes.

on est d'accord, mais ca ne change rien au faits.

Certains langages sont plus propices a faire des cochoneries que d'autres.
Bien que ce n'est plus le cas aujourd'hui vu que PHP a enormement
progresse, PHP reste l'inventeur "d'aide a la programmation" pas
forcement tres catholiques

- magic quoting: qui backslash toute les strings pour eviter l'injection SQL
Complètement stupide vu que selon la base de donnée qu'on utilise les
caractères a backslasher sont différents, et puis bon on a pas envie de
TOUT backslasher non plus.
Une fois je me suis retrouver a heberger un site perso sur un hebergeur
qui ne permettait pas de desactiver ce truc, et j'ai du mettre des
stripslahses() partout pour ne plus avoir de probleme d'affichage.

C'est fait dans le dos de l'utilisateur, et on n'y comprend rien.

- register globals: en debut de script toutes les variables en GET et
POST sont déclarées \o/
l'utilisateur peut donc declarer des variables dans nos scripts.
C'est la fete!

- une variable est estimée fausse si elle vaut "", 0, null ou false ou
qu'elle n'existe pas.
Donc en gros on était tente de faire !$variable pour tester l'existence
d'une variable (oui c'est mal! mais qd on debute on debute), et se
retrouvait avec des bugs incompréhensibles....

et mention speciale a dl() qui permettait de charger des .so/.dll sur la
machine de l'hebergeur, et de s'en servir (jusqu'à que le safe mode soit
ajouté pr controler la chose, c'est vrai que c'est pratique des fois dl())

Ceci dit on est bien d'accord sur un point: depuis PHP5 et 6, tout ceci
est fini, et j'attend beaucoup des versions a venir.

Peut être aura t'on la même évolution que de Action Script 2 a 3 (AS et
PHP n'ont rien a voir mais bon):
un langage qui devient explicitement typé, perso j'ai bien aim'e, meme
si la communauté Flash a l'air d'avoir detest'e.
(je n'ose pas ecrire statiquement type, ce n'est pas le cas pour l'AS)

Post by Sylvain SF

Post by Eloims
ca met la possibilité de publier du contenu a la portee de presque
tout le monde

c'est en effet une caractéristique plus significative.
comparé à des J2E, WebObjects, ou autre dotnetteries MS, PHP a
l'énorme avantage de permettre gratuitement avec n'importe quel
serveur libre d'implémenter ce qui requiert moultes dépenses ailleurs.

Post by Eloims
Genre en effet, a chaque requete on repart de zero, tout les fichiers
sont re-pars'es, la config de l'appli qui tourne recharg'ee etc

choix du langage, pas défauts du langage.
on parle ici de pages ouèbes générées par un serveur http, le module
PHP devrait-il garder un contexte (d'un des N visiteurs) en mémoire
alors que rien ne permet de savoir si la prochaine page (requête)
sera faite dans 2 sec. ou 2 heures ?
doit-on cacher ce contexte alors que le serveur apache d'une part et
l'OS d'autre part participent déjà à la gestion de mise en cache des
fichiers souvent lus ?

Je ne parle pas de contexte attache a un utilisateur precis ($_SESSION
qui est serialise entre chaque requete, a moin qu'on aille changer les
handler <= ca c'est bien fait par contre).

Dans le cas des framework, clairement oui.
Une grande partie du contexte est partagee par tous les utilisateurs de
l'application, et php se voit obliger de recharger le tout a chaque requête.

Je suis effare par la quantité de fichiers de config ayant toujours le
même contenu que php doit reparser a chaque requête avec Symfony (ou
autre framework php... c'est clairement pas la concurrence qui manque!
et ne parlons pas des CMS).


Rien a voir, d'ailleur, mais j'y pense maintenant.
Un avantage enorme de PHP: la quantitee de projets opensource disponible.
On a vraiment tout sous la main, frameworks, cms, bbs, blogs etc
et avec les lib qui sont fournies avec php on peut par exemple manipuler
et generer des images en quelques lignes

Quand on se lance sur un projet, la majoritee du truc est clairement
souvent deja faite.
C'est moin le cas en Python ou Ruby on Rails (frameworks mis a part,
peut etre plus, mais je me suis pas assez renseign'e)

Post by Sylvain SF

Post by Eloims
Bon il y a des histoires pour faire du byte code avec le php je crois?
ou au moin des systeme de cache, mais c'est une fausse solution pour
recuperer d'un cote ce qu'on pert de l'autre.

hmm, non, une compilation des définitions de classes PHP serait en
effet un truc significatif pour améliorer le traitement des scripts,
bcp plus que le cache des instances de ces classes.

bon ok je vais me cacher.

[Bruno Desthuilliers]

Eloims a écrit :
(snip)

Post by Eloims
Rien a voir, d'ailleur, mais j'y pense maintenant.
Un avantage enorme de PHP: la quantitee de projets opensource disponible.
On a vraiment tout sous la main, frameworks, cms, bbs, blogs etc

La plupart de ceux que j'ai vu souffrant du problème évoqué plus plus
haut, à savoir une qualité plus que moyenne...

(snip)

Post by Eloims
Quand on se lance sur un projet, la majoritee du truc est clairement
souvent deja faite.
C'est moin le cas en Python ou Ruby on Rails (frameworks mis a part,
peut etre plus, mais je me suis pas assez renseign'e)

En ce qui concerne Python, je crains en effet que tu ne te sois pas très
bien renseigné (c'est un euphémisme).

[Sylvain SF]

Post by Eloims

Post by Sylvain SF
savoir que certains peuvent commettre çi ou ça avec tel langage
n'apprend pas grd chse sur ce langage - ce n'est pas un inconvénient
*de* PHP si certains codent comme des anes.

on est d'accord, mais ca ne change rien au faits.

aux faits ou à tes convictions (faut-il dire a-priori ?)

Post by Eloims
Certains langages sont plus propices a faire des cochoneries que d'autres.

non, certains programmeurs sont plus propices ...

certains langages, parce typés, ou parce que compilés sont aptes
à *détecter* certaines erreurs de codage mais pas à empécher les
cochoneries qui restent humaines (trop humaines).

Post by Eloims
Bien que ce n'est plus le cas aujourd'hui vu que PHP a enormement
progresse, PHP reste l'inventeur "d'aide a la programmation" pas
forcement tres catholiques

hein ??

Post by Eloims
- magic quoting: qui backslash toute les strings pour eviter l'injection SQL
Complètement stupide vu que selon la base de donnée qu'on utilise les
caractères a backslasher sont différents, et puis bon on a pas envie de
TOUT backslasher non plus.

on a p.e. surtout pas envie de balancer comme requete SQL tout ce
qui serait poster ou transmis à une requête http, si des idiots le
font, ils feraient les mêmes cochoneries en ASP - again sans rapport
avec PHP.

Post by Eloims
Une fois je me suis retrouver a heberger un site perso sur un hebergeur
qui ne permettait pas de desactiver ce truc, et j'ai du mettre des
stripslahses() partout pour ne plus avoir de probleme d'affichage.

"ce truc" ?? balancer des rqst SQL tout seul ??
jamais vu ça de la part du parseur PHP.

Post by Eloims
C'est fait dans le dos de l'utilisateur, et on n'y comprend rien.

apparemment.

Post by Eloims
l'utilisateur peut donc declarer des variables dans nos scripts.

via un URL ? tu peux m'expliquer comment ?

Post by Eloims
Je suis effare par la quantité de fichiers de config ayant toujours le
même contenu que php doit reparser a chaque requête avec Symfony (ou
autre framework php... c'est clairement pas la concurrence qui manque!
et ne parlons pas des CMS).

la plupart de ces framework me semble destiné aux personnes
incapables de définir leur propre modèle SQL et sont souvent
des usines à gaz - corollaire l'injection SQL peut en effet
y être facile (puisque c'est bati sur cette mauvaise solution)
et ça peut être en effet lourdingue à souhait; mais c'est un
choix de ces libs, pas du langage.

Sylvain.

[Mihamina Rakotomandimby]

Post by Sylvain SF

Post by Eloims
Bien que ce n'est plus le cas aujourd'hui vu que PHP a enormement
progresse, PHP reste l'inventeur "d'aide a la programmation" pas
forcement tres catholiques

hein ??

PHP est "simple"
PHP est "orienté Web"
Il y a _plein_ d'exemples PHP accessible pour les débutants (avec leurs
avantages et laurs inconvénients) sur le Web

Donc
PHP permet de faire des programmes interessants pour le "débutant" qu'il
peut rapidement publier sur le Web pour montrer ce qu'il sait faire.

[Thierry B\.]

--{ Mihamina Rakotomandimby a plopé ceci: }--

Post by Mihamina Rakotomandimby
PHP est "simple"
PHP est "orienté Web"
Il y a _plein_ d'exemples PHP accessible pour les débutants (avec leurs
avantages et laurs inconvénients) sur le Web

On est pas vendredi, là ?

Post by Mihamina Rakotomandimby
Donc
PHP permet de faire des programmes interessants pour le "débutant" qu'il
peut rapidement publier sur le Web pour montrer ce qu'il sait faire.

Non, on est pas vendredi...

<soupir>

[Mickael Wolff]

Post by Sylvain SF

Post by Eloims
l'utilisateur peut donc declarer des variables dans nos scripts.

via un URL ? tu peux m'expliquer comment ?

http://example.com/whore.php?toto=tutu
Avec register_global à On, bien sûr.

[Sylvain SF]

Post by Mickael Wolff

Post by Sylvain SF

Post by Eloims
l'utilisateur peut donc declarer des variables dans nos scripts.

via un URL ? tu peux m'expliquer comment ?

http://example.com/whore.php?toto=tutu
Avec register_global à On, bien sûr.

beuhhh, je n'avais pas remarqué ce détail - étant tjrs à Off,
récupérant toutes mes variables d'états de $_SESSION et tous
les paramètres de $_GET (avec tests de pertinence et validité)

pourquoi diantre avoir inventé ce passage de variables ?!

Sylvain.

[Mickael Wolff]

Post by Sylvain SF
pourquoi diantre avoir inventé ce passage de variables ?!

Pour simplifier la vie aux pirates^Wprogrammeur !

[BertrandB]

Post by Bruno Desthuilliers
<troll>En bref, PHP, c'est le nouveau basic. </troll>

Là je vais demander des droits ;-)

A mon avis ce qu'il manque leplus et de loin, c'est un style de
programmation recommandé.
Sur certains morceaux de code pfff on croirait du perl donc ça a beau
être en GPL de là à vouloir y mettre les pattes.

actuellement on a la syntaxe alternative et la syntaxe complexe des
chaînes qui sont sous exploitées et permettrait je pense une écriture
plus propre

Sur le langage je me contenterai de dire que je préfère et de loin
python et javascript.

[Mihamina Rakotomandimby]

Post by Bruno Desthuilliers
Il y a aussi le modèle d'exécution, qui fait qu'il faut reconstruire le
monde entier à chaque requête.

N'est-ce pas HTTP qui est "en cause"? c'est HTTP qui est conçu comme ça.

[Bruno Desthuilliers]

Post by Mihamina Rakotomandimby

Post by Bruno Desthuilliers
Il y a aussi le modèle d'exécution, qui fait qu'il faut reconstruire
le monde entier à chaque requête.

N'est-ce pas HTTP qui est "en cause"? c'est HTTP qui est conçu comme ça.

Non. Tu confonds le caractère 'sans état' du protocole HTTP avec le
modèle d'exécution du serveur. Si tu prend des frameworks Python comme
Django, Pylons etc, tu a généralement un (ou plusieurs, selon la méthode
de déploiement) interpréteurs Python lancés, qui restent actifs entre
deux requêtes, et conservent tous les imports (bibliothèques,
configuration etc) en mémoire. Il n'y plus guère que quelques objets à
instancier pour servir une requête. Alors qu'en PHP, il faut *tout*
recharger à chaque requête.

Après, selon le cas d'utilisation, la complexité de l'appli, le type
d'hébergement etc, l'une ou l'autre solution présentent des avantages et
des inconvénients. L'un des inconvénients du modèle PHP est qu'il ne se
prête guère à trop d'abstraction, puisque la quantité de code à charger
et parser à chaque requête peut facilement devenir prohibitive
(accessoirement, l'absence d'espace de nommage digne de ce nom n'aide
pas non plus de ce point de vue là). Essayer de copier en PHP les archi
des serveurs d'applications basés sur des long runnning process est AMHA
une erreur - ni le langage (intrinsèquement procédural malgré la greffe
façon OGM d'un modèle objet essentiellement pompé sur Java), ni le
modèle d'exécution.ne s'y prêtent. Enfin, AMTHA, n'est-ce pas...

[Pascal PONCET]

Post by Mihamina Rakotomandimby
PHP fait partie des langages que j'utilise souvent.
Mais je n'ai pas encore ma petite idée de ses avantages et inconvénients.

Bonjour,

Vaste sujet ! Pour ma part, j'ai toujours été déçu par les comparatifs.
Je pense que la réponse ne peut être trouvée que par soi-même, car cela
dépend beaucoup trop du cadre dans lequel on va utiliser le langage.

Bien sûr, PHP s'utilisera surtout dans le cadre de la programmation Web.
Mais entre un petit site Web avec 2 ou 3 pages dynamiques (voire une
seule, comme le formulaire de contact) et une grosse application Web
frontale avec un back-office, c'est le jour et la nuit.

Ces contraintes se retrouveront d'ailleurs dans le style de
programmation : du fonctionnel mêlé au Html pour les cas simples,
jusqu'au framework objet complètement séparé du contenu visuel, genre
MVC, pour les cas plus complexes.

Eventuellement, on pourrait citer comme qualité générale la souplesse de
PHP, permettant de traiter ces cas extrêmes avec le même type de
technologie. Mais pour d'autres développeurs, ce manque de
spécialisation apparaîtra comme un défaut majeur.

On en revient donc à l'expérience personnelle, seule garante d'une
réponse vraiment critique à la question.
Vous pourrez quand-même trouver quelques témoignages intéressants sur le
Web, comme à cet endroit "http://www.journaldunet.com/developpeur/php",
ou là (in english, sorry !)
"http://blogs.techrepublic.com.com/programming-and-development/index.php?cat=149"
et, bien sûr, en cherchant dans l'historique de ce newsgroup où nous sommes.

Bonne chance,
Pascal

[JP]

Bonjour,
Je suis "choqué par certaines des positions que j'ai lu dans ce fil.
SI vous aimez les langages très structurés et "concus" pour éviter les bugs
et aider la maintenance ultérieure du code, vous avez ADA.
Tiens c'est bizzare, personne n'en a parlé.
Serait-ce parce que ce langage, concu pour être très "sécuritaire", est du
coup très très cher à coder ? et qu'en plus, l'absence de bug reste encore à
démontrer.
Comme quelqu'un l'a dit, on parle là de développements destinés à tourner
sur du WEB "grand public". C'est à dire de très nombreux accès concurents,
beaucoup d'erreurs de manipulation de la part des utilisateurs, des débuts
de traitements jamais terminés,...
Il semble que PHP, avec tous les défauts que vous avez cité reste quand même
excellement adapté à cet environnement très flou qu'est le WEB.

Je pense que concernant ta demande initiale, comme sur toutes les demandes
de ce type que j'ai vu dans les différents forums, la solution est simple.
Soit tu es déjà partisant de PHP et tu le restera, soit tu y est déjà opposé
et tu le restera.

PHP est excellent pour des réalisations qui ne nécessitent pas la perfection
absolu. Mais y-a-til vraiment des réalisations qui nécessitent la perfection
absolue.
La qualité d'une réalisation doit être mise en regard du coût associé. Et
là, le couple qualité/coût de PHP écrase toutes les autres solutions.

Oui, PHP est plein de problèmes (les développeurs étant l'un de ces
problèmes), mais sont coût d'acquisition, d'apprentissage, d'utilisation (cf
bibliotèques disponibles) le rend très nettement supérieur aux autres
langages.

Concernant les "bonnes pratiques", je suis surpris que vous n'ayez pas cité
l'initiative PEAR.

Si vous voulez "bien travailler avec PHP, allez voir PEAR, avec les défauts
inhérents à un framework.

Post by Mihamina Rakotomandimby

Post by Mihamina Rakotomandimby
PHP fait partie des langages que j'utilise souvent.
Mais je n'ai pas encore ma petite idée de ses avantages et inconvénients.

Bonjour,
Vaste sujet ! Pour ma part, j'ai toujours été déçu par les comparatifs.
Je pense que la réponse ne peut être trouvée que par soi-même, car cela
dépend beaucoup trop du cadre dans lequel on va utiliser le langage.
Bien sûr, PHP s'utilisera surtout dans le cadre de la programmation Web.
Mais entre un petit site Web avec 2 ou 3 pages dynamiques (voire une
seule, comme le formulaire de contact) et une grosse application Web
frontale avec un back-office, c'est le jour et la nuit.
Ces contraintes se retrouveront d'ailleurs dans le style de programmation
: du fonctionnel mêlé au Html pour les cas simples, jusqu'au framework
objet complètement séparé du contenu visuel, genre MVC, pour les cas plus
complexes.
Eventuellement, on pourrait citer comme qualité générale la souplesse de
PHP, permettant de traiter ces cas extrêmes avec le même type de
technologie. Mais pour d'autres développeurs, ce manque de spécialisation
apparaîtra comme un défaut majeur.
On en revient donc à l'expérience personnelle, seule garante d'une réponse
vraiment critique à la question.
Vous pourrez quand-même trouver quelques témoignages intéressants sur le
Web, comme à cet endroit "http://www.journaldunet.com/developpeur/php", ou
là (in english, sorry !)
"http://blogs.techrepublic.com.com/programming-and-development/index.php?cat=149"
et, bien sûr, en cherchant dans l'historique de ce newsgroup où nous sommes.
Bonne chance,
Pascal

[Bruno Desthuilliers]

Post by Mihamina Rakotomandimby
Bonjour,
Je suis "choqué par certaines des positions que j'ai lu dans ce fil.

Bienvenu sur usenet.

Post by Mihamina Rakotomandimby
SI vous

Qui "vous" ?

Post by Mihamina Rakotomandimby
aimez les langages très structurés et "concus" pour éviter les
bugs et aider la maintenance ultérieure du code, vous avez ADA.

Oui. Ou OCaml, Haskell, C++ (hum), Java (yuck) etc.

Accessoirement, dois-je en conclure que tu considères php comme langage
qui ne facilite ni la robustesse ni la maintenance ultérieure ?-)

Post by Mihamina Rakotomandimby
Tiens c'est bizzare, personne n'en a parlé.

Oui, c'est bizarre. Peut-être parce que le domaine d'application n'est
pas exactement le même, et que la plupart des contributeurs ont
jusqu'ici préférer se contenter de référence à des langages comparables
(c'est à dire des langages dynamiques de haut niveau couramment employés
pour le même type de développement que php) ?

Post by Mihamina Rakotomandimby
Serait-ce parce que ce langage, concu pour être très "sécuritaire", est
du coup très très cher à coder ?

Effectivement, un développeur ADA coûte généralement plus cher qu'un
développeur php, à l'achat et à l'entretien.

Post by Mihamina Rakotomandimby
et qu'en plus, l'absence de bug reste
encore à démontrer.

Dans le langage ou dans le programme réalisé avec le langage ?

Post by Mihamina Rakotomandimby
Comme quelqu'un l'a dit, on parle là de développements destinés à
tourner sur du WEB "grand public".

Non, de développement web coté serveur, c'est tout.

Post by Mihamina Rakotomandimby
C'est à dire de très nombreux accès
concurents, beaucoup d'erreurs de manipulation de la part des
utilisateurs, des débuts de traitements jamais terminés,...

Je pense qu'une bonne partie des intervenants sur ce newsgroup ont au
moins quelques notions de ce qu'est le développement web. Tiens,
peut-être même qu'il y en a dont c'est le boulot. Etonnant, non ?

Post by Mihamina Rakotomandimby
Il semble que PHP, avec tous les défauts que vous avez cité reste quand
même excellement adapté

Adapté, oui. "excellement", c'est ton avis personnel (auquel tu a bien
évidemment le droit).

Post by Mihamina Rakotomandimby
à cet environnement très flou qu'est le WEB.

"très flou" ? Tu trouve la rcf HTTP "très floue" ? Où est-ce avec
(x)html que tu a des problèmes ?

Post by Mihamina Rakotomandimby
Je pense que concernant ta demande initiale,

Je ne me souviens pas que Pascal - à qui tu réponds - ait formulé une
quelconque demande (en tous cas dans ce thread).

Post by Mihamina Rakotomandimby
comme sur toutes les
demandes de ce type que j'ai vu dans les différents forums, la solution
est simple.
Soit tu es déjà partisant de PHP et tu le restera, soit tu y est déjà
opposé et tu le restera.

Soit c'est blanc, soit c'est noir, en résumé ? Si tu ne perçois pas au
moins toute la gamme de nuances de gris entre les deux (sans parler des
couleurs), tu devrais peut-être envisager de consulter un ophtalmo.

Vois-tu, aussi surprenant que ça puisse te paraître, il y a des
personnes qui utilisent des langages sans nécessairement avoir une
position fanatique ni dans un sens ni dans l'autre. Encore plus
surprenant, il y a des personnes qui sont même capable de voir les
défauts et limitations de leur langage préféré.

Post by Mihamina Rakotomandimby
PHP est excellent pour des réalisations qui ne nécessitent pas la
perfection absolu.

"excellent" selon quels critères ?

Post by Mihamina Rakotomandimby
Mais y-a-til vraiment des réalisations qui
nécessitent la perfection absolue.

Il y a en tous cas des clients qui espèrent que leur site réponde
normalement et ne soit pas hackés toutes les deux minutes. A défaut de
"perfection absolue", on peut au moins viser un minimum de correction,
de robustesse et de sécurité. Ce qui est bien sûr tout aussi possible
avec php qu'avec n'importe quel autre langage turing-complete, à
condition de connaître son outil et de travailler sérieusement. Autre
chose ?

Post by Mihamina Rakotomandimby
La qualité d'une réalisation doit être mise en regard du coût associé.

Certes.

Post by Mihamina Rakotomandimby
Et là, le couple qualité/coût de PHP écrase toutes les autres solutions.

Tu a des chiffres pour appuyer cette affirmation ? Où c'est juste ton
intime conviction ?

Post by Mihamina Rakotomandimby
Oui, PHP est plein de problèmes (les développeurs étant l'un de ces
problèmes),

Les développeurs sont le principal problème quand il s'agit de
programmation, en effet.

Post by Mihamina Rakotomandimby
mais sont coût d'acquisition, d'apprentissage, d'utilisation
(cf bibliotèques disponibles) le rend très nettement supérieur aux
autres langages.

Même question : tu a des chiffres ?

Post by Mihamina Rakotomandimby
Concernant les "bonnes pratiques", je suis surpris que vous n'ayez pas
cité l'initiative PEAR.
Si vous voulez "bien travailler avec PHP, allez voir PEAR, avec les
défauts inhérents à un framework.

J'ai été voir - il y a longtemps déjà -, je suis retourné voir - parce
qu'il fallait que je corrige et/ou fasse évoluer du code basé dessus -,
et tout ce je peux dire (pour avoir utilisé pas mal de frameworks dans
pas mal de langages), c'est que les défauts que j'ai vu à PEAR n'étaient
en rien "inhérent à un framework".


JP, c'est beau, la ferveur et l'enthousiasme, mais des fois, ça nuit un
peu à la crédibilité. La première des bonnes pratiques, c'est de
connaître plusieurs outils, et de savoir choisir l'outil adapté à la
tache à effectuer.

[Patrick 'Zener' Brunet]

Bonjour.

Post by Mihamina Rakotomandimby
PHP fait partie des langages que j'utilise souvent.
Mais je n'ai pas encore ma petite idée de ses avantages
et inconvénients.
Pour le moment, les petites choses que je fais avec (et qui
de toutes façons sont faisable dans presque n'importe quel
langage) ne me permettent pas d'en connaitre ses limites ou
ses grandeurs.
[...] pour qu'on en discute...

Petite contribution d'utilisateur donc:

D'abord sur le contexte:
-----------------------
J'ai un sérieux doute sur le concept du tout-en-ligne, où le serveur héberge
un gros logiciel et le visiteur un simple terminal.
- Si on veut effectivement monter un serveur de "calcul", il faudra a priori
prévoir un serveur dédié et ce process sera écrit avec un langage plus
approprié pour un process (C++ par exemple);
- Par contre le serveur Web qui sert d'interface devrait se limiter à
assembler et servir des pages à partir de contenus précalculés;
- D'ailleurs la plupart des hébergeurs vont vous virer si vous pompez trop
de puissance.

Donc pour assembler et servir des pages:
-----------------------------------------
Tout d'abord, à moins de monter son propre serveur, on choisit parmi ce qui
est disponible chez les hébergeurs, et amha PHP est un standard plus ou
moins incontournable.

Ensuite, PHP est un bon moyen de s'affranchir du chaos des navigateurs mais
aussi des aléas de leur configuration, en leur servant des pages statiques
dynamiquement adaptées côté serveur, de même que les CSS si nécessaire, sur
la base d'un corpus unique et d'un contexte stocké dans une session.

Sur mes sites par exemple, il y a bien un zeste de Javascript, et même des
béquilles en HTC pour IE, et je me réserve aussi l'option d'utiliser des
inserts Flash (la détection est prévue), mais rien de tout ça n'est
indispensable. Ca fonctionne même avec les cookies désactivés.
Même les images peuvent être disponibles en plusieurs tailles, sélectionnées
en fonction de la largeur de l'écran du visiteur.

Parce que je ne crois pas qu'on puisse forcer l'utilisateur à installer
Java, Flash, une police ou toute autre extension s'il n'en a pas envie, et
cette envie ne peut lui venir qu'en ayant pu visiter le site en mode
dégradé. Donc il faut rester utilisable en 100% server-side.

Bien sûr, la souplesse que j'ai décrite nécessite un peu de calcul côté
serveur, mais c'est assez raisonnable parce que je l'ai optimisé (notamment
ces fonctions ne nécessitent pas de base de données mySQL, et les paramètres
utilisateurs sont détectés une seule fois puis conservés dans sa session).
De ce fait, le code ne fait globalement qu'assembler des chaînes et
concaténer des blocs de contenu.

Evidemment je préfèrerais un vrai langage à objets, compilé avec toutes les
validations, plutôt qu'un script avec son inéluctable permissivité et les
erreurs à retardement qui peuvent en résulter si on ne revérifie pas tout à
chaque modif...

* Mais donc finalement pour cette tâche relativement bateau, PHP se
débrouille assez bien.

A vrai dire, ce qui arrangerait davantage je crois, et supprimerait bien des
acrobaties pesantes, c'est un header normalisé (je sais, je rêve) dans
lequel le navigateur transmettrait au serveur ses "device capabilities"
(taille d'écran, couleurs, taille de police, formats d'image...) en tenant
compte des options d'accessibilité de l'utilisateur).
Ca éviterait pas mal de magie vaudou à partir du UserAgent et des quelques
infos HTTP_XXX qui restent plus ou moins fiables malgré les bugs (IE7 et les
PNG par exemple) et les pratiques de soi-disant sécurité.

--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.eu/ContactMe

[Olivier Miakinen]

Bonjour,

Post by Patrick 'Zener' Brunet
[...]
Tout d'abord, à moins de monter son propre serveur, on choisit parmi ce qui
est disponible chez les hébergeurs, et amha PHP est un standard plus ou
moins incontournable.

Cela fait donc partie de ses avantages : il est disponible chez à peu
près tous les hébergeurs. Ce n'est pas le cas d'ADA, par exemple, pour
répondre à JP¹.

Post by Patrick 'Zener' Brunet
Ensuite, PHP est un bon moyen de s'affranchir du chaos des navigateurs mais
aussi des aléas de leur configuration, en leur servant des pages statiques
dynamiquement adaptées côté serveur, de même que les CSS si nécessaire, sur
la base d'un corpus unique et d'un contexte stocké dans une session.

Ça, en revanche, ce n'est en rien spécifique à PHP : c'est vrai de
n'importe quel langage côté serveur.

Post by Patrick 'Zener' Brunet
[ Javascript, HTC pour IE, Flash ]

Halte là ! La question de Mihamina n'était peut-être pas complètement
explicite à ce sujet, mais j'ai cru comprendre qu'il souhaitait que l'on
discute des avantages et des inconvénients de PHP par rapport à d'autres
langages *pour le même usage* (pas forcément pour le web, d'ailleurs),
non pas que l'on discute des avantages et des inconvénients d'un langage
*sur un serveur web* (par exemple PHP) par rapport à *dans un navigateur
web* (par exemple JavaScript, HTC ou Flash).

Post by Patrick 'Zener' Brunet
[ snip du reste ]

[Patrick 'Zener' Brunet]

Bonjour.

Post by Olivier Miakinen

Post by Patrick 'Zener' Brunet
[...]
Ensuite, PHP est un bon moyen de s'affranchir du chaos des navigateurs
mais aussi des aléas de leur configuration, en leur servant des pages
statiques dynamiquement adaptées côté serveur, de même que les CSS
si nécessaire, sur la base d'un corpus unique et d'un contexte stocké

dans

Post by Olivier Miakinen

Post by Patrick 'Zener' Brunet
une session.

Ça, en revanche, ce n'est en rien spécifique à PHP : c'est vrai de
n'importe quel langage côté serveur.

Post by Patrick 'Zener' Brunet
[ Javascript, HTC pour IE, Flash ]

Halte là ! La question de Mihamina n'était peut-être pas complètement
explicite à ce sujet, mais j'ai cru comprendre qu'il souhaitait que l'on
discute des avantages et des inconvénients de PHP par rapport à d'autres
langages *pour le même usage* (pas forcément pour le web, d'ailleurs),
non pas que l'on discute des avantages et des inconvénients d'un langage
*sur un serveur web* (par exemple PHP) par rapport à *dans un
navigateur web* (par exemple JavaScript, HTC ou Flash).

Post by Patrick 'Zener' Brunet
[ snip du reste ]

Tout à fait, mais c'est précisément pourquoi j'ai tenu à préciser l'usage
sur lequel je fonde mon avis:
- Je ne fais pas de traitements complexes côté serveur,
- Uniquement de l'assemblage de pages à partir de contenus précalculés,
- Dans le but de ne compter sur **aucune aide côté client**,
- Tout en servant des pages sur mesure par rapport à ce client.

Donc en fait c'est de la pure interface graphique
- dont les organes se limitent aux possibilités de base de HTML,
- dont toute la logique est déportée sur le serveur,
- *mais pas plus*, je suis convaincu qu'un traitement important (ce que
j'appelle process) ne devrait *pas* être écrit en PHP mais plutôt dans un
vrai langage adapté à du process et sur un autre serveur que le serveur Web
qui lui sert d'interface.

Ce process peut être une base de données (très souvent sur le Web) mais
aussi un outil de simulation, de calcul, etc.

Telle était l'essence de mon propos (et nous savons que l'essence a une
grande valeur :-), fondé sur une copieuse expérience de la conduite de
process d'une part, et des IHM d'autre part.

Il est clair que les démons qui font la logique d'une interface sont de
complexité tout à fait abordable pour un langage de script tel que PHP, mais
pour le "moteur" d'un vrai process, ce langage me paraît très insuffisant et
donc casse-gueule.

D'ailleurs j'en ai autant pour tous les langages de script (Perl, Python et
les autres) et encore davantage pour le joyeux mixage! Faut vraiment adorer
les malloc, les spawn et le parsing de chaînes, mais aussi les impacts
cachés lors des évolutions...
Pour faire du process, rien ne vaut un langage qui se compile avec sévérité
maximale, qui est optimisé, puis génère *un* code qui tourne en natif sur la
plateforme.
Et bien sûr un langage riche mais sans aucune tolérance envers les oublis ou
négligences.

** A ma connaissance, aucun langage orienté Web ne satisfait à ça, c'est
pourquoi je dis qu'il ne *faut pas* faire de process dans un tel contexte.

Et donc si on se limite à l'IHM server-side, PHP me paraît un bon choix.
Des concurrents sérieux et non propriétaires ?

--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.eu/ContactMe

[Bruno Desthuilliers]

Patrick 'Zener' Brunet a écrit :
(snip)

Post by Patrick 'Zener' Brunet
Tout à fait, mais c'est précisément pourquoi j'ai tenu à préciser l'usage
- Je ne fais pas de traitements complexes côté serveur,
- Uniquement de l'assemblage de pages à partir de contenus précalculés,
- Dans le but de ne compter sur **aucune aide côté client**,
- Tout en servant des pages sur mesure par rapport à ce client.
Donc en fait c'est de la pure interface graphique
- dont les organes se limitent aux possibilités de base de HTML,
- dont toute la logique est déportée sur le serveur,

En bref, tu utilises PHP comme un langage de template un peu évolué ?

Post by Patrick 'Zener' Brunet
- *mais pas plus*, je suis convaincu qu'un traitement important (ce que
j'appelle process) ne devrait *pas* être écrit en PHP mais plutôt dans un
vrai langage

Attention, tu sous-entends que php n'est pas "un vrai langage", ça va
choquer JP !-)

Post by Patrick 'Zener' Brunet
adapté à du process et sur un autre serveur que le serveur Web
qui lui sert d'interface.

Accessoirement, la principale utilisation de PHP, hormis du templating
et quelques accès fichiers (donc via les lib système, donc pas de gros
surcoût), est d'accéder à une base (My le plus souvent)SQL. Si c'est
codé par quelqu'un qui sait structurer une base relationnelle et écrire
une requête SQL, les seuls traitements assurés par PHP relèvent de la
présentation (et de la validation des données pour les formulaires).
Pour l'envoi de web, on reste dans le même cadre - le gros du travail
est délégué a une autre appli.

(snip)

Post by Patrick 'Zener' Brunet
Il est clair que les démons qui font la logique d'une interface sont de
complexité tout à fait abordable pour un langage de script tel que PHP, mais
pour le "moteur" d'un vrai process, ce langage me paraît très insuffisant et
donc casse-gueule.

Là, je me demande si tu a beaucoup d'expérience en matière de
réalisation d'interfaces utilisateurs un tant soit peu évoluées. Pour
pas mal d'applis, la complexité de l'interface (au niveau conception /
programmation) est plus complexe que le "moteur".

Post by Patrick 'Zener' Brunet
D'ailleurs j'en ai autant pour tous les langages de script (Perl, Python et
les autres) et encore davantage pour le joyeux mixage! Faut vraiment adorer
les malloc, les spawn et le parsing de chaînes, mais aussi les impacts
cachés lors des évolutions...
Pour faire du process, rien ne vaut un langage qui se compile avec sévérité
maximale, qui est optimisé, puis génère *un* code qui tourne en natif sur la
plateforme.

C'est un point de vue. De fait, dans pas mal de cas, le typage statique
et la compilation en natif permettent des optimisations très difficiles
pour un langage dynamique (j'attends toujours une définition complète et
non-ambigüe du terme 'langage de script'). Si le "moteur" 1/ effectue
des calculs intensifs et 2/ a des specs stables dans le temps, et si 3/
on n'a pas de souci majeur de portabilité, alors effectivement, un
langage à typage statique pour lequel existe une implémentation compilée
en natif *peut* être un meilleur choix.

Post by Patrick 'Zener' Brunet
Et donc si on se limite à l'IHM server-side, PHP me paraît un bon choix.
Des concurrents sérieux et non propriétaires ?

Javascript, Ruby, Python, Perl, entre autres.

[Patrick 'Zener' Brunet]

Bonjour.

Navré pour le délai, boulot...

Post by Bruno Desthuilliers
(snip)

Post by Patrick 'Zener' Brunet
Tout à fait, mais c'est précisément pourquoi j'ai tenu à préciser
- Je ne fais pas de traitements complexes côté serveur,
- Uniquement de l'assemblage de pages à partir de contenus
précalculés,
- Dans le but de ne compter sur **aucune aide côté client**,
- Tout en servant des pages sur mesure par rapport à ce client.
Donc en fait c'est de la pure interface graphique
- dont les organes se limitent aux possibilités de base de
HTML,
- dont toute la logique est déportée sur le serveur,

En bref, tu utilises PHP comme un langage de template un
peu évolué ?

En fait un langage de template est une coquille *dans laquelle* on met des
blocs de contenu.
Ici l'interaction est plus forte, car ce contenu contient lui-même des
inserts en PHP.

En fait la précompilation (SED, M4, makefile...) les associe beaucoup plus
étroitement, c'est une fusion où ne restent en PHP que les éléments variant
au runtime.

Post by Bruno Desthuilliers

Post by Patrick 'Zener' Brunet
- *mais pas plus*, je suis convaincu qu'un traitement important
(ce quej'appelle process) ne devrait *pas* être écrit en PHP
mais plutôt dans un vrai langage

Attention, tu sous-entends que php n'est pas "un vrai langage", ça va
choquer JP !-)

J'ai dit: "un vrai langage adapté à du process" ;-)
Aucun langage n'est universel, et j'affirme que PHP n'est pas le meilleur
choix pour faire du process.

[...]

Post by Bruno Desthuilliers

Post by Patrick 'Zener' Brunet
Il est clair que les démons qui font la logique d'une interface
sont de complexité tout à fait abordable pour un langage de
script tel que PHP, mais pour le "moteur" d'un vrai process,
ce langage me paraît très insuffisant et donc casse-gueule.

Là, je me demande si tu a beaucoup d'expérience en matière
de réalisation d'interfaces utilisateurs un tant soit peu évoluées.
Pour pas mal d'applis, la complexité de l'interface (au niveau
conception /programmation) est plus complexe que le "moteur".

C'est selon mon expérience la grosse erreur qui conduit à cette course au
St Graal que serait une librairie d'interface capable de se déguiser en
Windows, en Motif, en KDE, en Gnome et en Mac à la fois, en mimant bien sûr
tous les comportements standards.
J'ai usé 6 ans de ma vie à poursuivre ce fantôme :-(

Il est vrai que les cliquodromes des vendeurs d'IHM font tout pour inciter à
disperser la logique de son process dans les démons de l'interface, et cette
facilité a de lourdes conséquences. Spécialement quand elle devient une
culture naturelle s'appliquant aussi là où on a la main.

C'est pourquoi je "milite" pour une approche plus souple, orientée MVC, avec
une part maximale de M.

Amha, l'interface doit être un produit séparé et totalement substituable
sans remettre en question le moteur.

Mais bien sûr ce rapport de taille est relatif.
Si le "process" se limite à une requête SQL dont on affiche simplement le
résultat, alors le moteur est en fait la base de données, et ce qu'on écrit
est la pure interface. Ca doit représenter la plus grande partie du Web,
hors gros sites commerciaux ou de services.

[...]

Post by Bruno Desthuilliers

Post by Patrick 'Zener' Brunet
Et donc si on se limite à l'IHM server-side, PHP me paraît un bon choix.
Des concurrents sérieux et non propriétaires ?

Javascript, Ruby, Python, Perl, entre autres.

Javascript côté serveur ? Jamais de la vie, c'est déjà assez .erdique côté
client.
La moindre faute de frappe, et on s'aperçoit par hasard qu'il manque un truc
dans la page parce qu'un des scripts a échoué en silence, ensuite on cherche
l'erreur par dichotomie...
A moins que dans une implémentation côté serveur on ait de vrais diagnostics
?

Je viens de changer d'hébergeur. En cherchant du PHP, le dilemme s'est
réduit à la question financière et au multidomaine, et la migration se fait
sans accrocs (avec les variantes de version et les paramétrages de sécurité,
on se méfie un peu).

Ils ont C, Perl et Python, et Ruby (sans ses rails je crois) dont ils ont un
peu honte (très lent)...
J'essaierai de jouer avec quand j'aurai le temps, c'est promis :-)
Mais avec un seul à la fois, Frankenstein me pardonne.

--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.eu/ContactMe

[Bruno Desthuilliers]

Patrick 'Zener' Brunet a écrit :

Note au modérateur : je crains que ce ne soit essentiellement HS - je ne
serais donc pas vexé si c'est rejeté.

Post by Patrick 'Zener' Brunet
Bonjour.
Navré pour le délai, boulot...

Post by Bruno Desthuilliers
(snip)

Post by Patrick 'Zener' Brunet
Tout à fait, mais c'est précisément pourquoi j'ai tenu à préciser
- Je ne fais pas de traitements complexes côté serveur,
- Uniquement de l'assemblage de pages à partir de contenus
précalculés,
- Dans le but de ne compter sur **aucune aide côté client**,
- Tout en servant des pages sur mesure par rapport à ce client.
Donc en fait c'est de la pure interface graphique
- dont les organes se limitent aux possibilités de base de
HTML,
- dont toute la logique est déportée sur le serveur,

En bref, tu utilises PHP comme un langage de template un
peu évolué ?

En fait un langage de template est une coquille *dans laquelle* on met des
blocs de contenu.

Pour moi, c'est plutôt un texte statique avec des parties dynamiques.
Mais bon...


(snip)

Post by Patrick 'Zener' Brunet

Post by Bruno Desthuilliers

Post by Patrick 'Zener' Brunet
Il est clair que les démons qui font la logique d'une interface
sont de complexité tout à fait abordable pour un langage de
script tel que PHP, mais pour le "moteur" d'un vrai process,
ce langage me paraît très insuffisant et donc casse-gueule.

Là, je me demande si tu a beaucoup d'expérience en matière
de réalisation d'interfaces utilisateurs un tant soit peu évoluées.
Pour pas mal d'applis, la complexité de l'interface (au niveau
conception /programmation) est plus complexe que le "moteur".

C'est selon mon expérience la grosse erreur qui conduit à cette course au
St Graal que serait une librairie d'interface capable de se déguiser en
Windows, en Motif, en KDE, en Gnome et en Mac à la fois, en mimant bien sûr
tous les comportements standards.

Je parlais de l'a complexité du code utilisant un GUI toolkit (quelqu'il
soit), pas de l'implémentation du toolkit lui-même...

Post by Patrick 'Zener' Brunet
J'ai usé 6 ans de ma vie à poursuivre ce fantôme :-(
Il est vrai que les cliquodromes des vendeurs d'IHM font tout pour inciter à
disperser la logique de son process dans les démons de l'interface, et cette
facilité a de lourdes conséquences. Spécialement quand elle devient une
culture naturelle s'appliquant aussi là où on a la main.

Je ne parlais pas non plus spécialement de programmation goret à la VB6
avec toute les logiques (de la présentation aux règles métier)
joyeusement mélangées dans les event handlers.

Post by Patrick 'Zener' Brunet
C'est pourquoi je "milite" pour une approche plus souple, orientée MVC, avec
une part maximale de M.
Amha, l'interface doit être un produit séparé et totalement substituable
sans remettre en question le moteur.

C'est un bel idéal, mais je crains que ça n'en reste un (idéal). On peut
certes (et c'est globalement ce qu'il convient de faire, nous en sommes
d'accord) rendre le modèle aussi intelligent que possible, et éviter
toute dépendence du modèle sur le couple vue-controleur. Ca n'empêchera
pas que certains besoins de l'IHM (ou d'une IHM donnée) nécessitent des
évolutions du modèle - on a beau mettre une barrière, elle n'est jamais
totalement imperméable.

Post by Patrick 'Zener' Brunet
Mais bien sûr ce rapport de taille est relatif.
Si le "process" se limite à une requête SQL dont on affiche simplement le
résultat, alors le moteur est en fait la base de données,

+ le code générant la requête, + le code présentant au couple
vue/controleur le résultat de la requête (données ou erreurs...).

Post by Patrick 'Zener' Brunet
et ce qu'on écrit
est la pure interface.

Laquelle nécessite aussi une gestion (présentation, état des éléments,
communication avec le modèle), gestion qui, dès qu'on sort du CRUD tout
bête, devient rapidement complexe - en tous cas si l'on s'attache à
présenter à l'utilisateur une interface ergonomique, conviviale, et
robute. Et n'oublie pas que pour l'utilisateur, l'IHM *est* le programme.

Post by Patrick 'Zener' Brunet
Ca doit représenter la plus grande partie du Web,

Ca représente surtout, très souvent, la plus grosse part du travail de
développement applicatif.

Post by Patrick 'Zener' Brunet
[...]

Post by Bruno Desthuilliers

Post by Patrick 'Zener' Brunet
Et donc si on se limite à l'IHM server-side, PHP me paraît un bon choix.
Des concurrents sérieux et non propriétaires ?

Javascript, Ruby, Python, Perl, entre autres.

Javascript côté serveur ? Jamais de la vie, c'est déjà assez .erdique côté
client.
La moindre faute de frappe, et on s'aperçoit par hasard qu'il manque un truc
dans la page parce qu'un des scripts a échoué en silence, ensuite on cherche
l'erreur par dichotomie...
A moins que dans une implémentation côté serveur on ait de vrais diagnostics
?

Je pense en effet que tu confonds les problèmes spécifiques à cette
grosse bouse d'IE, les problèmes liés au scripting navigateur en général
(la plupart des navigateurs modernes dignes de ce nom proposant un
debuggueur tout à fait correct) et le langage javascript lui-même.

Post by Patrick 'Zener' Brunet
Je viens de changer d'hébergeur. En cherchant du PHP, le dilemme s'est
réduit à la question financière et au multidomaine, et la migration se fait
sans accrocs (avec les variantes de version et les paramétrages de sécurité,
on se méfie un peu).
Ils ont C, Perl et Python, et Ruby (sans ses rails je crois) dont ils ont un
peu honte (très lent)...

Si c'est la 1.8 (Ruby, je veux dire) et que c'est déployé n'importe
comment, c'est tout à fait possible, en effet. Mais bon, PHP mal
paramétré, servi en CGI, avec par dessus un framework lambda, c'est pas
forcément très performant non plus, hein. PHP fonctionne bien sur des
trucs simples (je veux dire par là du code simple et conçu en comprenant
bien le modèle d'exécution de PHP - pas forcément des applications
triviales).

[Denis Beauregard]

Le 30 Sep 2008 14:26:23 GMT, "Patrick 'Zener' Brunet"

Post by Patrick 'Zener' Brunet
- Par contre le serveur Web qui sert d'interface devrait se limiter à
assembler et servir des pages à partir de contenus précalculés;
- D'ailleurs la plupart des hébergeurs vont vous virer si vous pompez trop
de puissance.

Exemple personnel.

Quand je me suis mis au PHP, j'ai voulu refaire mon site en vrai
PHP, soit la génération de pages au complet à la volée. Mais
chaque page demandait beaucoup de temps et j'ai préféré revenir
en arrière, soit à la génération de toutes les pages d'avance (en
C++ et en local) avec copie de toutes les pages vers le serveur
(ce qui me prend plusieurs heures). Le .php ne servait alors qu'à
inclure les bannières et l'anti-aspirateur (j'ai plus de 90 000
pages...).

Par contre, dans une autre application, où il y aurait eu plus
d'un million de pages pré-générées, je préfère de beaucoup y aller
à la volée !

La vraie question serait alors non pas de se demander si PHP est
bien, mais quelle est la meilleure stratégie en fonction de
l'application.


Denis

[Patrick 'Zener' Brunet]

Bonjour.

Post by Denis Beauregard
Le 30 Sep 2008 14:26:23 GMT, "Patrick 'Zener' Brunet"

Post by Patrick 'Zener' Brunet
- Par contre le serveur Web qui sert d'interface devrait se limiter
à assembler et servir des pages à partir de contenus précalculés;
- D'ailleurs la plupart des hébergeurs vont vous virer si vous

pompez trop de puissance.
Exemple personnel.
Quand je me suis mis au PHP, j'ai voulu refaire mon site en vrai
PHP, soit la génération de pages au complet à la volée. Mais
chaque page demandait beaucoup de temps et j'ai préféré revenir
en arrière, soit à la génération de toutes les pages d'avance (en
C++ et en local) avec copie de toutes les pages vers le serveur
(ce qui me prend plusieurs heures). Le .php ne servait alors qu'à
inclure les bannières et l'anti-aspirateur (j'ai plus de 90 000
pages...).
Par contre, dans une autre application, où il y aurait eu plus
d'un million de pages pré-générées, je préfère de beaucoup
y aller à la volée !
La vraie question serait alors non pas de se demander si PHP
est bien, mais quelle est la meilleure stratégie en fonction de
l'application.

Il y a aussi le temps de service de la page...

Pour mes sites, je pratique une précompilation des sources en usine, à
partir de SED, M4 et divers utilitaires que j'ai écrits, le tout piloté par
un vrai makefile (donc 100% automatisé).

Ca permet de synthétiser le HTML+PHP+CSS+JS etc. en figeant toutes les
options qui doivent l'être au compile-time.

Et donc PHP n'intervient plus au runtime que pour le moteur (sessionning,
sécurité, sections calculées) et pour les options dynamiques (dépendant du
contexte du visiteur).

Ca me permet d'avoir un corpus simplissime, donc facile à fournir, et de
l'intégrer dans une structure de site sophistiquée sans passer par une base
de données ni aucun autre framework.

--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.eu/ContactMe

[Rakotomandimby (R12y) Mihamina]

Post by Patrick 'Zener' Brunet
Pour mes sites, je pratique une précompilation des sources en usine, à
partir de SED, M4 et divers utilitaires que j'ai écrits, le tout piloté par
un vrai makefile (donc 100% automatisé).
Ca permet de synthétiser le HTML+PHP+CSS+JS etc. en figeant toutes les
options qui doivent l'être au compile-time.
Et donc PHP n'intervient plus au runtime que pour le moteur (sessionning,
sécurité, sections calculées) et pour les options dynamiques (dépendant du
contexte du visiteur).
Ca me permet d'avoir un corpus simplissime, donc facile à fournir, et de
l'intégrer dans une structure de site sophistiquée sans passer par une base
de données ni aucun autre framework.

Par curiosité, quel genre de site necessite ce genre de "pratique"?
Genre, celui de la SNCF?

[Bruno Desthuilliers]

Post by Rakotomandimby (R12y) Mihamina

Post by Patrick 'Zener' Brunet
Pour mes sites, je pratique une précompilation des sources en usine, à
partir de SED, M4 et divers utilitaires que j'ai écrits, le tout piloté par
un vrai makefile (donc 100% automatisé).
Ca permet de synthétiser le HTML+PHP+CSS+JS etc. en figeant toutes les
options qui doivent l'être au compile-time.
Et donc PHP n'intervient plus au runtime que pour le moteur (sessionning,
sécurité, sections calculées) et pour les options dynamiques (dépendant du
contexte du visiteur).
Ca me permet d'avoir un corpus simplissime, donc facile à fournir, et de
l'intégrer dans une structure de site sophistiquée sans passer par une base
de données ni aucun autre framework.

Par curiosité, quel genre de site necessite ce genre de "pratique"?
Genre, celui de la SNCF?

Là, c'est très bas comme attaque !-)

[Mickaël Wolff]

Post by Rakotomandimby (R12y) Mihamina
Par curiosité, quel genre de site necessite ce genre de "pratique"?
Genre, celui de la SNCF?

Ce n'est pas sympathique d'insulter Patrick avec ce genre de
remarques. :D

Plus sérieusement, l'ensemble des sites ayant une forte affluence
devraient s'inspirer de ce type de fonctionnement. D'ailleurs, le site
de www.voyages-sncf.com devrait s'y mettre (peut-être le site aura un
fonctionnement fluide à ce moment).