Skip to main content Help Control Panel

 

Projets «  

Extensibilité des codes yacs

Pouvoir créer ses propres codes yacs sous forme de plugins

J'ai développé une méthode pour étendre les codes yacs sous forme de plugins.

Principe:

Dans la fonction render() de la classe Codes, on va parcourir le répertoire /plugins/codes/ et inclure les scripts trouvés.

Exemple:

Je fournis en pièce jointe le codes.php modifié, ainsi qu'un exemple de plugin :
codes.zip

Intégration:

La branche wheel a été mise à jour.

 TopicPosterRepliesViewsLast post
Règles de fonctionnementChristophe Battarel0515

created by Christophe Battarel on June 25 2010

Codes yacs reloaded
Proposition d'un nouveau mécanisme, à base d'une classe à dériver, et en s'inspirant de la solution de Christophe.
Alexis Raimbault6333

edited by Alexis Raimbault on May 26 2011

Comments


J.Juraverfrom Entre chaise et clavier...
3710 posts

on Aug. 19 2011


Bonjour, pas tout compris du fonctionnement backend et frontend, mais je suis intéressé à tester la solution si une technique de test est proposée de manière simple.

Les codes yacs sont un grand levier d'évolution pour yacs.


Je ne m'attarde pas, j'ai mon yacs en double file...

Yacs on my blog | Suivez le blog Yacs | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz |

Alexis Raimbaultfrom Mulhouse
Associate, 1900 posts

inspired from Alexis Raimbault on Oct. 23 2010


J'ai ajouté une page pour ma solution.




Alexis Raimbault webmaster free-lance

Alexis Raimbaultfrom Mulhouse
Associate, 1900 posts

on Sep. 20 2010


Un petit mot pour dire que j'ai revu le sujet et commencé à travailler dessus, avec une solution très proche du code proposé par Christophe, juste un peu plus d'enrobage.

Elle se base sur la création d'une nouvelle classe, établissant l'interface d'un code yacs, à surcharger pour chaque type de code.

la méthode principale, set_pattern_replace(&$pattern, &$replace) permet de définir les couples "expressions captées"/"code appelé". Elle est à surcharger.

les classes dérivées contiendront ou pas une méthode render() selon le besoin. Le fichier de la classe devra se nommer selon le caneva "code_foobar.php".

Je regarde également comment faciliter la maintenance des pages d'exemples de codes yacs. Un methode get_samples() permettrait à chaque classe de définir ses textes d'exemple. (y compris donc, des codes yacs perso)

afin de faciliter cette rédaction, une methode format_sample() pourra prendre en charge le formatage d'une ligne d'exemple présentée en tableau dans les pages d'aide (et dont l'ensemble présente actuellement beaucoup de répétitions de code)

j'ai pensé également à une méthode pour faciliter l'écriture des expressions régulières à injecter dans $pattern.




Alexis Raimbault webmaster free-lance

Alexis Raimbaultfrom Mulhouse
Associate, 1900 posts

inspired from Christophe Battarel on Jul. 13 2010


Christophe Battarel :

d'accord pour réserver included aux scripts de projets externes.

Selon ton idée de plugin on devrait alors avoir plugins/layouts, plugins/overlays, plugins/hooks, etc.

mais je trouve qu'on s'écarte du fonctionnement de yacs. Une grande différence de yacs avec d'autres CMS est qu'il n'y a pas un seul script d'entrée (index.php) entrouré de modules mais des scripts pour chaque type de page affichée. Avec plugins et modules je sens que l'on va induire une confusion. Mais pour trancher il me faudrait savoir comment tu compte integrer tes "modules" avec les scripts actuels ?

En tout cas je pense que la place des codes de control reste /codes. Je vais proposer les entrées d'une classe modèle "codeyacs" et le traitement associé à faire dans shared/codes.php. Si quelqu'un a le temps avant qu'il ne se gêne pas pour entamer le boulot.

 

 

 




Alexis Raimbault webmaster free-lance

Alexis Raimbaultfrom Mulhouse
Associate, 1900 posts

inspired from Jmarc on Jul. 13 2010


Jmarc : l'éditeur textarea propose déjà quelques raccourcis de code yacs. c'est donc imaginable.




Alexis Raimbault webmaster free-lance

Jmarcfrom Cannes
821 posts

on June 29 2010


J'aime bien la simplicité de la solution de Christophe... en attendant une optimisation globale comme suggérée par Alexis.

Personnellement, s'il faut revoir certaines choses sur la mise en oeuvre des codes yacs, je proposerais d'aller plus loin, d'un point de vue "ergonomie utilisateur".

Il m'est difficile d'expliquer à mes contributeurs (pas très férus d'informatique) qu'ils peuvent utiliser des codes pour améliorer leurs contenus et qu'il faut qu'ils se plongent dans la liste des codes et de leurs exemples.

Par contre, j'aimerais bien leur mettre une liste déroulante dans l'editeur wysiwyg qui leur permette d'insérer un code yacs dans leur contenu. La liste n'afficherait pas les codes yacs mais leur résultat :

  • lien vers article
  • lien vers section
  • sommaire de la page
  • contenu d'une section
  • etc...

Le code yacs serait alors automatiquement interprété dans l'éditeur Wysiwyg pour afficher le résultat dudit code (c'est ce que j'ai fait pour l'inclusion des images... mais sans utiliser le code yacs habituel).

c'est pas simple à coder (je ne sais même pas si c'est faisable) mais cela permettrait de mettre la puissance des codes Yacs à la portée de tous


Christophe Battarelfrom Grenoble-Chambery
1041 posts

inspired from Alexis Raimbault on June 27 2010


Effectivement, cette solution a les qualités et les défauts de sa simplicité.

Il faut la prendre comme un point de départ pour effectivement exploser le codes.php.

Concernant l'arborescence, le répertoire included contient les scripts externes à yacs (tinymce, ckeditor, etc) et devrait d'ailleurs s'appeler libraries en toute logique. Par contre, il est suffisamment conséquent et spécifique pour ne pas aller le polluer avec autre chose.

J'ai hésité entre un sous-répertoire plugins dans /codes et un répertoire générique plugins avec un sous-répertoire codes, solution que j'ai finalement choisie car elle permet de prévoir d'autres types de plugins et de refléter cette nouvelle modularité dans l'architecture de Yacs.

J'envisageais également de coller dans plugins un répertoire modules qui contiendrait des modules optionnels pour yacs (par exemple pour le commerce électronique).

Cette architecture avec un dossier /plugins, un /plugins/codes, un /plugins/modules, etc permettrait aussi de pouvoir développer simplement une console de gestion des plugins installés sans avoir à parcourir tous les répertoires de yacs.




Christophe Battarel - Société altairis -

Alexis Raimbaultfrom Mulhouse
Associate, 1900 posts

inspired from Christophe Battarel on June 27 2010


Hellow Christophe,
merci pour cette initiative, c'est un chantier que je trouve important.
Shared/Codes.php est trop volumineux ( 4500 lignes ) et dissuade actuellement l'implémentation de nouveaux codes ou varations sur les codes, pourtant très demandés.

Ensemble de remarques sur ta propostion :

c'est assez simple, en touchant à peine à l'existant

J'aurais quand même vu plus loin avec un éclatement de codes.php. Toutes les familles de codes seraient regroupées par fichier à l'image de ton "plugin"
l'immense tableau (expression régulières/fonctions appelées) serait sorti de codes.php et construit à la volée.

Néanmoins à fin d'optimiser les performances, plutôt que de parcourir les fichiers à chaque fois, la construction dudit tableau pourrait être mis en cache, tout comme i18n transforme les .mo en .mo.php
Ce fichier-cache serait construit automatiquement, à voir quand (hook setup, premier appel d'un code...)
Si c'est nécessaire on peut optimiser davantage en mémorisant quelque part (values?) les codes les plus usités par le serveur de manière à les mettres en premier dans la construction du tableau.

Je suis un peu chagriné par le terme et l'aborescence "plugins". Tu as d'autres idées de plugins ? et nous avons déjà un "included".
Enfin en tout cas comme il s'agirait d'éclater codes.php, je propose la chose suivante :

nous avons déjà un répertoire codes/, qui contient en fait les pages d'exemples de codes yacs (d'ailleurs pas forcément à jour)
chaque fichier, en plus d'être une page de doc en ligne, condiendrait la déclaration d'une classe Mon_code extends codeyacs avec en méthode

  • la déclatation des expressions régulières captées
  • la fonction de traitement render associé


En procédant ainsi, on favoriserait la mise à jour de la doc en ligne à mesure qu'on ajoute des codes, et cela donne une arborescence plus logique. (Il est possible que les pages actuelles soient elles aussi éclatées)

A+




Alexis Raimbault webmaster free-lance

Christophe Battarelfrom Grenoble-Chambery
1041 posts

on June 25 2010


Merci de me transmettre ici vos retours et vos suggestions d'amélioration.


Christophe Battarel - Société altairis -

Christophe Battarelfrom Grenoble-Chambery
1041 posts

on June 25 2010


Bienvenue dans le groupe "Extensibilité des codes yacs"


Christophe Battarel - Société altairis -

Files

Codes.zip - 29,478 bytes, 12 downloads
edited by Christophe Battarel on June 25 2010 · details
PersonWatcherEditorOwner
 Christian - YACS team - responsable support
création site internet
annuaire entreprise Rhône-Alpes
 Christophe Battarel - YACS Team - Développement
 J.Juraver - Yacs team - Modération, Communication, Documentation
 Agnès Rambaud - YACS team - Modératrice
 Alexis Raimbault - YACS Team - Modérateur, Support, Développement.
 Jmarc