j'aimerais savoir si moodle utlise un mapping objet-relationnel comme doctrine ou nn ??? je doit implementer un nouveau module sous moodle et je doit connaitre son architecture si vous pouvez m'aidez
Ben dites-donc !
Il est temps que je prenne une vraie retraite car "je n'y pige que couic...".
J'espère qu'on pourra vous aider.
Patientez un peu, notre communauté est très réactive.
Daniel
La question n'est pas facile...
La reponse est pas vraiment. Moodle persente une couche assez fine objet-relationel. en fait cela n'est pas tres bien defini dans Moodle. c'est un peu une question d'opinion.
Desole de ne pas pouvoir offrir une reponse definitive.
expliquez vous svp parceque franchement j'arrive pas a vous comprendre surtout que jusqu'a maintenant la notion de base de donnee sur moodle (et son architecture) est encore floue.
voici un lien qui poura vous pointer dans la bonne direction: http://docs.moodle.org/dev/Database_schema_introduction
Cette introduction decrit the schema de la base de donnee de Moodle - a ne pas confondre avec le systeme de gestion des fichiers (Moodledata).
La documentation en Anglais est plus complete que la version francaise.
Bone chance.
Il faut comprendre dans le message de Paul que Moodle est issu d'une stratégie de développement pragmatique, on modélise peu, et réalise rapidement à partir du besoin exprimé par les usagers.
Ceci pourrait amener à un immense globi-boulga comme on peut le voir dans d'autres opensource.
Moodle a su publier très tôt des règles simples de codage, et promouvoir une très bonne modularité qui isole chaque module dans son petit modèle de données local.
Les développeurs n'ont donc jamais éprouvé le besoin de se lancer dans des grandes modélisations ou des cartographies abstraites de la plate-forme. (Il y a pourtant des patterns d'abstration à quelques endroits clefs)
Pour ce qui est de l'usage de l'objet : là encore, on évite le dogme du "tout objet "à la Zend" (ce qui fait des architectures tellement explosées en petites unités qu'elles deviennent indébuggagbles par des stratégies simples. L'objet est utilisé selon une stratégie "ad hoc" : Les objets apparaissent surtout à où il y a de l'extensibilité :
une classe abstraite + des plugins concrets qui dérivent de la classe abstraite (exemple : blocs, format de page, etc.). Cela favorise une bonne réglementation des modèles de plugin, plutôt que des "includes normalisés" qui au final ne sont plus jamais si normalisés que ça.
Faire du tout objet en PHP est un peu ridicule : il n'y a aucune persistance, ni serveur d'application. On s'ennuie à faire des objets pour des durées de vie qui sont celles du déroulé du script/page. Hormis pour la structuration de l'architecture : modularité, extensibilté, dérivabilité, c'est inutile.
J'en ai fourni (des mappings du noyau central de la bdd) quelques uns dans la doc dévelopeur 1.9, mais suis un peu en retard sur Moodle 2 :
http://docs.moodle.org/19/fr/D%C3%A9veloppement:Mod%C3%A8les_de_donn%C3%A9es
Sauf erreur je dirais plutôt "Gloubi Boulga".
Mais je ne connais pas trop le russe...ou plutôt le mongol...
Daniel : Sauf erreur je dirais plutôt "Gloubi Boulga".
Encore un nostalgique de L'Île aux enfants.
Joseph
Etes vous d'accod pour faire déplacer cette discussion dans la section Développement de Moodle ?
Salut Valéry,
C'est fait.