FUNKY-EMULATION V6
Nicky31

 projet
DonkeyCMS

15 messages dans ce sujet

Bonjour,

Me voilà ici pour vous présenter un projet que je développe depuis maintenant 3 mois, plus ou moins intensivement ...

 

070236donkey.png

 

DonkeyCMS

 

DonkeyCMS ... ? Qu'est-ce que c'est ?

DonkeyCMS est tout d'abord comme vous vous en doutez, un CMS. Vient immédiatement la question ... Pourquoi cette section ?

Tout simplement parce que l'objectif même de Donkey est d'être un CMS modulable et pouvant faire fonctionner en parallèle une multitude de modules ayant leur propre architecture MVC afin que chacun ait le plus large éventail de possibilités.

Ainsi, vous pourrez l'utiliser principalement avec un module CMS Dofus, tout comme avec un CMS Metin2, un portfolio, un forum, etc ... Voilà pourquoi il n'est pas dans une section de jeux.

 

Un peu plus d'informations sur son système ?

Outre le fait d'être majoritairement écrit en orienté objet, le système de DonkeyCMS se base sur le design pattern HMVC :

Hierarchical Model–View–Controller

Ainsi, un premier module ayant cette organisation Modèle - Vue - Contrôleur sera chargé suivant l'URL. Je le qualifie de module Maître, car c'est lui sera appelé pour générer le template de la page, à la différence des modules secondaires qui auront néanmoins la possibilité de modifier ce template avant l’envoi, pour par exemple y injecter leur propre contenu.

 

Sinon, des objectifs en dehors de sa modularité ?

Je ne souhaite pas une usine à gaz, c'est pourquoi je m'efforcerai par la suite de garder le juste équilibre entre complet et performant.

Où en est le CMS actuellement ?

Le système étant toujours en plein développement, ne vous attendez pas à pouvoir tester le premier module dès demain.

Principalement, les points important me venant en tête :

  • Écriture d'un système de hooks pour éventuellement en venir à des plugins.
  • Implémentation d'un registre, à priori

    Contenu Masqué

    .
  • Développement de la couche database, au minimum un CRUD
  • Éventuelle ré-éecriture totale du routage qui manque de souplesse
  • Dernier moment : Mise en place d'un backend pour la gestion du CMS (gestion modules, paramètres, logs, ...)

Liste non exhaustive, uniquement pour vous donner une idée de l'état du projet.

 

Pourquoi ce nom 'Donkey' CMS ?

Tout simplement à cause de la relation algébrique de mathématique complexe suivante :

CMS Modulable <=> Souplesse <=> Agilité <=> Singe <=> Donkey Kong

 

Des objectifs et attentes sur la 'popularisation' du CMS ?

Absolument aucun. J'ai entreprit son développement pour une unique raison :

  1. Mettre en pratique le pattern HMVC découvert par le biais d'Sgt Fatality et son kowFramework et m'entraîner toujours et encore

Cependant, ça me ferait bien évidement plaisir si des développeurs faisaient et partageaient leur module avec Donkey, et si le CMS parvenait à avoir un petit éventail de modules.

 

CMS payant ?

Jamais. Si il aboutit, je pourrai venir à vendre un module par nécessité, mais jamais le CMS qui est partagé en open-source depuis le début.

 


Voilà, je termine ce sujet en vous donnant le lien des sources :

Contenu Masqué

 

J'ouvre aussi le CMS au publique en quête d'avis critique extérieur pour m'améliorer, donc je vous en serai reconnaissant si vous avez des critiques constructives à apporter au code et à l'organisation du CMS :)

 

Bonne journée

0

Partager ce message


Lien à poster
Partager sur d’autres sites

J'ai hâte de voir le résultat. Si j'avais une suggestion, penses à y inclure un système simple de variables constantes pour les différentes MVC, ça peut être utile :)

Par exemple, on fait : $_set->publicVar('maVariable', 'Une donnée') et on peut la récupérer depuis n'importe quel model si on fait $_get->publicVar('maVariable');

Pour un CMS, ça peut être utile pour une variable de connexion, plus sécurisé qu'un cookie si c'est inclut directement sur le site.

 

#Alkimyst

0

Partager ce message


Lien à poster
Partager sur d’autres sites

D'abord merci pour le commentaire :)

 

J'ai hâte de voir le résultat. Si j'avais une suggestion, penses à y inclure un système simple de variables constantes pour les différentes MVC, ça peut être utile :)

Par exemple, on fait : $_set->publicVar('maVariable', 'Une donnée') et on peut la récupérer depuis n'importe quel model si on fait $_get->publicVar('maVariable');

C'est une bonne idée en soit, mais n'aurait selon moi d'utilité que si les modules étaient liés. Or là ils sont indépendants, venant de développeurs de tout horizon & pouvant servir des objectifs tout à fait différents. Donc comment l'un deux pourrait venir à utiliser une variable stockée en global par un autre module, qui pourrait aussi bien ne pas être installé & donc le besoin du module 'demandeur' insatisfait ? Ou peut-être que j'ai mal comprit ton idée :)

 

Pour un CMS, ça peut être utile pour une variable de connexion, plus sécurisé qu'un cookie si c'est inclut directement sur le site.

Hm, tu parles de variables constantes au sens de la même manière que des sessions ou cookies ; stockées sur le serveur ?

Sinon ton cas d'utilisation est une bonne idée, le module gérant une connexion stocke les variables relatives en global et qui en veut les utilise.

Mais cela voudrait dire que ces modules sont dépendants de l'installation et même de l'activité du premier module lors de chaque chargement de page commun ? (J'espère que tu m'as comprit)

 

Merci de m'éclairer sur ta suggestion :)

0

Partager ce message


Lien à poster
Partager sur d’autres sites

En fait, je pensais à une sorte de define() remodelé.

0

Partager ce message


Lien à poster
Partager sur d’autres sites

D'accord je vois. Mais à ce moment là autant utiliser directement les constantes classiques pour ne pas alourdir inutilement le code, avec au final le même résultat (Sauf si tu as une idée du concept qui diffère des constantes php).

0

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonne idée ! Je t'encourage à continuer !

0

Partager ce message


Lien à poster
Partager sur d’autres sites

La différence serait qu'elles soient utilisées avec une variable et non sans '$', et qu'elles soient limitées à certaines pages, pour ne pas influencer ton system.

Exemple : je definie une variable déjà existente pour ton système, ça fou en l'air tout le cms comme si je mets define('path', '') et que cette variable est utilisée dans un de tes scripts, ça peut provoquer certaines erreurs indésirables.

0

Partager ce message


Lien à poster
Partager sur d’autres sites

Ok, bon franchement je ne pense pas que c'est très utile étant donné l'indépendance de chaque module et que l'utilisateur est libre de communiquer comme il le souhaite à l'intérieur de son architecture MVC. Mais ça reste une idée envisageable suivant l'évolution du CMS ;)

Développement mit en 'mini-pause' le temps de profiter de mes vacances et développer mes autres projets.

0

Partager ce message


Lien à poster
Partager sur d’autres sites

/UP\

Alors Nicky, on abandonne ? :o

0

Partager ce message


Lien à poster
Partager sur d’autres sites

Très intéressant comme projet :o

D'autant que je me suis mis assez récemment à la POO donc je vais observer un peu les sources et si je trouve des possibilités d'améliorations ou d'autres idées je te ferais signe.

D'ailleurs je vais m'ouvrir un compte GitHub :)

0

Partager ce message


Lien à poster
Partager sur d’autres sites

/UP\

Alors Nicky, on abandonne ? :o

Ahah non, franchement j'avais un peu lâché le dév ces derniers temps et je m'y remets tranquillement avec un projet que je dois faire pour quelqu'un, après ça j'espère me remettre sur DonkeyCMS ^^

 

Fais toi plaisir Tha Smokke :)

0

Partager ce message


Lien à poster
Partager sur d’autres sites

T'as payé les droite d'auteurs sur DonkeyKong ? Y parait que chez Nintendo ils déconnent zéro avec ça :P

0

Partager ce message


Lien à poster
Partager sur d’autres sites

T'as payé les droite d'auteurs sur DonkeyKong ? Y parait que chez Nintendo ils déconnent zéro avec ça Tounge

Ahah, tu m'as affaiblit xD Je le déclare solennellement, le payerai les droits d'auteurs sur DonkeyKong lorsque la réputation du CMS atteindra celle de Facebook ! Comme ça, j'ai un peu de marge ^^ Et puis en fait, le cms s'appelant DonkeyCMS et non DonkeyKongCMS, suis-je réellement et techniquement dans l'obligation de payer les droits d'auteurs pour un nom de CMS qui a priori, et en théorie (Bien que je n'ignore pas que la théorie soit un monde bien obscure en informatique, n'est-ce pas :D), n'a jamais été utilisé / déclaré par une quelconque société, tel qu'il apparaît dans le nom de ce cms ?

Sinon, je voulais attendre avant de donner d'autres nouvelles du cms mais puisqu'on m'y force : 2 récents commits ont été fait, réorganisant la gestion des modules de façon plus cloisonnée ; la méthode Donkey::module() disparaît, et avec elle toute possibilité d'accéder à un module X depuis un module Y. Ceci a été fait suite à un éclaircissement de ma vision sur l'organisation que devrait adopter un tel système de modules : Etant tous potentiellement totalement indépendants, aucun module X ne devrait faire appel à un module Y d'une façon aussi directe, dans la mesure où rien n'oblige que Y soit bien installé et qu'il dispose d'une interface conforme à celle utilisée par X (en clair, où rien n'empêche que Y ait été modifié/ne soit pas la version officielle). D'embêtantes erreurs PHP sont ainsi évitées. Malgré tout, parce que pour qu'un tel système soit réellement souple, ce module X devrait pouvoir utiliser les fonctionnalités de Y, j'ai prévu 2 choses afin de permettre aux modules de communiquer en toute sécurité (pas de risque d'appel à un module ou interface inexistante) (X étant considéré comme le module maître dans ces exemples) :

  1. Repensant au concept avancé par Alkimys et à

    Contenu Masqué

    ; une zone de partage de données commune à l'ensemble des modules. Ainsi, afin de laisser la possibilité à Y de transmettre une information de sa production (ex: nouveau contenu additionnel comme l'output de Y intégré à X par X lui-même), X est libre de tester l'existence d'une variable (n'occasionnant ainsi aucune erreur d'accès impossible) dans cette zone registre et de l'utiliser si elle a bien été initialisée, et ce quelque soit sa source : ceci permet notamment à une information d'être générée par n'importe quel module de façon transparente à X, pourvu que le nom de la variable soit suffisamment précis (évitant à X d'utiliser une information générée par un module Z sans rapport avec ce qu'il attend).
    Jouant avec le schéma d’exécution des modules décrit plus bas, il est aussi possible pour X de déclarer une variable modifiable ou simplement utilisable en faisant cette déclaration dans son constructeur. Prévoyant d’appeler un hook juste avant l'exécution du controller du module demandé, les modules secondaires devraient pouvoir accrocher ce hook pour utiliser, sauvegarder, modifier la variable registre en question (ou même exécuter leur propre controller avant celui du module maître, mais ce n'est pas le sujet). X utilisera alors la valeur modifiée (s'il s'agit d'une modification) une fois ces fonctions hooks exécutées ; c'est à dire une fois la méthode de son controller demandée appelée.
    Si Sgt n'a rien contre ceci, j'aimerais d'ailleurs beaucoup utiliser son PigRegistry, que je trouve parfait pour répondre aux besoins de Donkey.
  2. Un système de hook (je ne suis néanmoins par encore tout à fait sûr de cette idée) permettant à X de se rendre tout seul 'crochetable' par d'autres modules en rendant par ailleurs une éventuelle variable modifiable par les hooks (d'autres modules ou éventuels plugins à venir ?). Ainsi, par l'alliance de ces 2 méthodes, 2 types de communications sont possibles : avec le registre, Y peut proposer un contenu que X peut ou non utiliser. Avec les hooks, X exécute toutes les fonctions associées à un hook demandé que Y peut ou non définir. Dans les 2 cas, la source de l'information peut venir de n'importe quel module (et de plusieurs pour les hooks) sans que X ne le sache.

Par ailleurs et afin d'avoir une liste des modules chargés (ce qui sera possible par la suite depuis le back-end) et activés (ou non d'ailleurs) par l'utilisateur, la base de donnée de DonkeyCMS a été créée pour y ajouter une première table donkey_modules.

Grâce à celle-ci, Donkey est donc dès à présent apte à charger le module maître (demandé par l'url) ainsi que l'ensemble des modules secondaires (= déclarés activé dans la table donkey_modules), selon le schéma suivant :

  1. Instanciation des modules maître/secondaires aléatoirement (selon l'ordre des lignes dans la table donkey_modules). Cela a pour conséquence qu'un module, maître ou non, ne peut compter sur l'existence (bien qu'elle soit dans tous les cas déjà supposée) d'une variable registre ou de fonctions hooks définis par un autre module, maître ou non. Le module maître peut donc très bien être instancié en premier comme en dernier. Ici, seuls les objets modules sont instanciés, le controller demandé du module maître n'est pas encore instancié.
  2. Si j'implémente effectivement ce système de hook et ce hook en question (ce qui devrait être le cas) : exécution du hook 'pre_main_module' dont j'ai parlé plus haut ; celui situé juste avant l'exécution du controller du module maître.
  3. Instanciation du controller du module maître et exécution de la méthode demandée via l'url. A la fin, toutes les vues du module sont normalement générées et enregistrées mais pas le template en lui même. Ceci peut permettre aux modules de l'étape suivante de renseigner une variable dans les paramètres statiques d'OutputContent pour être éventuellement utilisée dans le template du module maître. J'attire de nouveau l'attention sur la précision des noms utilisés : plusieurs modules sans rapport pouvant être exécutés, ils ne doivent écrire ou réécrire une variable registre / paramètre d'OutputContent que dans la mesure où l’inexistence de la variable à écrire ne fait aucun doute, et que la variable à réécrire est bien exactement celle supposée et non une variable sans rapport avec un identifiant vague/générique qui ne devrait pas être réécrite. Ces quelques détails d'importances pourraient éventuellement m'amener à un registre propre à Donkey, il faut que j'y réfléchisse.
  4. Génération de l'output complet en html du module maître en assemblant son template avec ses vues déjà générées : appel pour cela de la méthode Module::render() qui peut d'ailleurs éventuellement être réécrite, mais ce sera rarement nécessaire.
  5. Exécution aléatoire (toujours selon l'ordre des lignes de la table donkey_modules) de la méthode Module::partialRender($mainOutput) de chaque module secondaire, en passant donc en paramètre l'objet OutputContent du module maître. Si cette méthode n'est pas implémentée par le module en question, celle de la classe parente Module sera appelée : vide, rien ne sera fait.
    Les traitements des modules secondaires peuvent donc être fait : directement dans le constructeur des objets modules (pour de très courts traitements) ou dans une méthode crochetée au hook de l'étape 2 ou dans la méthode partialRender ou même dans les 3 ou 2.
  6. L'OutputContent du module maître est affiché. A ce stade, tous les modules ont fait leur travail et à moins d'un hook système, ils ne devraient plus être appelé de nouveau de quelque façon que ce soit.
  7. A la version actuelle de DonkeyCMS, son exécution est ici terminée.

Précision : Comme vous l'aurez vu, dans le chargement des modules secondaires de Donkey, a aucun moment les controllers secondaires ne sont instanciés/exécutés (comme Donkey ne sait de toute façon pas quoi appeler pour les modules secondaires). Vous êtes donc libre d'appeler ou non vous même le controller de votre choix grâce à la méthode Module::run($controller, $action).

 

Pour les points importants restants à faire, vous aurez sans doute deviné que je dois prioritairement m'occuper du système de hook, intégrer PigRegistry de Sgt (sauf si je vois qu'il faut vraiment que j'en code un pour Donkey) et ensuite éventuellement développer le back-end.

 

Voilà voilà, je pense avoir dit l'essentiel et je reste ouvert à toute question, remarque ou critique si mes explications sont incomplètes ou manquent de clarté quelque part.

 


 

EDIT :

Encore 2 nouveaux commits : PigRegistry a été inclu, et un

Contenu Masqué

a été implémenté. Exemple d'utilisation

// Constructeur TrucModule.php :
/*
* On associe au hook test_hook la méthode hookTest du module
* Le deuxième paramètre de bind() étant un callable, vous pouvez parfaitement renseigner une méthode statique ou une simple fonction
*/
Hook::instance()->bind('test_hook', array($this, 'hookTest'));

// ...

public function hookTest(&$arg1)
{
   $arg1 += 1;
}

 

// index.php
$foo = 40;
// On exécute toutes les fonctions du hook en leur permettant la réécriture de $foo :
list($foo) = Hook::instance()->exec('test_hook', $foo); // $foo = 41
// Ou bien, si on souhaite faire passer $foo sans que les fonctions puissent la réécrire :
Hook::instance() ->exec('test_hook', $foo); // $foo = 40

 

Notons l'importance de l'utilisation du mot-clé list étant donné que exec() renvoie un tableau des paramètres dans le même ordre avec lequel vous les lui avez transmis. Je me suis longuement documenté pour faire passer des variables en références à une fonction avec call_user_func_array mais le fait que ces variables soient issues de func_get_args() (qui renvoit un tableau de valeurs) semble poser problème et l'unique solution que j'ai trouvé ne marche pas pour moi, sans que je sache trop pourquoi. Au final je ne suis pas mécontent de ma solution qui permet de transmettre des variables aux hooks sans qu'elles soient éditables (même si les fonctions recoivent les variables en tant que références).

 

Par ailleurs :

  • J'ai constaté que même si Donkey vise à être modulable, insérer trop de points variables dans son système n'est pas vraiment la meilleure solution, ne serait-ce que pour la simplicité du code. J'ai donc décidé d'imposer l'héritage de la classe Module pour chaque module (qui pouvaient avant se contenter de laisser Donkey utiliser la classe parente Module). Cela aurait poser problème par exemple lors du listing des modules dans le backend : comment afficher les informations de base (auteur, version, description) des modules encore non installés et donc non enregistrés en base de données et ne disposant pas de classe Module ?
  • Maintenant, la configuration des modules est automatiquement chargée depuis leur colonne donkey_modules.settings. Il reste tout à fait possible pour les modules de charger leur propre fichier de configuration.
  • Nettoyage de la sysConfig : suffixes Module/Model/Controller ont été déplacés en tant que constante des classes en question. defaultController déplacé en tant que constante de classe Module, defaultAction en tant que constante de classe Controller. Ces deux dernières peuvent parfaitement être redéfinies par les classes Module/Controller filles.
  • Suppression de Config::toConstants() qui faisait perdre des performances pour pas grand chose (Les constantes étant plus lentes à définir que des variables).

0

Partager ce message


Lien à poster
Partager sur d’autres sites

Dans cet épisode :

"4 mois après, Nicky en est encore à coder index.html"  :rire:

 

Plus sérieusement, t'as pu avancer sur le projet ou pas du tout ?

Graphiquement parlant tu as déjà quelque chose ou tu aimerais que l'on te propose quelque chose ?

0

Partager ce message


Lien à poster
Partager sur d’autres sites

Salut, il me semble que les derniers avancements sont ceux dont je parle sur le post juste avant le tiens.

Sinon, tel qu'il a été pensé et en dehors de sa partie administrative, DonkeyCMS en lui même n'est pas censé avoir d'interface graphique ; son principe même est en premier lieu de fournir un outil de gestion de plusieurs sites présentés sous la forme de modules (codés pour Donkey) au sein d'une même application web, puis ensuite de fournir les outils de bases de n'importe quel (micro) fw de sorte de faciliter le codage des modules, mais aussi centraliser certains traitements comme l'accès aux données get/post/cookie/files ou l'accès à la base de donnée, déplaçant ainsi une bonne partie des soucis de sécurité en 1 endroit ; le coeur de Donkey. Si les traitements précédemment cités sont correctement gérés par Donkey et j'espère bien qu'ils le sont, aucun des modules ne devrait normalement souffrir de problèmes de sécurités vis à vis de ces points là.

Voilà grosso modo une présentation du but de ce CMS :)

Sinon, cela fait des mois que je n'ai pas touché au projet mais tout comme pour la pause de presque 1 ans qu'il a connu, je me remettrai à son développement lorsque je n'aurais plus vraiment d'autres priorités comme les études ou FE.

0

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !


Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.


Connectez-vous maintenant