Fonctionnalité
Le plugin permet d’afficher des parties d’échecs. Les parties sont des documents de type "PGN" placés dans un article.
Le rédacteur prépare son article et y télécharge un ou plusieurs documents de type "pgn". Ce type de fichier est simple à produire pour un joueur d’échecs depuis n’importe quel logiciel (de préférence GPL, bien sur). Le mot clé PGN est associé à l’article ... et c’est fini !
Donc, aucune préparation n’est nécessaire, il suffit de produire un fichier PGN et l’installer dans l’article.
Rédacteur
L’objectif est de faire simple pour les rédacteurs :
créer un article avec un texte d’introduction.
ajouter un ou plusieurs documents de type "pgn". Chaque document peut contenir une ou plusieurs parties (voir la description du format PGN).
associer un mot-clé à l’article (pour activer un squelette particulier grace au plugin "squelette par mot-clé").
Donc : aucune préparation (PALVIEW), pas d’applet, simplement un article et des documents attachés.
Remarque : en pratique il ne faut pas dépasser un total de quelques parties (moins de 10) sinon le temps d’analyse et chargement des documents devient trop long. Il est préférable de créer d’autres articles pour y placer les autres parties.
Administrateur / informaticien
Outre l’installation du plugin (qui nécessite CFG), l’administrateur devra utiliser de nouvelles balises, de préférence dans un squelette dédié. Le plus simple est alors d’utiliser le plugin "squelette par mot-clé" qui permet de définir un squelette particulier pour un article selon la présence d’un mot clé.
Les nouvelles balises :
#PGN_ECHIQUIER : échiquier, boutons de navigation, sélecteur de partie.
#PGN_COUPS : coups de la partie avec commentaires, variantes.
#PGN_TAGS : tags provenant du fichier PGN.
#PGN_DOCUMENTS : demande le chargement des documents PGN.
L’utilisation normale du plugin est de placer l’échiquier dans un bloc fixe à l’écran tandis que la partie elle-même peut défiler. Le plugin fait alors automatiquement défiler la partie pour que le coup joué soit toujours visible à l’écran (ça fonctionne très bien avec Firefox et assez correctement avec IE).
Visiteur : Affichage de l’article
L’affichage peut contenir les éléments suivants :
- un diagramme d’échecs
- l’échiquier avec les pièces
- des bouton de navigation (coup précedent, suivant, début, fin)
- un sélecteur de partie (si plusieurs parties sont présentes dans les documents chargés).
- la liste des coups joués avec les variantes, commentaires
- la liste des "tags" (informations générales sur la partie)
Le visiteur peut utiliser les boutons de navigation ou cliquer sur un coup dans la liste. L’échiquier est mis à jour tandis que le coup est affiché en surbrillance.
Comment ça marche ? (un peu de technique)
Le principe de base est de s’appuyer sur un script JAVASCRIPT qui est appelé par les différentes balises. Le chargement des fichiers PGN est délégué à un script PHP ce qui garantit un bon fonctionnement et une performance correcte.
Les inconvénients majeurs de JAVASCRIPT sont :
le risque de dysfonctionnement selon le navigateur ou le système d’exploitation
un temps de traitement trop important pour des documents PGN un peu conséquent.
J’ai pu constater ces 2 problèmes...
Donc, le PHP est utilisé pour lire un document PGN, analyser les parties et envoyer une information directement exploitable au JAVASCRIPT qui est chargé de l’affichage dans le navigateur.
Note : il serait possible d’utiliser AJAX pour dialoguer entre JAVASCRIPT et PHP, en pratique le protocole est assez simple pour être directement implémenté.
PGN : qu’est ce que c’est ?
La difficulté d’utilisation d’un fichier PGN réside dans le fait que la syntaxe est souple et minimaliste. En clair, il faut une "intelligence" qui suive l’état de l’échiquier pour pouvoir comprendre le prochain coup. L’analyse nécessite donc un peu de temps.
Version 1.2
Quelques corrections internes (paramètres mal gérés).
test compatibilité SPIP 2.0 : OK mais le plugin "Squelette par mots clé" ne fonctionne plus, il faut donc trouver une autre astuce pour choisir un affichage spécial.
Modifications à venir
Amélioration des performances :
Ne pas charger la totalité des parties mais seulement la liste. Ne réaliser l’analyse et le chargement que lors de l’appel de chaque partie.
gérer un cache des parties analysées à la manière de SPIP. Ce cache devra être alimenté lors de l’analyse d’un document et vidé lors de la modification d’un document. (complexe)
remplacer les images des pièces par les caractères unicode correspondants.
TAG "Annotator" de Fritz : il ne devrait pas bloquer l’affichage, je debogue ==> j’ai découvert cela en publiant une partie de genas, qui elle fonctionnait, et la différence était à ce niveau
RSS 2.0