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