suppression des derniers bouts de javascript sous forme de <script> dans l'espace prive (hormis gadgets)

changement de strategie pour l'affichage des gadgets : c'est ainsi plus rapide pour l'utilisateur, moins mechant pour le DOM, et ca s'approche d'une mise en squelettes. seule consequence negative : quand on desactive javascript les boutons qui ouvrent et ferment les blocs sont toujours la

Le dépot précédent ne respecte pas toujours l'interface qu'il décrit dans son message. Ca a le mérite de montrer ce qui se passe alors: faire Echo au lieu de Return au final est transparent en ASCII, abominable avec un autre encodage.

Les scripts appelables en Ajax sont à présent comme tous les scripts dans exec (i.e contenant une fonction exec_F_dist surchargeable). Le role d'index.php est seulement de tester si "var_ajax" est présent dans l'envoi, auquel cas il rajoute comme première ligne < ? xml etc ? > et transcode en Unicode le resultat de la fontion exec_F.

Autrement dit la seule chose qui distingue actuellement un script Ajax d'un autre, c'est que sa fonction exec_F retourne le flux à envoyer au client tandis que les autres font directement des echo. En calant tout le monde sur le premier comportement, tout script pourra alors s'exécuter en asynchrone, il suffira de mettre var_ajax=1 dans les parametre pour avoir les deux compléments indiqués ci-dessus (mais ils devraient sans doute s'intégrer aussi aux scripts à terme).

C'est la question de l'interface de programmation d'Ajax qui est posée.
En attendant de la stabiliser, le fichier index.php prend à sa charge l'aiguillage et le traitement opérés auparavant par ajax_page qui a été retiré du dépot, son contenu étant réparti en autant de fichiers inc/ajax_F.php qu'il contenait de fonctions F. 

Le mode d'appel est provisoirement encore "ecrire/?exec=ajax_page&fonction=F" en attendant mieux.

Asyncrhonisme du formulaire rendant virtuel un article. De nouveau le regret que le reste de la page ne reflètera pas le changement indiqué dans le cartouche du formulaire: le grand panneau 'Cet article redirige vers....' sera désynchronisé.

Deux remarques:

- en mode non Ajax ça marche toujours, mais la boite de saisie ne se rouvrira plus au rappel, faute de savoir qu'une modif a eu lieu là-dessus (mais elle est toujours ouverte en cas de signatures présente ou de messages);

- le cas des boutons radio est dérogatoire en Ajax, on se demande pourquoi.

Bravo pour les correctifs de [6966] Fil, sauf que ça faisait planter Safari qui ne voyait plus le nombre de saisies dans le formulaire. Corrigé. Maintenant tout l'échange Ajax est nickel.

quelques corrections ajax: charset & rotation de -90 deg & affichage de l'image rotative ; egalement retour des champs extra en bas de la page articles_edit

Répercuter la globale indiquant les formats de logos dans les endroits où on y fait référence (suite du [6883]).

La rotation des images passe en AJAX. Ce dépot implémente la tâche #487 de la meme façon que le dépot [6962] implémentait la tâche [486], sans inconvénients graphiques cette fois car c'est en fait plus facile (d'ailleurs la requete est en GET).

Au passage, nettoyage du script ajax_page car sa générité grandissante lui impose d'éviter les calculs inutiles. Il devrait s'améliorer encore.

- rajouter l'envoi d'en-tetes HTTP par la methode setRequestHeader;
- consulter $_REQUEST et pas $_POST qui n'est pas rempli dans ce cas !

En conséquence, pour chacun des scripts dans ecrire/actions qu'on voudra passer en AJAX, il faudra opérer ce changement, et à terme renoncer à spip_register_globals qui assurait la compatibilité avec les auto-globales à la php3.

Reste un problème: les envois en Ajax ne respectent pas le charset malgré plusieurs essais avec setRequestHeader, aussi bien en Get qu'en Post. A creuser.

Comme recommandé par [6959] les formulaires de description d'images et documents joints passent en Ajax: à présent, lorsqu'on veut nommer, décrire, dater ouredimensionner un fichier préalablement téléchargé, cliquer sur le bouton "Enregistrer" ne provoque pas le rechargement de toute la page, mais seulement du bloc contenant ce mini formulaire. L'effet est particulièrement appréciable quand on télécharge une archive de N fichiers au format Zip que l'on demande de déballer: la page présente alors les N mini formulaires qu'on remplit puis soumet en rafale sans attendre la réponse de l'un pour passer à l'autre. 

Quelques remarques:

Ce comportement est disponible autant pour la présentation horizontale en fin de page (scripts articles, naviguer etc) que pour la présentation verticale pour le script d'édition (script articles_edit) et tant pour les images que pour les documents. En contrepartie, il s'en est suivi une uniformisation graphique qui est un peu en régression comparée à l'existant. On peut s'en consoler par le fait qu'il y avait déjà des attributs style en dur plutot que des CSS, ce qui rendait cet aspect quand meme insatisfaisant. Ca fait une raison de plus de le reprendre.

Autre aspect graphique. Les fichiers joints sont présentés avec leur nom, leur type et leur vignette (std ou non) plus (quand on a les droit d'accès) le nom du fichier précédé du triangle dont le clic donne accès au bloc du formulaire. Ce bloc affiche le titre, le descriptif, et la date puis les balises permettant de les modifier; la soumission du formulaire provoque ce réaffichage initial, permettant de s'assurer que l'opération a bien eu lieu. En revanche, le titre AU-DESSUS de la vignette reste l'ancien (jusqu'au prochain rechargement complet de la page bien sur; un phénomène similaire existe pour le changement de statut des articles en simili-Ajax). C'est aussi à améliorer.

Pour le téléchargement lui-meme, le réaffichage complet reste la norme, le mode Ajax ne permettant pas le transfert asynchrone de fichiers (les alternatives connues à ce jour ne semblent pas très portables). De plus, changer le nombre de pièces jointes affecte presque toujours la mise en page, qu'il faut reconsidérer. Cet argument explique aussi pourquoi la suppression provoque aussi un réaffichage complet. Le seul cas échappant à cette problématique est l'association d'une vignette; il faut faire avec (ou plutot sans).

La transmission en Ajax aurait du se faire en Post, mais Firefox s'est révélé peu fiable dans ce mode. La méthode retenue est donc GET, et on verra  passer furtivement les arguments dans la barre de navigation. Pas beau, mais pas grave. 

Ce mode a été testé avec succès sur MacOSX avec Firefox et Safari. Avec Opera 9, les changements ont lieu mais le formulaire ne se réaffiche pas. Lorsqu'Ajax n'est pas connu du JavaScript du navigateur, le mode habituel est utilisé.

Poursuite de l'autonomisation des formulaires présents dans exec/articles mais aussi dans articles_edit, naviguer et breves_edit.
Cette fois c'est le formulaire de description des documents et images joints, qui est à présent produit par la fonction formulaire_modif_document, et traité par action/documenter.php

Comme pour [6947], la suite à donner est de passer à Ajax, pour éviter de recharger toute la page où le document se trouve, surtout quand elle contient un portolio.

Aussi dans ce dépot: ajout de l'apostrophe manque dans articles_tous (Thomas).

En fait il y avait un double bug dans [6950], c'est sans doute pourquoi le pb n'était pas apparent plus souvent.

Centralisation par une fonction 'acces_mots' des tests de droit de création de mots et groupe de mots.

Permettre la surcharge du selecteur de rubrique. Ca permet plus facilement de désactiver Ajax pour ceux qui n'aiment pas, et de fabriquer d'autres menus au besoin.

Depuis au moins le passage en SVN, js_menu_rubrique était desynchronisé alors qu'un meta était exclusivement faite pour éviter ça. Et code mort dans navigeur.

Depuis qu'on sait accepter visiteurs et redacteurs simultanément, faire apparaitre les 2 boîtes de sélections de même.

Pétouille graphique corrigée, et disparition de la fonction exec_affiche_article_dist dont le nom etait trompeur quant à l'API des scritps de exec/

Poursuite de l'autonomisation des formulaires présents dans exec/articles (cf [6934] et [6931]): le retrait, l'ajout et la recherche d'auteurs.

Deux suites à donner:

- ce code n'est pas loin d'etre partageable avec la recherche de participants dans le script source:spip/ecrire/exec/message.php (mais y en a-t-il vraiment
qui utilise la messagerie interne ?)

- il faudrait passer à Ajax, surtout pour la recherche dans des bases à beaucoup d'auteurs, ça permettrait d'avoir un réaffichage apparamment instantané, et de lancer  plusieurs ajouts d'auteurs en parallèle.

Quant à la non validation XHTML, elle atteint ici des sommets ;-).

accepter les . dans les noms de repertoires de plugins (d'autant plus que les paquets zippes s'appellent xxx_1.9, donc ca va pas etre anectodique ...)

Scorie dans la fusion des deux boucles en [6940]; fait tres mal en présence d'une boucle Documents. Corrige #480.

Verification des droits sur ecrire/data au démarrage d'une nouvelle ssion: plus systématique qu'au chargement de access.php (qui peut ne jamais etre chargé dans certains types d'utilisation d'un site), et devrait corriger sa précipitation dénoncée par #479.