avantages et inconvenient de PHP?

Eloims a écrit :

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 ?)

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

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 ??

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

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.

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

apparemment.

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

via un URL ? tu peux m'expliquer comment ?

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.

Sylvain SF wrote:

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.

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.




"Pascal PONCET" <poncet.pascal@club-internet.fr> a écrit dans le message de
news:48dceb38$0$8009$7a628cd7@news.club-internet.fr...

Mihamina Rakotomandimby a écrit :

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?cat9"
et, bien sûr, en cherchant dans l'historique de ce newsgroup où nous
sommes.

Bonne chance,
Pascal

Sylvain SF a écrit :

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.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Bonjour.

"Mihamina Rakotomandimby" <mihamina@mihamina.us> a écrit dans le message de
news: gbi69i$30cg$1@cabale.usenet-fr.net...

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

Bonjour,

Le 30/09/2008 16:26, Patrick 'Zener' Brunet a écrit :

[...]
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¹.

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.

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

[ snip du reste ]

--
Olivier Miakinen

¹ JP, à qui je recommande chaudement la lecture de ceci :
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html

Bonjour.

"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
48e23a0d$1@neottia.net...

Le 30/09/2008 16:26, Patrick 'Zener' Brunet a écrit :
>
> [...]

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

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

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

JP a écrit :

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

Bienvenu sur usenet.

SI vous

Qui "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.

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 ?-)

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) ?

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.

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

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

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.

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 ?

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

à 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 ?

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

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é.

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

"excellent" selon quels critères ?

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 ?

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

Certes.

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 ?

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.

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 ?

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.

Mickael Wolff a écrit :

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.

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

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,

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

- *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 !-)

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)

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".

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.

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.