avantages et inconvenient de PHP?

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

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

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>

--
Si je suis descendu, je ne regretterai absolument rien.
La termitière future m'épouvante. Et je hais leurs vertus de robots.
Moi, j'étais fait pour être jardinier.
-- Antoine de Saint-Exupéry - Ecrits de guerre

Le 30 Sep 2008 14:26:23 GMT, "Patrick 'Zener' Brunet"
<use.link.in.signature@ddress.invalid> écrivait dans fr.comp.lang.php:

- 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

Sylvain SF a écrit :

pourquoi diantre avoir inventé ce passage de variables ?!

Pour simplifier la vie aux pirates^Wprogrammeur !
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Bonjour.

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

"Bruno Desthuilliers" <bdesth.quelquechose@free.quelquepart.fr> a écrit dans
le message de news: 48e26fdf$0$22804$426a74cc@news.free.fr...

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

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.

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

[...]

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

[...]

> 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

Bonjour.

"Denis Beauregard" <denis.b-at-francogene.com.invalid@nospam.com.invalid> a
écrit dans le message de news: 6il5e4df4cgtj3ebg50ogushkmud7dksdk@4ax.com...

Le 30 Sep 2008 14:26:23 GMT, "Patrick 'Zener' Brunet"
<use.link.in.signature@ddress.invalid> écrivait dans fr.comp.lang.php:

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

Patrick 'Zener' Brunet wrote:

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?

Rakotomandimby (R12y) Mihamina a écrit :

Patrick 'Zener' Brunet wrote:

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

Rakotomandimby (R12y) Mihamina a écrit :

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

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

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

Bonjour.

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

"Bruno Desthuilliers" <bdesth.quelquechose@free.quelquepart.fr> a écrit dans
le message de news: 48e26fdf$0$22804$426a74cc@news.free.fr...

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

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)

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

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.

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.

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

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.

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.

> [...]

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.

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