Suggestion Codex pour le ploug de recueil des données Advertise pour le ploug d'inventaire
My two cent's Le 17 septembre 2013 12:48, Bruno <[email protected]> a écrit : > 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 > -- Franck -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
