Wikini

GererLesActionsSousFormeDObjets

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-18-206-241-26.compute-1.amazonaws.com

Gérer les actions sous forme d'objets

Idée qui me trote depuis un certain temps, mais que je pensais totalement impossible sans un réécriture complète du moteur, ou du moins sans casser la rétrocompatibilité avec les actions existentes. Mes réflexions récentes m'ont tout de même fait trouver une solution, que je me permets donc d'exposer ici. -- LordFarquaad

Idée de départ

Ce qui existe

Actuellement, les actions (tout comme les handlers et les autres modules) sont gérés comme de simple fichiers à inclure sauvagement à partir de la méthode IncludeBuffered?, dont le principe consiste à demander au module d'afficher tout, et à récupérer ce qu'il a affiché pour le retourner. En gros, WikiNi fait sans cesse un jeu de passe-passe en redirigeant ce qui est affiché vers un buffer (avec les fonctions ob) et en récupérant le contenu comme retour de méthodes, bien souvent pour être affiché à nouveau juste après etc.

Les inconvénients de ce qui existe

Cette solution n'est peut-être pas idéale, mais on peut dire qu'elle fonctionne plutôt bien. Cependant, au niveau des actions, elles posent quelques petits problèmes/limitations:

La solution

Pour contourner ces problèmes, la solution consiste à charger les actions sous forme d'objets, qui seront utilisés ensuite à la demande via une méthode spécifique. Les paramètres passés aux actions deviennent un paramètre de la méthode, et les actions ont leur propre espace de nommage (variables internes de l'objet).

Ses avantages cachés


Ses inconvéniants


Principe de fonctionnement

L'idée est simple: lorsqu'une action est appelée pour la première fois, on charge la classe du même nom et on en crée une instance qu'on stocke dans un vecteur des actions (paires "nom de l'action" => objet) et dans une variable $action. Si l'action a déjà été appelée, on récupère $action dans le vecteur des actions.
Ensuite, on appèle une méthode spéciale de $action avec comme paramètres un vecteur des paramètres fournis par l'utilisateur (sous la forme clef => chaine) et l'objet $wiki.
Ainsi, l'objet représenté par l'action est stocké tout au long de l'exécution et peut mémoriser ses propres variables internes.
(NB.: pour l'implémentation, faire attention au risque de copie des objets en Php4?)

Rétro-compatibilité

Si on veut conserver la compatibilité avec toutes les actions existentes, surtout les ContributionsWikiNi, il faut permettre aux anciennes actions de continuer à fonctionner sans avoir besoin d'être transformées en objets. Pour cela, il suffit de définir une nouvelle nomenclature des actions implémentées sous forme de classes. Ce sont des classes, dans des fichiers à inclure... Je propose simplement nomdelaction.class.inc.php, ce qui permettra au moteur de les distinguer des anciennes actions, nommées simplement nomdelaction.php.

Cas de test

Cette section définit le comportement du noyau de WikiNi lors de l'appel d'une action:
  1. L'action existe-t-elle dans le vecteur des actions ?
    1. oui:
      1. récupération de l'objet actionobj dans le vecteur
      2. return $actionobj->run($params, &$wiki)
    2. non: le fichier actions/$action.class.inc.php existe-t-il ?
      1. oui:
        1. chargement du fichier (ce qui définit la classe Action$action NB. je pense que les noms de classes sont insensibles à la casse en PhP)
        2. instanciation et stockage de l'instance dans $actionobj et dans le vecteur des actions sous la clef strtolower($action)
        3. continuer à partir du 1.a.2
      2. non: exécuter l'action à l'ancienne (inclusion etc.)

Implémentation

Voilà j'ai fait une première implémentation qui semble bien fonctionner et satisfaire les objectifs. Le code est assez long et pour pouvoir donner des exemples facilement je l'ai placé dans une autre page: GererLesActionsSousFormeDObjetsSolution1?.

Discussions

Votre avis ?

voila un truc qui me plait bien, car pour le moment je suis en effet bloqué sur des trucs tous simple comme le header qui est chargé en premier par exemple, ce qui ne permet pas d'en faire autre chose que prévu. Et pour tous les avantages évoqués plus haut... -- Err404?

Je crois que la modularité est indispensable à la pérénité de wikini, et c'est un très bon axe de travail pour l'optimisation. --Xf75013?

Tout ça me paraît très intéressant. En revanche j'ai un peu de mal à suivre ton raisonnement n'étant pas très versé dans la POO... pourais-tu nous fournir un exemple avec du code ?
Par exemple il pourrait s'agir d'une action permettant de définir le <meta name="keywords" content="..............." /> de chaque page en plaçant l'action au début du texte :
{{metaKeywords content="objets, action, wikini"}}. Qu'en penses-tu ? -- CharlesNepote

Je me dis à présent que le choix de l'extension ".class.inc.php" est un peu lourd et que ".class.php" suffirait tout à fait en fait (quelle différence sémentique pourrait-il y avoir entre les deux ? Il me semble que ".class.php" implique que c'est un fichier à inclure, ce qui rend le ".inc" inutile...). Ceci serait d'autant mieux qu'apparemment certains IDEs (Eclipse? par exemple) associent automatiquement cette extension à des fichiers contenant simplement une classe (avec un template prévu à cet effet). Qu'en pensez-vous ? -- LordFarquaad


LordFarquaadASuivre
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]