[spip-dev] SPIP 2.0

From : ben.spip@... , the 19th March 2008 21:29
Bon, moi qui ai toujours trolle pour defendre l'idee que SPIP 2.0 ne sortirait pas sous ce nom la !!! mais bon peu importe le nom la perspective d une version stable me rejouie ;-) alors si je reprends un peu les differents mails cela donne quelque chose de ce genre : FORMULAIRES :  ---------------------------- cedric : Il y a maintenant une API définie, implémentée en cours de test. Je l'ai pour ma part appliquée à une demi douzaines de types de formulaires différent, et il me semble que sa couverture fonctionnelle est bonne. J'ai aussi recodé et en test le formulaire forum ajaxé. Comme il ne t'aura pas échappé, la doc de cette api est en cours sur spip.net. Il est encore temps de faire des retours dessus pour la figer. Les vieux formulaires peuvent continuer à fonctionner, à condition de copier AUSSI le vieux balises/formulaire_xxx associé. Dans ton cas particulier, il doit suffire d'ajouter un class='noajax' sur la balise form de ton squelette arno : on définit l'API des formulaires (j'ai compris que c'était en bonne voie, donc)... Fil : * OK avec Cédric pour pêter les formulaires, le nouveau système est quand même mieux. Avec une méthode simple pour continuer à pouvoir exploiter les formulaires qu'on a personnalisés (un zip facile d'accès sur la zone, par exemple, et une doc de migration). Ben : Pour la doc dont parle cedric c'est ici http://www.spip.net/ecrire/?exec=articles&id_article=3753 Donc si vous voulez tester les "nouveaux formulaires" n hesitez pas et faites vos commentaires ici ou sur l article de spip.net CFG ---------------------------------------------------------------- Arno* : le plugin CFG ne doit pas être un plugin désactivable. C'est totalement incohérent: un plugin qui désactive les autres plugins, c'est incohérent. Soit on le met dans le core, soit on en fait un / lib. Et on le rend multilingue, parce que bon, c'est pas possible, là. (Et faudra lui faire un lifting un jour, parce que son interface est pas aux normes SPIP :-)). Fil : cfg est super, mais contient tellement de trucs "ultra puissants mais super complexes" que c'est un morceau de code difficile à faire avaler au core ; si on veut le mettre dans le core (et en effet il faudrait, conceptuellement ça n'a pas de sens qu'il n'y soit pas), il faut le simplifier, voire en réécrire une version minimaliste. Ben: et qu'en pense Matthieu qui a bien plonge les mains dedans ? PLUGINS ---------------------------------------------------------------- Arno : on met en place une «ferme»  plugins, bien foutue, façon plugins Mozilla, accessible et compréhensible par le webmestre qui n'a pas un niveau bac+4 en manipulation SVN; Fil : Les plugins sont actuellement encore un peu difficiles d'accès : c'est sans doute pas grand chose à faire : un peu d'interface pour la partie chargeur, un peu d'interface/doc pour la partie spip.net/plugins/  -- plus ils seront faciles à gérer, moins le débat "officiel/pas officiel" qui nous pourrit la vie aura de l'importance. On pourra alors avoir une base de code minimale (dite "core"), une (ou plusieurs) "distributions" (officielles ou non), et une foule de bidules (modules, plugins, squelettes) à ajouter pour activer telle ou telle fonctionnalité. Ben : Ah tiens je n avais pas vu qu il y avait une ebauche ici : http://spip.net/plugins INTERNATIONALISATION ------------------------------------- Fil: * Pour l'internationalisation des plugins, Arno*, il y a plusieurs problèmes : - internationaliser le code (mettre les _T() et créer les chaînes de langue dans l'interface de trad) reste un peu chiant à faire - traduire ce qui est dans l'interface de trad est du domaine des traducteurs - les chaines de langue des plugins ne sont pas dans cette interface ? Pourtant tout est prévu pour qu'ils puissent l'être : go go go. Ca n'a rien à voir avec la question d'être "core" ou "pas core", le seul truc c'est que le "core" exige une mise en traduction => i.e. à chaque fois je m'en suis occupé. Mais il faut se prendre par la main, c'est malsain que ça dépende uniquement de moi (la preuve, en ce moment même le core est trop peu internationalisé) - nous les zonards avons pris l'habitude de mettre les fichiers de langue dans le SVN de la zone, au lieu de l'interface de trad. C'est une mauvaise habitude, ça prouve peut-être qu'on n'est pas assez sérieux sur cette question : là encore il suffit qu'une personne (ou deux) décide de s'y consacrer Ben : ok je vais jeter un coup d oeil sur le processus ... selon moi cela consiste a faire un plugin "modele" qui est completement internationalise et de voir comment cela est maintenu et comment cela s imbrique avec les trads de spip.net James Florent et Fil sont a ma connaissance ceux aui maitrisent le processus RESTE ----------- Arno : – on définit clairement l'API des plugins, et on la documente progressivement – on définit l'API des #EXTRA (vach'tement pratique pour les petites bidouilles), et on les documente (pour l'instant, il n'y a qu'un article sur contrib, qui dit qu'il faut patcher SPIP!) – on définit l'API des accès SQL, TICKETS ------------------------ je me pose une question sur les tickets : quel report faut il regarder ? : http://trac.rezo.net/trac/spip/report/3 quel tag prendre en compte pour la sortie de juillet ? SPIP SPIP SPIP hourra ;-) Ben.