Teddy Payet

Plugin « Info SPIP »

Teddy Payet — 2014-07-21T16:00:00Z

Ce plugin permet d'avoir une page, dans la partie privée, donnant la fiche identitaire de votre site et de votre serveur. Il offre aussi la possiblité d'avoir une page au format xml (dans la partie publique) reprenant les même informations que la page du privé.

Ce plugin après activation fournira une page accessible par http://example.org/ecrire/?exec=info_config.

Les pages livrées par le plugin http://example.org/ecrire/?exec=configurer_info_config et http://example.org/ecrire/?exec=info_config ne sont accessibles qu'aux webmestres du site.
En effet, ces informations, plutôt techniques, n'intéressent pas les administrateurs mais les développeurs.

Plus d'informations :

Liste des identifiants de menu de SPIP

Teddy Payet — 2014-04-13T11:41:40Z

Lorsqu'on développe un plugin pour SPIP, on ajoute quasi systématiquement une entrée dans le menu du back office de SPIP pour pouvoir accéder à nos pages. Mais voilà, on ne connait pas par coeur le nom de chaque menu et sous menu. Alors voici une liste de tous les menus connus.

Préambule

Qui dit menu, dit insertion du bon code dans plugin.xml ou paquet.xml. Voici le code préconisé :
Pour paquet.xml (SPIP 2.x et SPIP 3.x) :

 chemin de l'icone chaine de langue du titre nom de l'exec arguments transmis

Pour paquet.xml (SPIP 3.x) :

Comme vous pouvez le voir, le code change un peu mes les attributs restent les même. Il faut juste ne pas oublier que c'est "menu" dans paquet.xml et "bouton" dans plugin.xml.

Les identifiants de menu

Voici la liste selon le contexte de version :

SPIP 2.x
cf. http://core.spip.org/projects/spip/repository/entry/branches/spip-2.0/ecrire/inc/bandeau.php#L30
cf. http://core.spip.org/projects/spip/repository/entry/branches/spip-2.1/ecrire/inc/bandeau.php#L30

Identifiant du parent	Titre	Commentaires
accueil	Accueil	On ne l'utilise quasiment jamais
naviguer	Édition	Contient généralement les liens vers les objets enregistrés en BDD
forum	Forum	Tout ce qui est interactivité avec l'internaute mais aussi entre auteurs
auteurs	Auteurs
statistiques_visites	Statistiques	Ne s'affiche que si vous avez activé les visites sur votre site
configuration	Configuration	Toutes les pages de configuration du site, plugins compris

SPIP 2.x avec le plugin Bandeau
cf. http://zone.spip.org/trac/spip-zone/browser/_plugins_/bandeau/inc/bandeau.php#L45

Identifiant du parent	Titre
bando_accueil	Accueil
bando_edition	Édition
bando_publication	Publication
bando_reactions	Activités
bando_squelette	Squelettes
bando_administration	Maintenance
bando_configuration	Configuration
outils_collaboratifs	Sans titre
outils_rapides	Sans titre

SPIP 3.0
cf. http://core.spip.org/projects/spip/repository/entry/branches/spip-3.0/ecrire/inc/bandeau.php#L52

Nom du parent	Titre
menu_accueil	Accueil
menu_edition	Édition
menu_publication	Publication
menu_activite	Activités
menu_squelette	Squelettes
menu_administration	Maintenance
menu_configuration	Configuration
outils_collaboratifs	Sans titre
outils_rapides	Sans titre

Remarques

Comme vous pouvez le voir, en SPIP 2.x, avec le plugin "Bandeau", on a eu les prémisses du menu en SPIP 3.0. Tout comme l'appel dans paquet.xml, on a changé "bando" pour "menu". Ce qui est plus logique en soit.
Il y a aussi l'apparition de outils_collaboratifs et outils_rapides. Le premier contient tout ce qui est accès à la messagerie, au calendrier et au forum interne. Le second contiendra tous les boutons de création d'un objet éditorial (cf. ajout d'un élément dans une des tables de SPIP).
Ces 2 menus sont disponibles mais cela ne veut pas dire que c'est obligatoire lorsque votre plugin crée de nouveaux objets éditoriaux. Avoir un menu long comme le bras ne vous plaira pas très certainement ! ;-)

Quoiqu'il advienne, vous pouvez mettre pour un plugin compatible SPIP 2.x, l'insertion de vos boutons pour SPIP sans le plugin "Bandeau" et avec "Bandeau". Voici un exemple : http://zone.spip.org/trac/spip-zone/browser/_plugins_/projets_sites/client/trunk/plugin.xml#L28

Et voilà, vous avez tous les identifiants sous la main maintenant ! Vous ne pourrez plus vous tromper !

SPIP - Documentation technique : nomenclature

Teddy Payet — 2013-12-02T07:02:42Z

Lorsque nous avons l'utilité d'un nouvel objet (éditorial) dans SPIP, il est plus simple et même conseillé de passer par la création d'un plugin.
A force de créer des plugins, je me suis créé une nomenclature d'écriture des fichiers. En fait, je n'ai rien inventé de particulier. La base des fichiers est créée par le plugin "La Fabrique" (merci marcimat !).

Préambule

Malgré un titre "racoleur", cet article ne va pas traiter de la nomenclature d'écriture des fichiers de SPIP mais d'une nomenclature que j'ai mis en place personnellement.
Si vous désirez avoir des informations particulières sur la nomenclature de SPIP (ses API, etc.), je vous conseille quelques sites :
– Programmer avec SPIP ;
– Documentation du code de SPIP ;
– Autodoc de SPIP : une zone particulière de code.spip.net. Il est autoalimenté par le PHPDoc inséré dans le code source de SPIP.
– SPIP-Contrib ;
– L'annuaire des plugins de SPIP.

De plus, je ne traitera pas non plus de l'utilisation du plugin La Fabrique. Sa page de documentation est très complète.

Contexte

Pour l'expression de cette nomenclature, je prendrai pour ligne de conduite la création d'un objet "vins". Cela sera plus parlant. Je me réfèrerai, sauf mention contraire, toujours à cet objet éditorial.
Le but de cet article n'est pas la création d'un plugin mais la méthodologie pour une bonne nomination des fichiers et des chaines de langue associées.
De ce fait, nous partons de zéro pour arriver à la fin de ce cycle à la réalisation de l'affichage de la documentation technique.

Vif du sujet

La Fabrique crée les bons fichiers selon les API de SPIP. Au départ c'est un "clicodrome". Mais il ne nous dispense strictement pas de penser, au préalable, notre structure de données. On ne fonce pas tête baissée dans un projet.

Dans le formulaire "Ajouter un objet éditorial", nous pouvons rajouter tous les champs nécessaires :

nom
millésime
id_producteur
id_couleur
id_appellation
id_region
etc.

Une des premières choses à laquelle je fais attention autant que possible est le respect de "id_objet". La Fabrique créera la table spip_vins (au pluriel) associé à mon objet "vin". De là, il crée un ID : id_vin (mon équivalent à "id_objet" cité en début de paragraphe.)
Surtout, ne modifions pas cela même si la Fabrique nous le permet. Vous comprendrez pourquoi un peu plus loin.

Ici, ce n'est pas tellement le nom et/ou le nombre de champs qui m'intéresse dans "ma" nomenclature. Le but de cette dernière est de générer semi-automatiquement une information technique sur la table et ses champs grâce aux fichiers de langue.

La Fabrique adopte donc la philosophie des API de SPIP. Lorsque nous respectons "id_vin" pour l'objet "vin", la Fabrique créera les fichiers :
– lang/vin_fr.php : toutes les langues liées à l'objet "vin" ;
– lang/vins_fr.php : toutes les chaînes liées au plugin ayant le préfixe "vins" ;
– lang/paquet-vins_fr.php : les chaînes de langues généralement utilisées dans paquet.xml.

Si nous n'avions pas utilisé "id_vin" mais par exemple "ref_vin", la Fabrique aurait créé le fichier lang/ref_vin_fr.php… ce qui ne nous aurait pas arrangé pour la suite. J'ai rencontré ce cas récemment.

Un objet, deux objets, etc.

Pour aller un peu plus loin, nous allons créer une table pour les producteurs de vins. Nous nommerons cette table spip_vins_producteurs, l'objet associé sera "vins_producteur". Laissez-le tel quel.
Lorsque nous serons dans l'espace privé de SPIP sur la fiche d'un producteur, nous aurons une URL de type ?exec=vins_producteur&id_vins_producteur=XX

Remarque

J'aurai pu créer la table spip_producteurs. Mais le soucis est que ce nom est trop générique et pourrait se télescoper avec une autre table qui n'a rien à voir avec notre plugin.

Vous aurez compris que l'ID du producteur est sous la forme "id_vins_producteur". La Fabrique a enlevé le "s" final à producteur.

Normalement, vous m'avez suivi sans trop de soucis jusqu'à maintenant sans pour autant savoir où je voulais en venir. Pas vrai ? ;-)
Alors, continuons :

Pour la chaîne de langue de l'objet "vins_producteur", la Fabrique va créer lang/vins_producteur_fr.php.
Ça ne vous rappelle rien ? Je vous aide un peu : lang/vin_fr.php… lang/objet_fr.php

C'est la règle d'écriture adoptée par la Fabrique.

Rappel

Dans mes précédents articles, je vous avez montré (grâce à b_b, denisb et kent1) comment reconstruire une chaîne de langue pour l'afficher sur notre page :
[(#VAL{#GET{prefixe}}|concat{':nom_du_champ'}|_T)]

On ne change pas une équipe qui gagne.

Créer les chaînes de langue

Nous allons utiliser cette même règle pour construire notre documentation technique. Une sorte de PHPdoc "linguistique" à la SPIP.

Remarque

Mon but dans cette nomenclature n'est pas de documenter des fonctions (au sens PHP) car il existe des méthodes robustes aujourd'hui. SPIP a adopté, sous l'impulsion de Marcimat, PHPDoc pour cette documentation.

Dans ma documentation technique, en fait, je désire afficher 4 choses dans un tableau :

le nom du champ ;
son label ;
sa définition MySQL ;
son aide à la saisie (explication) ;
et sa documentation.

Pour cela, on va prendre l'habitude d'écrire nos chaînes de langue sous la forme :

label_champ
label_champ_explication
label_champ_documentation
La définition MySQL du champ est directement issu des variables globales de SPIP ce qui rend inutile de créer une chaîne de langue pour elle. Nous aurons alors 3 chaînes de langue par champ.

Donc, soit pour notre objet vin, nous aurons :

label_id_vin
label_id_vin_documentation
label_id_vin_explication
label_nom
label_nom_documentation
label_nom_explication
label_millesime
label_millesime_documentation
label_millesime_explication
etc.

Dans les fichiers de langues adéquates, nous devons y renseigner ce dont nous avons besoin.

Afficher le contenu sur la page de documentation

Bon, tout est prêt maintenant pour construire notre page, y compris le contenu. Nous devons maintenant créer un fichier "prive/squelettes/contenu/vins_doc.html". Voici le code à y insérer :

[(#SET{prefixe,'vins'})]
<h1>[(#VAL{#GET{prefixe}}|concat{':documentation_technique'}|_T)]</h1>
#SET{tables, #LISTE{'vin','vins_producteur'}} <B_tables>
<BOUCLE_tables(DATA) {source table, #GET{tables}} {si #SESSION{webmestre}|=={oui}}>
#SET{spip_table,#VAL{'spip_'}|concat{#VALEUR,'s'}}
<B_info_table>
<table>
<BOUCLE_info_table(DATA) {source table, #EVAL{$GLOBALS['tables_principales'][#GET{spip_table}]}}{cle==field}> <caption>#_tables:GET{spip_table}</caption>
<thead> <th>[(#VAL{#GET{prefixe}}|concat{':nom_du_champ'}|_T)]</th> <th>[(#VAL{#GET{prefixe}}|concat{':definition_mysql'}|_T)]</th> <th>[(#VAL{#GET{prefixe}}|concat{':label_label'}|_T)]</th> <th>[(#VAL{#GET{prefixe}}|concat{':documentation'}|_T)]</th>
</thead>
<B_label>
<BOUCLE_label(DATA) {source table, #VALEUR}>
<tr>
<td><strong>#CLE</strong></td>
<td><em>#VALEUR</em></td>
<td>[(#VAL{#_tables:VALEUR}|concat{':label_',#CLE}|_T)]</td>
<td>[<strong>[(#VAL{#GET{prefixe}}|concat{':aide_a_la_saisie'}|_T)]</strong><br/>
(#VAL{#_tables:VALEUR}|concat{':label_',#CLE,'_explication'}|_T)<br/>]
[<strong>[(#VAL{#GET{prefixe}}|concat{':documentation'}|_T)]</strong><br/>
(#VAL{#_tables:VALEUR}|concat{':label_',#CLE,'_documentation''}|_T)]</td>
</tr>
</BOUCLE_label>
</B_label>
</BOUCLE_info_table>
</table>
</B_info_table>
</BOUCLE_tables>
</B_tables>

Ce code va construire le tableau comme prévu.
Sur cette page, on peut voir que parfois la chaîne de langue ne s'affiche pas. En tout cas, pas son contenu mais bel et bien la chaîne en elle même sans les underscores. Exemple : label id vin, label id vin documentation, label id vin explication.
La raison en est très simple : nous n'avons pas encore renseigné cette chaîne de langue.
Mais parfois, nous n'avons rien à dire de particulier sur un champ. Il parle de lui même. Alors l'astuce est de créer tout de même cette chaîne de langue dans le bon fichier et de mettre un espace blanc/vide, soit 'label_id_vin_documentation' => ' '.

Astuce

Pour ceux qui ont lu le code ci dessus, vous avez pu voir un [(#SET{prefixe,'vins'})]. En fait, ceci est pour nous simplifier la tâche si on désire mettre ce bout de code dans un autre plugin. Il nous suffira de mettre le préfixe de notre nouveau plugin ici pour que la chaîne de langue se construise.

Remarque

Denisb nous a rappelé l'existence depuis SPIP 3.0.13 d'une nouvelle écriture de construction d'une chaîne de langue. Vous pouvez voir son commentaire ici et ici.

La page étant construite, il nous faut maintenant compléter nos différentes chaînes de langue. Alors à vos claviers et rendez-vous dans mon prochain article.

Vous pouvez lire aussi :
– SPIP - Documentation technique : nomenclature
– SPIP - Documentation technique : construction des pages
– SPIP - Documentation technique : mise en conformité

Une boucle DATA pour avoir les dernières versions de SPIP

Teddy Payet — 2013-09-24T15:00:00Z

Avec SPIP 3, nous avons nativement la boucle DATA issue du plugin Itérateur réalisé par Fil. Cette boucle nous permet de parser presque tout ce que l'on veut ! C'est purement magique !

Un xml

Voici un exemple d'utilisation de la boucle DATA à partir d'un xml obtenu de la page http://files.spip.org/spip/archives/

    [(#VALEUR{0})]

Explications

– l'url spécifiée est fournis par la console de YQL : http://developer.yahoo.com/yql/cons... (Cliquez sur "Test" pour voir le rendu)
Le résultat de cette première boucle DATA est un tableau qui contient uniquement les liens vers les archives de SPIP. Il nous suffit de le passer en critère à une seconde boucle DATA.
– grâce au critère {cle==a}, on récupère uniquement les clés contenant 'a' (équivalent à la balise html ).
– #VALEUR{href} : récupération de l'attribut href de la balise .
– #VALEUR{0} : récupération du contenu de la balise .

Et voilà. Nous avons sur la page toutes nos versions officielles de SPIP.

J'étofferai un peu plus tard cet article avec une boucle DATA avec une source YQL.

Modifier un plugin sur la zone de SPIP

Teddy Payet — 2013-01-16T14:11:06Z

J'ai écris récemment un article sur Comment faire des commit sur la zone de SPIP. Ce présent article continue sur la même lignée. Et je vous parlerai de comment corriger un fichier d'un plugin en local. Puis committer vos modifications.

Préparation

Il va arriver que vous ayez besoin de corriger ou de faire évoluer un plugin de la zone. Pour cela, il vous faudra faire une copie du répertoire de ce plugin sur votre ordinateur. Je vais prendre pour exemple le squelette de la boussole de SPIP. Voici la démarche :

créer un répertoire dans vos "Documents" en le nommant "zone_spip" ;
Puis depuis votre logiciel de ligne de commandes (un terminal), positionnez vous dans ce répertoire.
```
cd ~/Documents/zone_spip/
```
La ligne de commande ci-dessus est la méthode sous MacOS X.

On crée une copie en local

Cela fait, on faire une copie du répertoire de notre plugin dans ce répertoire.

svn checkout svn://zone.spip.org/spip-zone/_galaxie_/boussole.spip.org/

Aller depuis votre explorateur de fichier pour voir si vous avez bien le répertoire et ses fichiers.

Modifier nos fichiers

Vous pouvez maintenant modifier vos fichiers. Toujours pour notre exemple, j'ai modifié la ligne #8 du fichier boussole_spip.xml. J'ai remplacé :

par ça :

Vérifier nos modifications depuis le terminal

Puis, depuis votre terminal, nous allons nous repositionner dans ce nouveau répertoire pour y voir ce que nous avons modifié, ajouté, etc.

cd boussole.spip.org/

Pour vérifier le contenu de ce répertoire, tapez cette ligne :

ls -las

Ce qui vous donnera quelque chose de ce genre :

total 48
0 drwxr-xr-x 10 teddy staff 340 16 jan 13:59 .
0 drwxr-xr-x 3 teddy staff 102 16 jan 13:59 ..
0 drwxr-xr-x 7 teddy staff 238 16 jan 14:03 .svn
8 -rw-r--r-- 1 teddy staff 1960 16 jan 14:00 boussole_spip.xml
0 drwxr-xr-x 4 teddy staff 136 16 jan 13:59 images
8 -rw-r--r-- 1 teddy staff 1185 16 jan 13:59 inc-head.html
8 -rw-r--r-- 1 teddy staff 287 16 jan 13:59 inc-pied.html
8 -rwxr-xr-x 1 teddy staff 3855 16 jan 13:59 jquery.backstretch.js
8 -rw-r--r-- 1 teddy staff 1050 16 jan 13:59 perso.css
8 -rw-r--r-- 1 teddy staff 589 16 jan 13:59 sommaire.html

On est bon. :-)
On va maintenant regarder les différences entre ma versions locales et le répertoire sur la zone de mon squelette :
svn st
Résultat :
M boussole_spip.xml

Vous désirez voir si ce que vous avez modifié est bien pris en compte ? Rien de plus simple :
svn diff
Résultat :

Index: boussole_spip.xml
===================================================================
--- boussole_spip.xml	(revision 69027)
+++ boussole_spip.xml	(working copy)
@@ -5,7 +5,7 @@   
- 
+

Cool !

Étape finale : envoyer nos modifications au serveur

Il ne nous reste plus qu'à committer notre modification sur la zone :
svn commit -m "Mon message ici"
Ça mouline, ça mouline et on a quelque chose de ce genre afficher :

Sending boussole_spip.xml
Transmitting file data .
Committed revision 69028.

Tadaaaa ! C'est fini. Vous pouvez voir le résultat de mon exemple sur la zone à cette adresse 69028.

Conseils

Si vous êtes amené à corriger, modifier régulièrement des plugins sur la zone, je vous conseille de construire la même arborescence que la zone :

_core_
_galaxie_
_plugins_
_squelettes_
_themes_

Soit ceci pour référence : http://zone.spip.org/trac/spip-zone...
Et dernière cerise sur le gâteau, créez aussi un répertoire "archivelist" qui n'aura de but que de contenir le fichier "archivelist.txt" (cf. Publier archivelist.txt via svn/terminal)

Source
En plus de mon article précédent, je me suis aidé de ces articles sur contrib :

Plugin Chants

Teddy Payet — 2012-03-12T11:18:31Z

La documentation officielle de ce plugin est publié sur le site SPIP-Contrib.net. Pour toutes informations ou SAD, merci d'utiliser le forum sur la documentation officielle.

Présentation

Le plugin Chants a été créé sur la même structure de chants du logiciel open source, OpenSong. Il permet de référencer des chants pour une présentation en live par exemple. Ou tout simplement les référencer sur votre site internet.

Installation

Il s'installe comme tous les plugins http://www.spip.net/fr_article3396.html
Le plugin nécessite :
– Saisies ;
– Zippeur.

Il utilise aussi Zpip et Compositions. Mais ces derniers ne sont pas obligatoires pour la bonne utilisation de Chants.

Les balises

Voici la liste des balises offertes par ce plugin :
– #TITRE
– #ALIAS : il arrive parfois qu'on connaisse un chant sous un autre nom, un alias.
– #COPYRIGHT
– #ID_CHANT
– #ID_RUBRIQUE
– #ID_SECTEUR
– #DATE_ANNEE : année de sortie du chant ;
– #DATE : date de publication du chant ;
– #NUMERO : le numéro du chant ;
– #PAROLES : les paroles du chant ;
– #PRESENTATION : l'ordre des couplets du chant. Exemple : [V1] [V2] [C] [V1] [R] ;
– #LIGNE_PRINCIPALE
– #CCLI : le numéro du chant au répertoire de CCLI
– #CAPO : un capo (ou capodastre) est un chiffre de 1 à 5 déterminant la position du capo sur le manche de la guitare ;
– #TONALITE
– #TEMPO
– #SIGNATURE
– #STATUT : en cours de rédaction, proposé, publié, refusé, à la poubelle ;
– #LANG
– #ID_TRAD

Les objets liés

Vous pouvez ajouter des mots-clés à un chant mais aussi associer un auteur. L'auteur associé au chant sera ajouté en tant qu'authors lors de l'exportation du fichier xml (cf. ci-dessous).
Si nécessaire, vous pouvez joindre un logo au chant (facultatif).

Les squelettes disponibles

Le plugin fournit un squelette par défaut pour le public. Il affichera toutes les balises du chant.

Intégration rapide sur votre site

Si vous utilisez le plugin Z et Compositions, il existe une composition pour une rubrique dédiée aux chants. Il vous suffit de sélectionner cette composition pour la rubrique désirée.

Exporter en xml

Vous pouvez exporter chaque chant au format xml compatible OpenSong depuis l'espace privé, sur la page du chant.
Mais vous pouvez l'intégrer depuis les pages publiques grâce à cet appel, dans une boucle CHANTS :

[(#SET{filename, [(#CCLI|replace{' ',''})_][(#TITRE|textebrut|replace{\W})]})] [(#URL_PAGE{chant_export.xml}|parametre_url{'id_chant',#ID_CHANT}|parametre_url{'filename',#GET{filename}})]

Le paramètre filename : c'est le nom du fichier qui sera enregistré sur votre bureau. Si vous ne renseignez pas ce paramètre, le nom par défaut sera "chant_export" et vous donnera de ce fait un fichier chant_export.xml.

Les modèles

Vous pouvez exporter une rubrique contenant les fichiers xml compatible OpenSong.
Pour cela, utilisez l'appel au modèle suivant dans une boucle renseignant l'identifiant de la rubrique :

[(#MODELE{repertoire_zip}{id_rubrique})]

Ce modèle utilise le plugin Zippeur cité en début d'article. De ce fait, vous aurez un fichier zip sous la forme "rubrique_XX.zip" où XX est le numéro de la rubrique.
Le fichier sera enregistré dans un sous-répertoire de "local/". Il sera recréé si vous mettez à jour un chant dans ladite rubrique.
Ce fichier, décompressé, pourra être placé dans votre répertoire "Songs" du logiciel OpenSong (se référer à la documentation de ce logiciel pour plus d'informations).

Le XMLRPC et les possibilités offertes à SPIP

Teddy Payet — 2012-02-03T10:19:08Z

Depuis quelque temps, on a pu voir circuler sur twitter des messages de personnes espérant voir un jour une application iPhone permettant de publier des articles sur SPIP tout comme l'application officielle de Wordpress

J'ai regardé en début de semaine par curiosité le code de l'application de WP. J'ai pu constaté que cette application utilise entre autre le langage XML-RPC (en) pour communiquer avec votre installation WP. Bien entendu, on utilise le langage de développement de prédilection de l'iPhone : l'Objective-C.

Pas de soucis…

Ici, ce qui nous intéresse est la passerelle entre l'application et wordpress : XML-RPC.
En faisant une petite recherche sur notre ami google, @ on trouve ceci :

En voyant cela, un espoir est né : on peut voir un jour arriver une iApp SPIP nous permettant de publier, voir de gérer entièrement notre site SPIP depuis nos iBidules !

Avenir

Mais les possibilités ne s'arrêtent pas là. On peut imaginer pleins d'autres applications avec ce protocole :
– système de push pour publier des articles par emails ;
– un trackback de liens (?) ;
– etc.

Applications externes

Il existe des applications de bureau (≠ iApps) qui permettent grâce à la passerelle XML-RPC de publier des articles sur votre site. En voici quelques unes :

Scribfire, une extension pour Firefox http://scribefire.com/ ;
BlogDesk http://www.blogdesk.org/en/index.htm ;
Windows Live Writer http://explore.live.com/windows-liv... ;
MarsEdit http://www.red-sweater.com/marsedit/ ;
Raven http://www.zoundryraven.com/ ;
Ecto http://illuminex.com/ecto/ ;
etc.

Conclusion

Les possibilités sont très grandes.
Voyez-vous d'autres perspectives entre XML-RPC et SPIP ?

Des posts sont déjà apparus sur les réseaux sociaux :

L'opendata… Mon tour (rapide) des lieux.

Teddy Payet — 2012-01-25T23:19:07Z

Depuis le mois de novembre, je m'intéresse à la vague de l'Open Data en France. L'Open Data (une donnée ouverte), selon Wikipedia, est une information publique brute, qui a vocation à être librement accessible. La philosophie pratique de l'open data préconise une libre disponibilité pour tous et chacun, sans restriction de copyright, brevets ou d'autres mécanismes de contrôle.

Data.gouv.fr

Vous n'êtes certainement pas passé à côté de l'arrivée en ligne du site data.gouv.fr, le site officiel du gouvernement pour l'Open Data. Il a été réalisé par Etalab, une mission sous l'autorité du Premier Ministre chargée de l'ouverture des données publiques et du développement de la plateforme française. Ils ont réalisé plusieurs ateliers de travail autour de l'ouverture des données, constituant la charnière de data.gouv.fr.

Data.gouv.fr

http://data.gouv.fr

Ce site contient :
– 352 000 jeux de données publiques et plus ;
– 90 producteurs de données publiques ;

C'est pas mal comme chiffre, mais ce n'est qu'un début. Les données sont fragmentées par centre d'intérêts. Vous trouverez rarement de fichiers comprenant TOUTES les données d'une même thématique. Cela pourrait représenter un fichier de plusieurs milliers de ligne pour des données INSEE. Ce qui ne serait pas simple à l'utilisation par une machine (grosses ressources pour son exploitation).
Le plus gros soucis, en fait, n'est pas le nombre de lignes… Mais le format des fichiers. L'Open Data se veut ouvert. Pourtant, une très grande partie est dans un format fermé, propriétaire comme Excel. Voici, au 25 janvier 2012, la liste des formats présents sur le site :
– 293650 xls
– 2144 csv
– 216 txt
– 148 doc
– 117 shp
– 90 xml
– 50 pdf
– 44 Autre

Si vous additionnez tous ces chiffres, cela nous fait 296459 et non 352000 et plus… Peut-être une erreur dans leur calcul fichier par fichier. Cela dit :
99% des fichiers, ou jeux de données, sont au format XLS. Ce format peut s'expliquer sur le fait que c'est un format usuel. Qui n'a pas dans son administration Microsoft Office sur son poste ?
On peut comprendre ce choix. Mais il aurait été plus en adéquation avec la pensée de ce site de mettre une version CSV (Comma-separated values) de ces fichiers XLS.

Le vœux pieu est que ces données soient utilisables par des machines et créateur d'activités innovante sur l'exploitation des données.
L'idée me séduit énormément, pas par une envie mercantile, mais par le partage des informations au plus grand nombre. Cher à ma pensée.

Data.gouv.fr autrement

Si on parle de Data.gouv.fr, nous ne pouvons garder sous silence le site de debug de data.gouv.fr. Mais attention, ce n'est pas le gouvernement qui a mis ce dernier en place. Ce site est une initiative de Regards Citoyens. À l'heure actuelle, où j'écris ces quelques lignes, il n'existe pas encore de solution sur le site de data.gouv.fr pour signaler un problème de données ou technique lié à leur site.
“Regards Citoyens” est auteur de plusieurs actions dont celle-ci : Nos Données. Ce site vise à apporter plus de visibilité aux données publiques, l'Open Data, librement accessibles à tous.

Les initiatives locales

Autres que l'initiative gouvernementale, il existe des initiatives locales. Parmi elles, nous pouvons trouver :

Nod (Nantes ouverture des données)

http://data.nantes.fr/

Rennes Métropole en accès libre

http://www.data.rennes-metropole.fr/

Paris data

http://opendata.paris.fr/

Territoire Montpellier Numérique

http://opendata.montpelliernumerique.fr/

Portail OpenData - Communauté urbaine de Bordeaux

http://data.lacub.fr/

GrandToulouse.data

http://data.grandtoulouse.fr/

etc.

En plus de l'aspect graphique des sites, je trouve les données beaucoup plus accessible que le site du gouvernement.
Vous pourrez trouver une liste presque exhaustive des initiatives locales sur le site de LiberTIC grâce une carte géographique créée et mise à jour par leur soin : http://libertic.wordpress.com/2012/...
Petite anecdote : ce nom a un désavantage, voyez-le par vous même… Sans commentaire.]

Constat ou rêve inavoué

Toutes ces données viennent d'un bon souhait : la transparence de l'État et des collectivités.
Malheureusement, je constate un manque d'informations pratico-pratiques.

C'est bien de savoir qu'il y a eu tant de voix pour telle ou telle élection, sa répartition, que tel budget a été attribué pour tel projet de logement, d'aménagement urbain. Mais, il manque des informations pratiques :
– Les horaires des administrations ;
– La liste des entreprises d'une commune (les coordonnées, les heures, etc.) ;
– Les activités de la commune ;
– etc.

Leur utilité ? Développer des services au citoyen dans leur vie courante, augmenter l'activité économique d'une zone géographique. Informer les nouveaux arrivants dans une ville des infrastructures de la ville, les entreprises existantes, etc.
La porte est grande ouverte aux perspectives. A chacun de la saisir.

Et vous, qu'en pensez-vous ?