Je pense, si j'ai bien compris ce qu'a dit garrath, qu'il veut en faite utiliser des class php pour générer des composants graphiques qu'on utiliserait un peu comme des API windows.

Ces composants communs permettraient d'assurer une certaine homogénéité entre les admins des modules et faciliterait le developpement de véritables outils d'administration en se concentrant sur ce qui est important et non plus comme actuellement sur le rendu de la page.

Pour mon point de vue, je vois nettement plus large. Selon moi, xoops doit viser le secteur des CMS ultra modulaires. Pour cela, il faut mettre en place des outils permettant aux concepteurs de modifier très facilement les éléments composants xoops sans etre trop ennuyé lors de la montée de versions (Par exemple, eviter de modifier tout un fichier de class quand j'ai besoin de reecrire seulement une fonction alors qu'il serait possible que j'effectue un héritage de la class officiel. Si tu as compris ce que j'ai expliqué plus haut, tu devrais comprendre l'interet de cette méthode. En cas de MAJ, j'ai juste a verifier que la methode que j'ai surchargé n'est pas été modifié. Si le code est bien documenté et que les methodes sont versionnés, il y'a pas de soucis, ça se voit de suite)

Pour ce qui est de la programmation pur et dur, actuellement xoops est composé :
-d'un noyau
-de composants communs
-de modules que l'on peut ajouter ou retirer qui s'appuie sur certains de ces composants

Dans la pratique, un noyau, on a rarement besoin de le toucher. C'est justement la partie qui doit le plus optimisé et la plus solide.

Les composants communs que l'on a actuellement (par exemple le module.textsanitizer.php) devrait pouvoir etre modifié et étendu très facilement sans mettre en péril la montée en version.
Actuellement ce n'est pas le cas et c'est très très handicapant pour le developpement de fonctionnalités et de modules.
Je pense que pour permettre à xoops de pleinement evoluer, il faut mettre en place un systeme de composants (ou plug in) qui permette d'étendre les fonctionnalités de xoops séparant davantage le noyau des composants existants.

Après, on peut rentrer dans le concept de la distribution en distribuant un noyau associé à des plug ins et modules officiels.
Ainsi, l'evolution du noyau sera bien plus souple car on n'aura plus forcément besoin d'attendre que l'equipe xoopscore integre des fonctionnalités pour les rajouter de maniere propre dans notre xoops.

Joomla suit en partie (en partie seulement) ce principe sauf que selon moi, leur système est très très loin d'etre propre.

Actuellement, je trouve xoops très bien fait du point de vue propreté d'installations des modules et autre (au niveau de la gestion des fichiers, pas des bases de données où la avec la table des permissions c'est un vrai champs de bataille)

Certe, le developemment est ambitieu mais xoops peut il vraiment se permettre de continuer sur une voie dépassé à coup de patchwork ?
Le concept de modules est super mais aujourd'hui, absolument tous les CMS le font (certe de maniere un peu moins propre souvent). Il faut donc voir plus loin

Euh je comprends pas trop ce que tu veux dire...
Pour moi, un hak implanté se surcharge sur le hak precedent (ou sur la class d'origine si elle existe pas)

En clair, la class MaClass_hak2.php a est prioritaire sur MaClass_hak1.php et ainsi de suite.

Quand a l'heritage de la class, ça c'est le choix du concepteur de la class de hak. Il peut la surcharger ou ne pas la surcharger.

Ce procédé implique une certaine technique (enfin un effort de l'utilisateur) pour l'implanter.
Si on souhaite totalement automatiser ça, par un système de plug-in sélectionnable, ça risque de devenir chaud.
Je dis pas que c'est impossible mais ça implique une implantation costaud pour eviter de nuire aux performances.

Le rajout de colonne dans une base de donnée est, j'avoue un soucis.
Il y'a à ce moment la, 2 approches possibles.
-Laisser l'ancienne méthode statique avec les fichier mysql
-avoir un systeme de construction dynamique de base en fonction de paramètre donné dans les class php. Ce systeme sera activé par l'utilisateur depuis l'admin de xoops lors de la mise a jour du module

Je suis entierement d'accord avec toi.

Pour les class internes, elles doivent etre davantage extensible pour permettre à chacun de les surcharger selon ces besoins.
Attention, il faut evaluer la sécurité sur certaines class.

L'autre point clef, c'est les haks pour xoops. Actuellement, on travaille par systeme de module, surcharger une class dans le noyau est particulierement lourd.
La meilleure méthode est justement de prendre en compte cette possibilité.
La méthode xoops_gethandler est notre amis dans ce cas.
Il suffirait de verifier si un fichier de class du style maclasse.php avec un class XoopsMaclassHandler existe (comme c'est le cas actuellement), a ce moment la on l'inclut.
Apres, on verifie l'existence d'une fichier maclass_hak0.php :
-si c'est le cas on inclut le fichier class XoopsMaclassHak0Handler.
-Si c'est pas le cas, on instancie la class XoopsMaclassHandler.

Si maclass_hak0.php, on verifie l'existence de maclass_hak1.php
-Si c'est pas le cas on instancie XoopsMaclassHak0Handler

Et ainsi de suite...

De cette maniere, xoops deviendra tres tres modulaire car on aura une solution de hak disponible ne risquant pas de corrompre les fichiers de base lors de la montée de version.

Il y'a plein de petites astuces comme ça qui pourrait faciliter la vie de tout le monde et c'est ce qui doit etre developpé.

Le noyau doit etre compact, solide et extensible. Il doit donc faire abstraction de tout ce qui est applicatif (gestion d'utilisateurs, ...)

Je pense que le reste doit etre developpé sous forme de librairie ou module

Suite au bug rencontré, je poste une nouvelle version de l'editeur.

Editeur DHTMLa v1.1

Dans celle ci, il n'y a pas de bug de la page blanche pour l'administration des modules.

Je remercie :
-Garrath : pour certaines optimisations dans le javascript et le php
-Didier_mDF : pour la patience dont il a fait preuve en me permettant d'utiliser sa plate forme pour la correction du bug des pages blanches.

Il n'y a pas de fonctionnalités supplémentaires.

Garrath a optimisé le nombre de donnée à transformer pour l'editeur en générant directement la liste des couleurs, des polices et des tailles de caractère a partir du javascript.

Je vais mettre en place un nouvel environnement de test car l'ancien n'existe plus.

Non, le lien n'est pas brisé. Le serveur de redirection DNS qui heberge le site a eu un soucis de ligne telephonique avec FT.
Le site a été indisponible 2 jours de suite. A présent, tout est rerentré dans l'ordre

Ok, j'ai verifié sur tous les sites que j'utilise (3 sous xoops), je n'ai aucun problème d'acces aux préférences des modules.
Je t'envoie un mp avec mon adresse msn, Pourrais tu me contacter directement pour que je puisse en savoir plus ?

Pourrais tu me dire les modules dont les preferences bug ?

Merci

Il n'y a pas de mon point de vue de module miracle.

Je conseillerai News pour les fonctionnalités xoops (par contre je le deconseille pour apprendre l'architecture d'un module xoops orienté objet car le module se base sur la classe newsstory de xoops et non pas le xoopsobject)
Pour l'objet, voir plutot du coté de smartsection. Par contre, se mefier de certaines techniques utilisés par faciliter le codage (comme les includes dans le header qui facilite le codage mais coute en performance)

Pour decomposer un module, il faut principalement s'occuper du fichier xoops_version.php.

De mon point de vue, il vaut mieux penser ses scripts orienté xoops que de les adapter à xoops. C'est nettement plus efficace.

Les choses a vraiment comprendre sont le modele objet et son handler (au debut c'est assez deroutant, on a tendance à mélanger les 2).
Bien insister sur la classe criteria qui est tres tres importante pour créer des modules efficaces et facilement modifiable.
Je déconseille pour commencer d'utiliser des classes abstraites s'occupant de créer certaines fonctions comme l'insert, la lecture d'un element de la table. Il vaut mieux coder cela en dur.

Faire egalement l'effort d'utiliser l'objet en pensant un objet différent pour manipuler un type de donnée associé à des fonctionnalités

La meilleure doc sur laquelle tu peux t'appuyer, c'est la doc php.

Normalement, le serveur est a nouveau en ligne pour pouvoir tester.

Aille, c'est vrai que j'ai hébergé la zone de test sur la machine de developpement.
Normalement elle est toujour en ligne, mais aujourd'hui ça n'a pas l'air d'etre le cas.
Je tache de regler le problème des ce soir