[Agora-generale] Passage en version 5.0 de PHP

[Stephane LAURENT]

S. Poulain (compte yahoo) a écrit :
>
> L'objet de ma question n'est pas le déboguage de l'application qui est 
> une évolution que l'on compte mener en parallèle
encore un fork du fork ?
Mais il y a combien de versions d'Agora dans la nature ?

<troll>
"Heureusement" que chacun programme dans son coin, sinon, ca serait un 
vrai sapin de noel le CVS !
A quand le "defi du merge" ?
:o)
</troll>

Tristan Rivoallan a écrit :
>
> La programmation orientée objet est une affaire de concepts plus que 
> de fonctionnalités. Agora n'exploite quasiment aucun de ces concepts.
<troll>
Ben oui, ca fait des mois qu'on se tue à le dire : fork inutilement mal 
fait !
Et ce n'est pas une critique de CA qui, j'ai bien compris, a fait ce 
qu'on lui a demandé.
</troll>

Le premier "concept" souhaité etait la surcharge.
On a vu la limite de l'approche objet sur Agora : la gestion des droits 
est certes surchargeable, mais à quel prix ?
Combien de jours/homme pour mettre en place un circuit de validation 
parallele ?
Est-ce vraiment plus "maintenable" d'avoir des classes de 2000 lignes à 
coder ?
Idem pour les "bienfaits" du coté support multibase : il n'y a qu'à voir 
le nombre de bases supportées aujourd'hui pour comprendre qu'il y a un 
pas entre concept et réalité...

Un systeme de surcharge "propre" (cad n'obligeant pas à "forker" une 
librairie complete) est maintenant disponible dans Spip 1.9, qui est 
compatible PHP5, partout(?) ou c'est necessaire, sans pour autant 
imposer de la programmation objet(mais sans l'interdire) : ca s'appelle 
un pipeline et ca n'est pas de l'objet, pourtant ca repond au besoin.

C'est exactement pour les memes mauvaises raisons qu'Agora a "mal forké" 
Spip : prendre un projet en partant de la technique, c'est marcher sur 
la tete !
Un cahier des charges "fonctionnel" qui impose des solutions techniques 
est un mauvais cahier des charges qui menent à un mauvais produit.
Il faut d'abord se demander quel est le besoin fonctionnel (meme au 
niveau des developpeurs) avant de se poser la question de la reponse 
technique à apporter...

Dire "je veux de l'objet", c'est comme dire "je veux du web 2.0"... ca 
ne veut rien dire !
Inclure ahah.js ou del.icio.us dans une page web, ca fait ... des 
fichiers de plus à charger pour l'utilisateur, c'est tout.
Pour rester sur cette illustration, dire "je veux pouvoir changer ca 
sans recharger la page" me semble plus constructif et la bonne reponse 
technique ne sera pas forcement la derniere version de del.icio.us.
La petite "iframe action" a par exemple très bien joué son role pour la 
gestion des statuts et reste sans doute compatible avec plus de 
navigateurs que l'utilisation de HTTPRequest.
Maintenant que Spip utilise massivement "AJAX" (enfin, plutot AJAH), le 
choix s'est porté sur JQuery/Ahah : ne contenant que les fonctionnalités 
réellement exploitées.

Alors à part la legitime compatibilité PHP5, vous voulez quoi ?
de l'optimisation de la memoire ? des traitements ?
la maintenabilité ?
Il faut poser les questions avant d'apporter les reponses !

<troll>
Si vous voulez un CMS programmé en objet qui exploite vraiment ce 
concept, developpez le en java ou C# !
Au moins vous pourrez faire du polymorphisme et gerer des comportements 
differents selon les instances sans avoir à tout dupliquer.
</troll>

J'avais espéré que, à defaut de reconnaitre les erreurs du passé, les 
reflexions étaient maintenant portées sur l'avenir, mais visiblement, 
rien n'a changé.
Comme tout cela est triste et inutilement couteux pour le contribuable...

Cordialement.
Stephane.