Clearbricks tests
by Régis FLORET
Bonjour à tous.
Après un léger craquage de nerfs (un "neirvouze brèque donne" comme on
dit de nos jours) dû a une surcharge de travail (je pense que vous savez
de quoi je veux parler :| ) je reviens en pleine forme et quand je vois
les 10 Millions de messages de la liste, je me dis que je suis passé à
côté de plein de choses super rigolotes.
Bon, pour les tests, ça avance pas mal (en fonction oeuf corse du temps
disponible).
Vous pouvez les trouvez ici :
https://bitbucket.org/rfloret/clearbricks-test
En fait, ils ne sont pas directement dans le dépôts clearbricks pour le
moment. Principalement pour ne pas encombrer clearbricks. C'est juste un
choix (je ne suis pas super à l'aise avec mercurial). Rien n'empêche
dans un futur que je souhaite proche de faire un gros pull request.
Actuellement les tests ne passent pas. Soit par ignorance de ma part
(comme l'a si bien fait remarqué Nicolas) soit parce que Clearbricks
est buggé. C'est pour cela que je fais le point ici.
Actuellement, sont testées les fichiers suivants :
common/lib.crypt.php
common/lib.date.php
common/lib.files.php
common/lib.form.php
common/lib.html.php
common/lib.http.php (partiellement)
Pour ceux qui veulent m'aider un poil, le plus simple serait de lancer
un test de votre côté et de me contacter soit directement par mail, soit
sur mon dépôt pour les tests si j'ai fait une erreur.
Même les tests doivent être débuggés
Dans le répertoire clearbricks faire un : hg clone
https://bitbucket.org/rfloret/clearbricks-test tests
Le reste est dans le README.
Si vous utilisez le Power Shell (ce qui est mon cas), le plus simple
est d'utiliser directement le macgeekguy.atoum.phar avec php
macgeekguy.atoum.phar
La méthodologie des tests est la suivante :
1) Je regarde la description de la méthode,
2) Je regarde ce qu'elle est censée me donner comme résultat en fonction
des normes actuelles (W3C, etc.)
3) J'écris les tests.
4) Je regarde l'intérieur de la méthode pour voir si je prends tout en
compte,
5) j'ajoute des nouveaux tests en fonction de 4
6) Si il y a des problèmes insoluble, je les note dans un commentaire
dans la proc de test.
Je ne peux principalement bosser dessus que le W.E.
J'ai conscience qu'il reste pas mal de travail, que c'est un travail de
longue haleine, qu'il y a un risque non nul que je ne les finissent pas,
etc, etc. Mais ce qui est fait, n'est plus à faire.
Cordialement
Régis
10 years, 5 months
Aides contextuelles, on fait le point
by Kozlika
Plop.
Il reste des pages à faire, d'autres où quelqu'un a dit "je prends" mais ne
les a pas encore faites.
Qui a des pages sur le feu, qui ne pourra finalement pas s'occuper des
pages qu'il avait "réservées", qui veut bien en prendre ?
(Objectif : sortie RC dans le week-end)
--
Anne / Kozlika
10 years, 5 months
Iconset Traviata
by Kozlika
Pouet,
J'aurais dû me plonger dans mes cours de javascript (n'est-ce pas Nikrou)
et puis finalement j'ai trouvé beaucoup plus amusant de faire un iconset
aux couleurs de l'admin.
Si vous voulez voir à quoi il ressemble, il est en pièce jointe.
--
Anne / Kozlika
10 years, 5 months
L10n et déclarations de widgets
by Simon
Bonjour,
En voulant mettre à jour l'un de mes plugins aux nouveaux standards, j'ai
remarqué que la déclaration des widgets prenait maintenant un paramètre
supplémentaire, une description "longue" s'affichant sous le nom du widget
côté admin. Exemple avec un widget "core" :
$__widgets->create('subscribe',__('Subscribe
links'),array('defaultWidgets','subscribe'),null,'Feed subscription links
(RSS or Atom)');
Je remarque ce qui est selon moi une incohérence : le nom du widget est
traduit (avec la fonction __(); ) à la déclaration, alors que la
description est quand à elle traduite semble-t-il par la fonction de
création (puisque que les intitulés sont bien affichés traduits).
Ne vaudrait-il pas mieux être consistant sur ce point ? Je pense qu'il est
plus simple pour un développeur d'avoir l'appel à la fonction dans son
plugin pour avoir ensuite la chaîne repérée automatiquement par un outil
comme translater. D'un autre côté, cela alourdit la syntaxe.
Avis, suggestions ?
10 years, 5 months
mises à jour des extensions
by Julien Wajsberg
Salut les gens,
une question m'est venue ce matin, en lisant les divers threads de la liste;
Imaginons un utilisateur Bob en version 2.5 avec un plugin A en version 1.1.
Le développeur (Alice) du plugin A fait ce qu'il faut pour le rendre
compatible 2.6, ce qui, (arrêtez moi si je me trompe) le rend incompatible
avec 2.5. Il sort une version 1.2.
Maintenant, Bob n'a pas forcément envie de mettre à jour son dotclear tout
de suite, parce que, bon, il a un peu custo son thème, et puis il est chez
Free, alors il veut attendre d'avoir un peu de temps. Mais il voit qu'il y
a une mise à jour pour son plugin A, et donc il lance la mise à jour. Sauf
que le plugin n'est plus compatible 2.5, et donc il va tout péter.
D'où ma question: a-t-on un garde-fou contre ça ?
Bonne journée ;)
--
Julien
10 years, 5 months
Idées de formalismes de macros
by Bruno
Hello,
J'ai évoqué hier le ticket 956 (http://dev.dotclear.org/2.0/ticket/956) sur
la mise en place d'un moteur de macros indépendant. Pour rappel, l'idée est
de permettre de définir des macros dans les billets, qui seraient
interprétées au moment de la génération du code xhtml du billet. Exemples :
insertion d'un media/billet via son id.
La problématique est simple :
1. soit on définit une syntaxe d'appel de la macro qui n'interfère pas avec
les syntaxes actuelles (ie. qui ne sera pas transformée par le moteur de
syntaxe), auquel cas, l'ordre de génération du code xhtml du billet est le
suivant :
* première passe avec le compilateur de format de texte (wiki, markdown,
...)
* seconde passe avec le compilateur de macro
2. soit on passe d'abord via le compilateur de macro, auquel cas on est
plus libre dans la syntaxe d'appel de macros, mais il faut savoir, pour
chaque format de texte, comment inclure du contenu xhtml (afin que le code
sorti par le compilateur de macro ne soit pas recompilé ensuite par le
contenu xhtml
3. Soit on fait en 2 étapes :
* première passe avec le compilateur de macro qui remplace l'appel à la
macro par une balise donnée (indépendante du moteur de formattage de texte)
* seconde passe avec le formatteur de texte
* troisième passe avec le compilateur de macro qui remplace la balise
donnée par le résultat des macros.
Des avis sur le sujet, et éventuellement sur une syntaxe souhaitée de
macros ?
--
Bruno
10 years, 5 months
Réunion IRC-Code du 28/10/2013
by Franck Paul
Réunion IRC-Code du 28/10/2013 21h
==================================
Présents
--------
* Tomek
* kozlika
* nikrou (vers la fin)
* mEga|work passé faire coucou
* Franck (aka moi)
1. Petite revue des tickets de la 2.6
-------------------------------------
http://dev.dotclear.org/2.0/ticket/1795, nikrou nous apprendra à la fin de
la réunion que tout va bien, un élément tiers provoquant le souci mentionné
dans ce ticket, que nous déclarons donc réglé !
TODO : http://dev.dotclear.org/2.0/ticket/1822, il s'avèrera au cours de la
réunion que ce ticket pointe un défaut de la documentation en ligne (
http://fr.dotclear.org/documentation/2.6/resources/plugins/admin/tabs) sur
le site et qui devra être mise à jour. nikrou se propose de regarder ça.
TODO : http://dev.dotclear.org/2.0/ticket/1823, je propose de m'en occuper
ASAP, personne ne conteste (je me demande si c'était par politesse ou par
fainéantise).
TODO : http://dev.dotclear.org/2.0/ticket/1732, xave a été réquisitionné
pour installer le plugin demandé.
2. Autres petites affaires de la 2.6
------------------------------------
Je pose deux-trois questions sur les affaires courantes de la 2.6, en
signalant le 1er billet sorti ce même jour sur la présentation des
nouveautés de la 2.6, puis poursuis en expliquant que les noix de
St-Jacques rôties avec une persillade, spa mal du tout, en fait !
On devise un peu de la partie anglaise de l'aide en ligne et du reste et
tombons d'accord sur le fait qu'il faudrait plus de contributeurs
anglophones pour ce faire. Pas bête. Du coup je consulte rapidement le
solde du compte bancaire de l'Asso Dotclear pour vérifier si on a assez
pour racheter Wordpress et ses contributeurs, … ah ben non, finalement y'a
pas assez, on va faire autrement :-p
Sur ces entrefaits je fais le pari que Wordpress, justement, sortira une
3.8 avec une admin réellement responsive, parce qu'ils seront trop jaloux
de la notre qu'elle est trop trop bien \o/ (d'ailleurs pour la 3.7 ils nous
avaient déjà piqué l'idée de l'indicateur de robustesse de mot de passe, …).
Nous tombons également d'accord pour dire que la mise à jour silencieuse
implémentée par WP est potentiellement source de problème (compatibilité de
plugins, …). Cela dit, on peut toujours y réfléchir.
Ensuite nous devisons du temps qu'il fait dans le plus beau pays du monde :
le Pays Bigouden.
3. Revue générale et stratégique pour la prochaine version 2.7
--------------------------------------------------------------
. (c'est secret alors on peut pas en parler pour l'instant sinon WP, les
fourbes, y vont nous piquer toutes nos super idées qu'elles sont trop pas
révolutionnaires)
4. Questions diverses
---------------------
nikrou arrive, nous reprenons la réunion à zéro, puis, 17 secondes plus
tard, déclarons la réunion terminée et reprenons chacun nos vie ordinaires
:-)
--
Franck
10 years, 5 months
