Bon on a vaguement glisse l'idee dans un ou 2 posts sur les topics qui deviennent un peu foure tout actuellement (j'ai rien contre c'est du brain storming au final )

Xoops est cense etre objet, ce qui sous entend pour bcq une programmation modulable, qui peut s'enrichir etc...
Sur divers points on s'apperçoit que l'on est oblige d'aller modifier les classes de bases de xoops pour faire ce que l'on veut, ou meme rajouter des classes a gauche a droite.
Pour un developpeur ca pose pas de pb, par contre pour des utilisateurs lambda si...
C'est pour cela que l'on a plus ou moins vaguement lance l'idee de pouvoir mettre des classes differentes dans xoops et de laisser le choix a l'administrateur de prendre tel ou tel classe (pour tel ou tel raison).
Je vais donner un exemple pour que cela soit plus clair.

Admettons que le panneau d'admin de tous les modules soit constitue pareil et utilise une classe X pour son affichage.
Cette classe fait apparaitre le menu sous forme de tableau sur la page d'admin du module (classiquement, exactement comme le panneau d'admin du module system).
On peut tres bien imaginer d'autre façon de proposer l'affichage du menu du panneau d'admin : Une classe Y par exemple qui nous le fait apparaitre sous forme d'onglet.
Typiquement on pourrait tres bien donner dans le panneau d'admin le choix a l'administrateur de choisir l'affichage qu'il veut. Et donc au final la classe.

Voila en gros le principe, en esperant que cela soit claire.
Mais ce qui est vrai ici, devrait pouvoir se faire pour pas mal de chose differente.

En gros cela reviendrait a pouvoir ajouter des fonctionnalites a xoops de 2 façons differentes, avec des modules d'un cote ou on ajoute des fonctionnalites diverses et varies, et de l'autre avec un ajout et un parametrage de classe ce qui est un peu moins lourd qu'un module qui permet d'etendre les possibilites deja offerte basiquement par xoops (des hacks peut etre?)

On pourrait tres bien faire ceci, pour les editeurs, pour les bases de donnees, pour les users, etc... etc...

Voila l'idee general.

Maintenant, il faut y penser et reflechir a plusieurs choses :
L'interet est-il reel?
L'interface utilisateur?
Generalisation de l'idee?
etc...

A votre bon coeur

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

yep Phelim... On rentre directement dans la technique
Effectivement avec le handler on a un moyen technique de le faire.

Maintenant, comment on peut imaginer le parametrage de cela?
- Juste un bete choix de class dans une listbox?
- Un parametrage plus fin, avec choix dans la listbox plus options de certaines class

L'implementation aussi... comment on fait
Certaine de ces surcharges de classes devront rajouter des colonnes aux tables de base ou meme rajouter des tables?
Comment gerer cela, Est ce que l'on accepte l'idee de rajouter des colonnes aux tables de base?

L'arborescence a prendre en compte pour les classes du coup?

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 veux laisser a l'admin le choix de la classe dans une listbox de façon a ce qu'il puisse changer s'il veut.

Exemple : comme pour le look des menus d'admin. Il met un tableau, il peut regarder si ca lui convient, et apres il peut changer de classe et mettre les onglets.

Bien sur c pas le cas general, certaine classe ne peuvent pas etre change tout le temps. Ca veut dire que c'est un parametre a prevoir...
D'autre classe peuvent etre choisi par l'utilisateur lambda tout le temps comme l'editeur par exemple (c'est deja le cas)

Il faut voir cela de façon general. Prevoir tous les cas et s'arranger pour que tout soit fait sur le meme modele.

Salut,

J'ai lu votre post avec attention vu que je m'intéresse au code.

Mais dans l'exemple que tu donnes, il suffit de changer de template (html) et pas de classe. Je vois pas ce que changer de classe va changer l'affichage.

Certe pour passer d'un affichage classique de la console admin à un affichage en onglet, il manquera peut-être quelques (traitement de) données nécessaire au développeur pour faire son changement d'affichage.

Enfin moi il me semble qu'il est plus important que le oyau (core) fournisser vraiment des classes de bases et correctement écrite, qui puissent être surchargée et ou l'héritage est garanti. Ensuite au Dév d'ajouter ce qui lui manque pour assurer el rendu qu'il souhaite.

Ou alors j'ai rien compris

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

OK merci, cette fois je crois avoir compris.

Que dire, si ce n'est 1000% d'accord

ne vous fixez pas sur l'affichage du panneau admin, c'est un exemple... Comme c'est quelque chose de visuel c plus parlant ;)

Pour donner d'autres exemples :
- Les Messages prives, il y a la classe de base et cela serait sympa de pouvoir utiliser d'autres classes pour avoir d'autres fonctionnalites sur les messages prives.
- La classe user aussi qu'on pourrait heriter en partie pour ajouter facilement des infos differentes a renseigner/afficher.
- les editeurs qu'on peut selectionner (mais la selection possible par utilisateur lambda)
- les bases de donnees que l'on pourrait modifier (MySQL, Oracle, Postgrest, DB2 etc...)


On peut rajouter pas mal de chose encore...
Il faut trouver une solution pour module.textsanitizer.php effectivement car a chaque montee de version si on doit aller modifier ce module car on a rajoute des xoopsCode...

La frontiere entre un module et ce system c que on livre peu de fichier et on etend des fonctionnalites deja presente dans xoops, les modules etant la pour rajouter des fonctionalites lourdes (mais bon la frontiere comme toute frontiere peut etre floue ).

Tout ceci à l'air vraiment intéressant pour la modularité de Xoops! Je n'ai pas le niveau pour vous suivre, mais je tenais à dire que Xoops Cube Legacy (que je ne connais que de nom, jamais testé) utilise apparemment un système 'preload' qui permet le hack du core, sans changer les fichiers du core, mais en en ajoutant d'autres, un peut comme ce que vous proposez.

Il pourrait donc être utile de regarder comment ils ont implémentés ça, ça pourrait donner des idées!