Feature.prism mod loader

[bawaaaaah]

Permet de charger les modification de prismjs tels que autolinker et line numbers.

avant de merger il faut me valider ma maniére d'utiliser les fichier de conf, actuellement je pensse utiliser des fichier de conf contenant du json.

je vais continuer de mon côter a travailler sur l'intégration des autre module.

[ademcan]

@bawaaaaah je viens de tester ton code, il fonctionne correctement, c'est cool :) Par contre j'ai une question:

• il y a trois plugins prismjs qui m'intéressent (line highlihts, line numbers et autolinker). Je pense donc à proposer ces options dans l'interface admin lors de l'ajout de nouveau snippet ("Add new snippet"), sous forme de checkbox par exemple. Ces options seront spécifiques à chaque snippet, par exemple le numéro des lignes ne sera affiché que pour les snippets pour lesquels l'utilisateur aura sélectionner cette option. Pour moi l'autre possibilité de loader ces plugins serait tout simplement de forcer l'ajout du code <pre ....> en début de chaque snippet selon les options sélectionnées (avec qqchose du genre $code="<pre ...>"+$code+""). Du coup je me demande quel est l'avantage de l'autoloader ici, est-ce un gain de temps ? Ne serait-il pas plus judicieux de charger tous les .js et .css en en-tête des deux index.php une bonne fois pour toutes ?

[baptistedonaux]

The autoloader doesn't accelerate the plugin loading but regroup all codes loading. Then, It's autoloader which must know when it will have to load or not.

[ademcan]

Il y a en tout et pour tout 6 plugins prism.js et je ne suis pas sûr de vouloir tous les intégrer pour le moment. Alors pourquoi ne pas loader les .js et .css une bonne fois pour toutes en en-tête des fichiers index.php (seulement deux fois donc). Est-ce que ça ferait trop brouillon ?

[baptistedonaux]

Ce qui doit être chargé par l'autoloader, c'est les classes PHP et tout code dynamique nécessaire à la génération d'une page. Cela ne me choque pas donc si le chargement des .css et des .js ne sont pas prédéfinies à l'avance.. Par contre, ce qui me choque, c'est que la fonction "autoloader" soit dans un fichier config.php

[ademcan]

Ok, je vois à quoi sert l'autoloader mais je me demande si c'est vraiment utile pour ce projet. canSnippet ne contient en tout qu'une dizaine de fichiers essentiels. Il y'a deux index.php (index.php et admin/index.php), ne serait-il pas mieux de tout loader dans ces deux fichiers dès le début ? Du moins pour le moment je pense que c'est largement suffisant non ? Je ne suis pas totalement convaincu de l'utilité de l'autoloader dans l'état actuel du projet.

[bawaaaaah]

autoloader fichier config.php: Je ne savait pas trop ou le mettre et il sort la configuration des module a charger.

j'ai fait l'autoloader des plugin dans l'optique je veut moi utilisateur final rajouter mon plugin prismjs sans trop de modification niveau code. et non pas dans l'otpique intégration direct avec cansnippet ce que tu voudrait de ce que je comprend @ademcan Je n'ai pas trop chercher a intégrer le module line highlihts car il faut rajouter une option qui surligne certainne ligne et cela demander une modification compléte du code.

Personnelement si j'attaque l'api je modifirai toute les page de maniére a ce qu'elle tape sur les diversse fonction de l'api pour unifier et éviter une redondance de code actuellement présente.

@ademcan Oui il faudrait modifier la BDD pour ajouter des champs relatif au snippet pour leur donner ou non les autorisation d'utiliser un mod prism, et aussi gérer le comportement par défault pour les module que tu voudrait voir.

[baptistedonaux]

Au pire des cas, tu ne perds rien à utiliser au autoloader. De plus, tes plug-in ne seront pas forcément chargé que dans 2 fichiers.

L'intérêt des plug-in, c'est de rendre personnalisable facilement un projet à n'importe qui. Je ne vois pas l'intérêt d'intégrer des « plug-in » constamment dans ton code. Si ils sont obligatoire,, ce ne sont plus des plug-in. Dans un projet il faut voir plus loin et mettre en place, pas forcément qu.un projet mais également une structure. L'autoloader, c'est présent dans tous les projets. C'est un peu comme un listener général.

[bawaaaaah]

comme dit @baptistedonaux on peut laisser mon autoloader et rajouter une intégration plus pousser des 3 module d'ont tu as parler. sachant que le plugin ligne-hightlight nécessite une modification plus profonde du code que les autre.

[ademcan]

Ok, moi je ne vois pas les plugins de la même façon. Il s'agit de plugins prism.js et non canSnippet, du coup moi je pense que l'idéal serait d'ajouter par défault les plugins dans canSnippet (même si cela va alourdir le code), l'utilisateur pourra alors choisir lequel il souhaite utiliser pour tel ou tel snippet. Pour le côté modulable, il sera toujours possible de supprimer les fichiers .js ou .css du plugin en question si l'utilisateur ne souhaite pas les utiliser. Un utilisateur de base pour moi est une personne qui n y connait rien en programmation, c'est pourquoi j'insiste sur le fait de tout garder selon le principe KISS. Je vois mal un utilisateur se rendre sur prism.js pour télécharger tous les plugins qu'il voudrait installer. Il pourrait dans ce cas utiliser directement prism.js dans son domaine sans passer par canSnippet. Pour vous montrer comment je vois la chose je vais me concentrer sur le code et mettre le tout sur une branche avec des exemples de l'ajout de plugin (surtout line highlits), du coup ce sera plus clair pour tout le monde ;) Sinon @bawaaaaah ton autoloader est nickel, pas de soucis de ce côté là, c'est juste qu'on ne voyait pas la chose de la même manière ;)

[bawaaaaah]

d'accord je comprend mieux dans ce cas.