Compléments de réflexion : Pour le plugin référentiel (nommons-le "repo", si vous avez d'autres suggestions je suis preneur :)) : * webservice public de soumission de fichier de plugin/thème (json), avec les blindages qui vont bien * webservice public de consultation de disponibilité d'un plugin/thème dans la base. * on gère la liste des plugins/thèmes dans une base coté admin dans un premier temps, on ouvre éventuellement coté public après
Pour le plugin d'inventaire (nommons-le invent) : * Possibilité de générer un fichier json de description d'un plugin/thème * Consultation du plugin référentiel pour vérifier si un plugin n'est pas déjà référencé dans la base * envoi du json au référentiel via webservice Reste à définir la structure du json... -- Bruno Le 17 septembre 2013 10:06, Greg <[email protected]> a écrit : > Puisque personne n'a encore répondu. > > Je suis tenté dans la mesure de mon maigre temps libre (proportionnel à la > longueur des CR que je rédige) > > > > -- > Greg > > > Le 17 septembre 2013 08:03, Bruno <[email protected]> a écrit : > > > Hello, > > > > En complément du mail d'Anne sur les tests de régressions sur la 2.6, je > > pense qu'il est primordial que nous soyons en mesure de jauger > l'importance > > de telle ou telle fonctionnalité de dotclear vis-à-vis des thèmes et > > plugins dotclear dans l'écosystème actuel. > > > > Face à cela, je vois 2 plugins à développer. Je peux en être gros > > contributeur, mais je ne pourrai pas tout faire tout seul. > > > > Le premier plugin est un vrai plugin de gestion d'inventaire (idéalement > > qu'on stockerait sur un dépôt commun, à définir). Ce dernier permettrait > de > > recenser les dépendances/caractéristiques[1] d'un plugin/thème vis-à-vis > de > > dotclear. Ce dernier plugin serait principalement réservé à la team, du > > moins pour son administration [2] > > > > Le second est un plugin du type "aidez-nous à vous aider", un peu comme > ce > > que fait Mozilla sur Firefox, que je propose de livrer avec le core dès > la > > 2.6, mais qu'on doit pouvoir proposer en installation séparée dès la > 2.5.x. > > Ce plugin est à installer sur tout blog d'un utilisateur, il permet de > > faire l'inventaire des plugins et thèmes installés, et de les parser pour > > fournir un fichier qui alimentera le premier plugin. > > > > [1] Quand je parle de dépendances/caractéristiques, j'entends : > > > > Pour un thème : > > * Sa structure : simple stylage, héritage, définition de nouveaux > fichiers > > templates, présence de fichiers php > > * Les balises de template qu'il utilise, et leur paramètre > > * Les fichiers js qu'il utilise/définit s'il y en a > > * Les behaviors qu'il définit > > * Les behaviors qu'il ajoute > > > > Pour un plugin : > > * Sa structure : présence d'un prepend, d'un admin, d'un public > > * Les behaviors qu'il définit > > * Les behaviors qu'il ajoute > > * les objets $core->XXX qu'il utilise (pertinence et faisabilité à > > confirmer) > > * Les chemins qu'il ajoute dans $core->tpl s'il y en a > > * Les settings qu'il ajoute (pertinence et faisabilité à confirmer) > > > > [2]Je dis principalement, mais pour un utilisateur lambda, ça peut aussi > > être didactique, pour avoir des exemples de l'utilisation d'un behavior > > donné. > > > > > > Voilà. Qui serait tenté par ce chantier ? > > > > -- > > Bruno > > -- > > Dev mailing list - [email protected] - > > http://ml.dotclear.org/listinfo/dev > > > -- > Dev mailing list - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
