Valery Fremaux

Bon, dans ce cas c'est réglé, ce qui conduit à donner quelques indications sur des reprises de modules ou blocs pre 1.8 vers du Strict XHTML :

• vérifier les <input> des formulaires :
  • vérifier le / de la fin : <input ... />
  • vérifier d'éventuels attributs sans valeur : selected ou checked, on les écrit souvent simplement alors que le XHTML demande selected="selected" et checked="checked"
• Vérifier les <br> qui doivent s'écrire <br/>
• Vérifier les <img> qui doivent aussi se terminer par un slash.
• vérifier toutes les URL des liens et notemment celles qui contiennent des couples paramètres=valeur : <a href="index.php?param1=valeur1&amp;param2=valeur2..."> 
• laisser le vérificateur intégrer déceler les autres erreurs (balises non fermées, éléments non attendus à cet endroit, ...).

Un point positif avec la 1.8.1+ : à part quelques très rares exceptions, les développeurs du Moodle core ont fait du bon boulot : les librairies moodle qui produisent quelque chose à l'écran fournissent du code compatible.

Donc : s'il y a erreur, il y de forte chance que ce soit dans des modules additionnels.

Le cas précédent (de l'article d'origine) est en fait la quatrième cause d'erreurs classiques. 

Pour tous ceux qui ont commencé à regarder la compatibilité de leurs blocs en 1.8.1, et après discussion avec Nicolas des H.Q. la version 1.8 va poser les difficultés que tous ce qui se frottent au XML validé vont connaître.

Comme me l'epliquait Nicolas, la décision de produire du XML validé vient entre autres que certains pays n'acceptent plus institutionnellement que des produits open-source qui produise du code validé et respectueux de l'accessibilité.

Recoder nos blocs et nos modules pour respecter ces conditions est indispensable puisque le DOCTYPE est passé en Strict par défaut dans la version 1.8.

Cela ne va pas sans surprise et difficultés :

• les messages d'erreur de validation sous Explorer sont tronqués.
• les messages d'erreur sous les deux (Mozilla et Explorer) sont pas toujours compréhensibles (exemple plus bas)
• les erreurs de validation ne sont pas identiques sous Explorer et sous Mozilla.

Voici par exemple une erreur (???) donnée par l'insertion d'une URL dans un $tabObject, bien difficile à comprendre

Erreur d'analyse XML : mal formé
Emplacement : http://127.0.0.1/WWW-MOODLE1_8_1-PHP/mod/techproject/view.php?id=16
Numéro de ligne 173, Colonne 47 :

<li class="first"><a href="view.php?id=16&view=description" title="Description"><span>Description</span></a></li>
----------------------------------------------^

Voilà ce que propose Explorer pour exactement la même page :

<>

Le symbole point-virgule était attendu. Erreur de traitement de la ressource http://127.0.0.1/WWW-MOODLE1_8_1-PHP/mod/techp...

>/>>/>

>/>>

D'après toutes nos discussions au MoodleMoot, il semble quand même plus sage de passer au moins par une étape 1.6 pour le passage en utf-8 de la base, mais j'avoue que je n'ai rarement observé les mêmes réactions que les autres sur ces migrations... donc d'autres avis seront judicieux.

L'idée de tester les "besoins réels" sur une application base de données est pas mal. Ceci permet de rapidement faire discuter les utilisateurs sur leurs réels besoins en matière d'information et les faire s'exprimer.

Pour la compétence technique ne t'inquiète pas. Il nous est possible de construire une ébauche complète d'un module, une fois tous ces petits besoins identifiés et collectés auprès des enseignants, laquelle ébauche contiendrait alors 90% du code technique minimal pour un module correct. Après, on pourrait dire : à toi de jouer !! (si ton niveau de php te permet d'adapter des fomulaires, des requêtes ou des tables et de te concentrer sur le "fronctionnel", on s'occupera des détails et des débugs un peu sévères).

Qu'est-ce que t'en pense ?

Une fois dans le CVS des contribs il nous sera possible de nous échanger les modifications successives jusqu'à pouvoir livrer le module aux lions. 

Nous pouvons maintenir une discussion simultanée pour établir la "stratégie de développement". Par exemple : faut-il un module "cahier de texte" et un "module d'absences" séparés et modulaires ou tout intégré ? Voilà typiquement des questions à débattre ou à explorer avant de commencer.

Moodlement tienne.

Valéry. 

Cher Thierry,

toutes les demandes déclenchées par ton post montrent l'intérêt répété pour des systèmes de notifications assez avancés comme conséquence du "cahier de textes".

Ceci tendrait au développement plus complexe qu'une application du module base de données, déjà très puissant en soi. 

Nous avons un groupe de travail sur le thème de la gestion des tâches dans Moodle, que j'ai constitué avec Jeff Graham aux Etats-Unis et qui essaye de fédérer tous ces modules "orientés tâches", un module "todo" assez proche du cahier de texte était à l'étude, mais pas encore amorcé.

Serait-tu intéressé par cet axe de développement concerté et éventuellement en commun ?

Cf la discussion : http://moodle.org/mod/forum/discuss.php?d=73474