Hello, Koz, spa ma fôte, je ne voudrais pas bloquer les bonnes volontés des développeurs :)
Quelques chantiers sur la branche sexy que je verrais bien à court/moyen terme. Si certains veulent contribuer, n'hésitez pas. Les sujets sont des propositions (et beaucoup de copy/paste de vieux mails de ma part), toute critique est bienvenue :) Si certains d'entre vous se sentent plus d'affinités pour tel ou tel point, manifestez-vous ici, on ouvrira s'il le faut les fils qui vont bien sur le forum. La liste n'est pas figée, n'hésitez pas à enrichir avec vos suggestions. (Note : je cause seulement de la partie dev, je pense qu'on parlera de l'ergo de l'admin sur un fil à part, ce dernier concernant aussi les non-devs). Franck: tu peux ajouter les points que tu vois sur la partie branche default :) 1. Implémentation de Twig coté admin J'ai résumé la situation sur le forum : http://forum.dotclear.org/viewtopic.php?id=47322 Si certains connaisseurs de twig sont là, je suis vraiment preneur de tout feedback sur les templates qui ont été créés pour l'instant, sur la manière dont twig est intégré/appelé. Je suis très preneur aussi des feedbacks sur le concept dcForm, et si certains se sentent, les dcFilter et dcList (voir posts.php de la branche twig et ce que ça donne pour le moment, il reste à voir les actions) 2. Gestion de dépendances entre plugins et thèmes. Je repompe un mail d'il y a un an sur le sujet. Coté dev, il faudrait pouvoir compléter le _define.php du plugin, avec par exemple : $this->registerModule( /* Name */ "Antispam", /* Description*/ "Generic antispam plugin for Dotclear", /* Author */ "Alain Vagner", /* Version */ '1.3.1', array( 'permissions' => 'usage,contentadmin', 'priority' => 10, 'depends' => array( 'comments' => '1.0') ) ); L'attribut 'depends' est alors un tableau des dépendances, chaque clef du tableau étant une dépendance avec un plugin donné. Pour la valeur associée à la clef : * soit on met une valeur min (ex: 1.0) : dépendance avec comments v1.0 minimum * soit on met un intervalle (ex : array('1.0','2.0')) : dépendance avec comments v1.0 minimum, v2.0 maximum * Soit on met rien (''), auquel cas on vérifie juste que comments est présent. Maintenant, comme la vérification des dépendances est potentiellement chronophage, je propose de restreindre la vérification à certains endroits : * A l'accueil de l'admin : on vérifie les problèmes de dépendance, et on désactive les plugins ayant des problèmes de dépendances. * Dans la gestion des extensions : * vérification de toutes les dépendances à l'accueil de la page extensions * vérification des dépendances à l'installation d'un plugin : si les dépendances ne sont pas concordantes, le plugin est installé, mais désactivé. * un plugin dont dépendent d'autres plugins actifs n'est ni désactivable, ni supprimable (on affiche un message du pourquoi) * un plugin n'ayant pas ses dépendances résolues n'est pas activable, mais est supprimable. 3. Réflexions sur une classe gestionnaire d'urls A force de creuser dans les entrailles du core coté admin, je me rends compte d'un besoin transverse pas encore adressé : la gestion des URLs. Par exemple : comment éditer la catégorie 1, comment afficher la catégorie 1 coté public, ... Je pense qu'un objet qui gère tout ça coté admin serait bienvenu. Du genre : $core->urlManager->getAdminLink('category',array('id',1)) $core->urlManager->getPublicLink('post',array('id',1)) ... Aujourd'hui, si on veut renommer admin/category.php en autre chose, les impacts sur les fichiers à modifier sont assez conséquents. Autre point, un plugin peut contourner tout ces liens vers les siens :) 4. Enrichissement du backend / REST Rendre toutes les actions d'admin accessibles en REST 5. Evolution du plugin widgets pour ne plus fournir de contenu en dur ==> lié au passage à Twig, avoir une vraie couche de présentation 6. Réflexions sur le remplacement de dblayer par PDO
_______________________________________________ Dev mailing list - Dev@list.dotclear.org - http://ml.dotclear.org/listinfo/dev
