Je l'ai deja indique avant ailleurs etc...
Pour moi le cahier des charges du kernel pour l'instant tient a peu de chose. Optimisation du code.
Ca sous entend pas forcement le rendre plus rapide (quoique) mais aussi reduire le nombre de ligne de code, reutilisabilite etc...
Le code du kernel aujourd'hui fait ce qu'on lui demande, il a certainement des bugs, certainement des trous de securite (mais la moi j'y connais strictement rien) mais bon en gros il repond aux besoins.
Sauf qu'il est pas reellement Objet, qu'il perd pas mal de temps par endroits et qu'il peut certainement etre plus petit. Et qui dit moins de code dit aussi automatiquement moins de bugs et moins de probleme a maintenir.
A mon humble avis avant d'essayer d'aller de l'avant en rajoutant des fonctionalites il faut deja revoir cette fondation.
De base moi perso j'ai deja corrige 2 bugs que j'ai decouvert dans les classes du kernel et j'ai deja optimise toutes les classes du kernel 4 fois sur les versions 1.14 a 1.17(et ca tourne sans pb chez moi depuis pfuuuuttt....) Mais on peut aller encore plus loin on peut utiliser les idees qui n'ont pas ete poussee jusqu'au bout et on peut reduire tout le code du kernel en utilisant un peu mieux la classe xoopsobject et le handler (j'y ai deja pense suite a une discussion sur sourceforge mais jamais eu le courage de le faire cf
http://sourceforge.net/forum/forum.ph ... d=1563501&forum_id=347994).
Une fois que l'on a fait cela on devrait se retrouver avec un code bien plus leger (en terme de ligne) et faisant la meme chose.
Le but ultime serait a mon sens de reussir a faire en sorte que les requetes n'aient plus a etre ecrites par le dev.
Ca serait un peu plus gourmand (en terme UC) certainement mais ca permettrait de laisser la porte ouverte a d'autres bdd que MySql (normalement le SQL c'est un standard mais certaines bdd ont des petites nuances, typiquement les champs autoincrement n'existent pas dans toutes les bdd). Mais bon meme si on arrive pas a cela, de toutes manieres cela serait normalement toujours du code en moins a ecrire pour les dev de modules.
On peut aussi parler de l'admin en general. En dehors du look actuellement il y a toute une tripotee de code qui n'est pas a sa place et qui empeche d'utiliser les classes de xoopsforms correctement. Il faut concevoir objet et savoir qui a la responsabilite de faire quoi (typiquement rajouter une factory et enlever une tripotee de switch...)
C'est des petites trucs que j'ai vu car je suis tombe sur des os lors de developpement de module. Mais je suis sur qu'il y en a d'autre. C'est ceux qui m'ont gene moi... Je veux dire par la que je pretend pas avoir la science infuse et qu'il y a certainement d'autre car j'ai pas decortique le code complet de xoops, donc si quelqu'un en a vu d'autres qu'il n'hesite pas.
Et cela peut etre fait rapidement, et cela ne change en rien le fonctionnement actuel donc il devrait toujours etre compatible avec tout ce qui a ete fait jusqu'a aujourd'hui.
J'ai vu d'autre petit truc mais il faut reflechir encore. Typiquement j'ai cree un module pour gerer mes MP. Pour cela il m'a fallut corriger le kernel (pb d'heritage) mais il m'a fallu aussi modifier des fichiers au niveau de la racine de xoops. Il faut trouver une solution pour eviter cela de maniere generale (dsl la je l'ai pas trouve en meme temps j'ai pas cherché...). Je veux dire par la il faudrait trouver une solution pour pouvoir changer les classes du noyau sans avoir a reecrire les endroits ou c'est utilise (Injection de dependance ?) et modifier certains fichiers actuel de xoops pour qu'ils soient fait avec des liens dynamiques. Enfin bref il faut que xoops merite ces 2 O
Une fois cela fait et si on a toujours un truc qui tourne
il faudrait essayer de faire en sorte d'utiliser sur les pages gerees par xoops un controleur, de façon a montrer des bonnes pratiques aux dev de modules. Je suis horrifie de voir la tripotee de code sur les index.php des differents modules... mais bon ca c pour le geste et je dois dire que j'ai pas vraiment regarder si c'etait jouables. Au pire il faudrait donner des exemples de modules bien concus.
En terme d'oganisation... je dois dire que ca a jamais ete mon fort
Mais bon deja je vois des pb techniques, typiquement moi je tourne sur du php5 depuis le debut, donc le code que je fais fonctionne sur php5. Faudrait donc soit avoir une plateforme de test php4 pour tester, soit voir si on continue en php4.
Si on decide de se diriger lentement mais surement vers le php5 on peut aller de plus en plus loin (petit a petit) en mettant en place des interfaces etc...
Apres les tests et les validations... en meme temps dans un premier temps le but est de reorganiser le code donc pas forcement enormement de risque, mais il faudra quand meme le tester pour avoir bonne conscience (je veux dire aller un eu plus loin que des tests unitaires).
Ensuite pour le reste de l'organisation, de toutes façons tout depend du nombre de personne...
Pis on peut se rapprocher des teams qui ont envie d'avancer (bresilien, mexicaine...) du coup on peut se greffer sur leur organisation (bon pb de langue...) .
On peut aussi se partager le boulot avec eux.
Enfin bref, on peut deja avancer sans trop d'organisation, de toutes façons quand tu vois ce que cela apporte l'organisation
(ironie inside)
