• Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
DonkeyCMS
Staff
#11
Citation :/UP\
Alors Nicky, on abandonne ? Smiley_12
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 Heuu

Fais toi plaisir Tha Smokke Content
[Only registered and activated users can see links Click here to register]

[Only registered and activated users can see links Click here to register]
  Répondre
#12
T'as payé les droite d'auteurs sur DonkeyKong ? Y parait que chez Nintendo ils déconnent zéro avec ça :P
Weyx
  Répondre
Staff
#13
Citation : 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 Heuu 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 à [Only registered and activated users can see links Click here to register] ; 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:TireartialRender($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 [Only registered and activated users can see links Click here to register] a été implémenté. Exemple d'utilisation
Code PHP :
// 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;


Code PHP :
// 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).
[Only registered and activated users can see links Click here to register]

[Only registered and activated users can see links Click here to register]
  Répondre
#14
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 ?
Funky-PsychoZ Serveur :: Stoppé..
[Image: 1337329665-Konan.png]
.. Fini le temps du troll pedobear, voici venu le temps du Kay pro et sérieux ..
  Répondre
Staff
#15
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 Content
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.
[Only registered and activated users can see links Click here to register]

[Only registered and activated users can see links Click here to register]
  Répondre




Utilisateur(s) parcourant ce sujet : 1 visiteur(s)
Donation's plugin by Naoar.com