La graine de Marcimat

Un crayon listant des liaisons

Matthieu Marcillaud — 2012-11-14T18:25:33Z

Les crayons, c'est facile d'utilisation, surtout quand on veut modifier des éléments de la table en cours de lecture. Mais lorsqu'il s'agit d'éléments liés, comme des mots clés sur des auteurs, le parcours est plus délicat !

Cet article présente une solution pour obtenir cela. Le code mériterait d'être amélioré, mais il présente une base de travail pour ceux qui aimeraient copier :)

Tout d'abord, précisons que cet exemple concerne SPIP 2.1. Certaines parties mériteraient d'être réadaptées pour SPIP 3 (mais devraient aussi fonctionner).

Nous avions besoin d'un listing d'auteurs où il serait facile de choisir des mots d'un groupe de mots donné (le numéro 40) avec un crayon. Dans notre cas le nombre de mots du groupe est limité (environ 10 mots) ce qui permet une interface assez simple : on liste tous les mots du groupe dans un sélecteur multiple.

Nous avons une liste d'auteurs (les lignes), et la colonne montrée indique les mots clés attachés (des métiers) aux auteurs. C'est eux que l'on veut éditer avec un crayon.

Commençons par montrer le code permettant d'amener l'icone de crayon sur la liste :

#EDIT{ctags}">
	(MOTS){id_auteur}{id_groupe=40}{', '}>[(#TITRE|supprimer_numero)]
	---

Télécharger

Nous sommes à l'intérieur d'une boucle auteur (non présentée ici) et notre colonne est affichée grâce à une boucle sur les mots de même auteur, du groupe 40. Sur la balise td du tableau, nous appelons le crayons nommé ctags avec #EDIT{ctags}, comme n'importe quel crayon habituel, sauf qu'ici, la colonne « ctags » n'existe pas dans notre table auteurs.

Il va falloir indiquer à crayons :

comment obtenir les données du formulaire à afficher, via une fonction PHP
quel formulaire afficher, via un contrôleur et une saisie
comment enregistrer les données saisies, via une fonction PHP
comment réafficher le résultat, via une vue

Le plugin crayons sait gérer des formulaires traitant plusieurs types de champs d'un coup ; par exemple le crayon « introduction » affiche 3 champs : description, chapeau et texte (de mémoire) et gère leur enregistrement. Il utilise pour ça 1 contrôleur, qui obtient les données des 3 champs et affiche les 3 champs de formulaire.

Nous, nous avons besoin d'1 contrôleur, pour obtenir 1 champ de formulaire, mais les données du champ sont obtenues et enregistrées en plusieurs endroits ensuite. Le fait d'avoir 1 seul champ nous dispense de devoir créer un contrôleur PHP en plus du HTML, qui serait indispensable pour déclarer les champs utilisés dans le contrôleur sinon. Ici, Crayons comprend que le champ souhaité porte le même nom que le contrôleur.

Commençons par le plus simple.

Le contrôleur et sa saisie

Il affiche le formulaire et porte le nom indiqué dans la balise #EDIT, soit ici controleurs/ctags.html. Il contient :

#CACHE{0}
 
#SET{mots,#ARRAY}
(MOTS){id_groupe=40}{id_auteur}>
#SET_PUSH{mots,#ID_MOT}
 
[(#SAISIE{ctags, content_#ENV{key}_ctags, id_groupe=40, class=crayons-active, valeur=#GET{mots},
	label=<:utilisateurs:label_categorie:>})]

Télécharger

La première partie s'amuse à retrouver les mots déjà associés à l'auteur et les stocke dans une variable « mots » qui est passée, ensuite comme valeur de la saisie « ctags ». Cette saisie va lister les mots du groupe 40 et sélectionner ceux qui sont déjà associés à l'auteur.

Il est important de noter que la saisie crée un attribut name de nom : content_X_ctags où X est un identifiant attribué par crayons.

La saisie saisies/ctags.html est simple (enfin c'est relatif, mais c'est juste un copié collé adapté d'une autre saisie) :

[(#REM) defaut peut être une chaine (plusieurs valeurs ou pas) qu'on sait décomposer ]
#SET{defaut, #ENV{defaut}|saisies_chaine2tableau}
 
[(#REM) valeur peut être une chaine (plusieurs valeurs ou pas) qu'on sait décomposer ]
#SET{valeur, #ENV{valeur}|saisies_valeur2tableau}

Télécharger

En gros, c'est une saisie affichant une sélection multiple, bouclant sur les mots du groupe de mot demandé.

Ajoutons un rien de CSS pour enlever le label de notre saisie (sinon le crayons est 2 fois plus large) :

.crayon-html .saisie_ctags label {display:none;}
.crayon-html .saisie_ctags {padding-left:10px;}

Télécharger

Déjà, nous arrivons maintenant à un formulaire lorsqu'on édite ressemblant à cela :

Faisons la vue.

La vue

La vue d'un crayon, c'est ce qui s'affiche après avoir modifié un élément. Il y a des vues par défaut, mais on peut les personnaliser. Nous, nous souhaitons le même affichage que dans notre tableau à l'origine. Il nous suffit de recoller le même code dans vues/ctags.html :

#CACHE{0}
(MOTS){id_auteur}{id_groupe=40}{', '}>[(#TITRE|supprimer_numero)]
---

Télécharger

Simple et efficace :)

Voyons maintenant comment faire pour que crayons enregistre les données !

Préparation et enregistrement des données

Crayons, pour savoir si une donnée a été modifiée par la personne qui valide le formulaire fait envoyer par le formulaire une signature des données qu'il avait calculé au moment de l'affichage dudit formulaire. Chaque champ possède 2 signatures : une signature identifiant le champ (le key de tout à l'heure), une autre identifiant le contenu des données (un md5 de celles-ci).

Comme SPIP dans l'espace privé, Crayons n'acceptera de modifier une donnée que si sa signature envoyée par le formulaire est la même que celle actuellement en base. Le cas contraire indique que quelqu'un d'autre a modifié les données entre temps. Si les signatures correspondent, il regarde si les données envoyées sont différentes également (sinon pas la peine d'enregistrer la même chose). Si tel est le cas l'enregistrement se fait, pour uniquement les données modifiées.

Le corollaire est que Crayons doit connaître les données en créant le formulaire ! Comme notre champ n'est pas standard, il va falloir lui indiquer comment l'obtenir.

C'est ce que fait la fonction suivante (à placer, par exemple dans un fichier d'option - il y a certainement mieux, mais je n'ai pas regardé plus en détail encore) :

// obtenir la liste des identifiants de mots clés liés à notre objet...
function valeur_champ_ctags($table, $id, $champ) {
	$valeurs = sql_allfetsel("m.id_mot", "spip_mots AS m, spip_mots_${table}s AS ma",
 array("m.id_groupe=40", "m.id_mot = ma.id_mot", "ma.id_${table}=".sql_quote($id)));
	$valeurs = array_map('array_shift', $valeurs);
	return $valeurs;
}

Télécharger

La fonction valeur_champ_X où X est le nom du champ souhaité (c'est aussi personnalisable en fonction du nom de la table) reçoit 3 arguments : le type de table (ici auteur), son identifiant (le numéro d'auteur), et le nom du champ désiré (le X, soit « ctags » ici).

La fonction doit retourner la valeur du champ. Ici, on retourne un tableau de tous les identifiants de mots clés associé à l'objet et son identifiant. Une fonction d'API spécifique en SPIP 3 pourrait obtenir ces données (cf API éditer liens), mais j'étais en SPIP 2.1.

Ceci fait, il faut maintenant indiquer le traitement à réaliser pour notre contrôleur, puisque ce n'est pas un traitement automatique. Cela se passe avec la fonction X_revision où X est le nom du contrôleur.

// la révision du crayon ctags doit supprimer ou ajouter des liaisons de mots clés
function ctags_revision($id_objet, $colonnes, $type_objet){
 
	// actuellement en bdd
	$old = valeur_champ_ctags($type_objet, $id_objet, 'ctags');
	// ceux qu'on veut maintenant
	$new = explode(',', $colonnes['ctags']);
	// les mots à supprimer
	$del = array_diff($old, $new);
	// les mots à ajouter
	$add = array_diff($new, $old);
 
	// actions !
	if ($del) {
 sql_delete("spip_mots_${type_objet}s",
 array(sql_in("id_mot", $del), "id_$type_objet=$id_objet"));
	}
	if ($add) {
 $adds = array();
 foreach ($add as $a) {
 $adds[] = array(
 "id_$type_objet" => $id_objet,
 "id_mot" => $a,
 );
 }
 sql_insertq_multi("spip_mots_${type_objet}s", $adds);
	}
 
	return true;
}

Télécharger

Ici la fonction reçoit 3 arguments : l'identifiant de l'objet, les couples de données à enregistrer, le type d'objet. Ici, SPIP 3 simplifierait aussi le code avec son API d'édition de liens.

Le principe est simple : on récupère ce qu'on veut enregistrer dans la clé 'ctags' de la variable $colonne. Elle contient la liste des identifiants de mots pour notre auteur. On fait ensuite la différence entre ce qui est déjà stocké et les nouvelles données pour savoir ce qu'on doit enlever et ajouter en BDD.

Voilà :)

Bon, tout n'est pas très propre, mais c'est une belle base !

Espéranto, genre et sexisme

Matthieu Marcillaud — 2012-08-29T14:15:39Z

Un des points les plus génants actuellement j'ai l'impression pour l'esperanto (enfin c'est moins pire que le français) est sa non distinction pour certains mots entre le neutre (enfin d'un sexe indéterminé) et le masculin, alors que passer un mot au féminin se fait par l'usage d'un suffixe. Du coup, beaucoup de personnes s'interrogent sur comment rendre cette langue non-sexiste. Il y a beaucoup de propositions, mais pas encore de choix établi.

Le français (la langue) est dit discriminant, par exemple lorsqu'il accorde un adjectif au masculin pluriel dès qu'il y a un élément masculin dans un groupe comme « L'homme et les 99 femmes sont beaux ». Une proposition de réforme du français est d'accorder avec le nom le plus proche. C'est la règle de proximité (et c'était comme ça il y a quelques siècles en ancien français). Ce qui donnerait « L'homme et les 99 femmes sont belles » ou « Les 99 femmes et l'homme sont beaux » selon le nom le plus proche de l'adjectif.

En espéranto les noms en eux-mêmes sont non-genrés (ni masculin, ni féminin) et il n'y a pas d'accord à faire de ce type. « La table blanche et le piano blanc » peut se traduire par « La tablo blanka kaj la piano blanka ». Par contre ils peuvent se référer à quelqu'un (ou un animal) qui est lui sexué, mais ça ne change pas les accords. « Nigra katino ronronas » signifie « Une chatte noire ronronne »

En esperanto, il y a des problèmes qui ne portent pas sur l'accord de l'adjectif (qui ne marque que le pluriel et non le féminin), mais sur la question du sexe attribué à un nom ou un pronom désignant une personne.

Prenons un nom simple : « la knabo », qui signifie le garçon. En ajoutant le sufixe -in- on obtient le féminin : « la knabino » signifie la fille. C'est là que ça devient embêtant : par le fait qu'il y ait un suffixe pour désigner le sexe féminin, on s'attend à l'existence d'un suffixe pour désigner le sexe masculin, mais il n'en est rien. On peut s'attendre aussi à l'existance d'un neutre, où le sexe est indéterminé (j'ai l'impression que ça se nomme épicène dans ce cas là).

De la même manière les pronoms personnels de la 3è personne sont :

li : il (masculin ou indéterminé)
ŝi : elle (féminin)
ĝi : il neutre pour un objet/animal tel que « la hundo... ĝi estas... » (Le chien... il est...)

On voit aussitôt que « li » est employé pour désigner ce qui est masculin ou indéterminé. Là encore ça pose le problème d'une sorte de prédominance du masculin. Dans « La kuracisto eniras. Li estas granda. » (Le médecin entra. Il est grand). On ne sait normalement pas le sexe du médecin. Pourtant, « li » indique, ou incite à penser que c'est un homme (c'est le même problème en français d'ailleurs).

Pour ces raisons de nombreuses propositions d'espérantistes visent à trouver des solutions à ces 2 problèmes. Aucune n'a encore été validée et c'est peut être ça le plus embêtant : chaque solution risque de vivre sa propre vie, mélangée aux autres simplement parce qu'une n'a pas été retenue et validée.

Voyons un peu les propositions faites.

Des explications complètes sont disponibles en anglais là

Pour le masculin et neutre des noms

Il faut savoir qu'il existe déjà un préfixe (vir-) pour désigner le « mâle » chez les animaux, par exemple « virbovo » pour taureau. Le préfixe vir- et le suffixe -in- comme la plupart en espéranto peuvent être utilisés seuls : viro = de sexe masculin, ino = de sexe féminin. On voit déjà encore un autre problème : parfois il y a vir- pour spécifier le masculin, dès fois pas (on ne dit pas « virpatro » ou « virkuracisto » pour dire le père ou le médecin homme). Et ce n'est pas symétrique, il y a un suffixe et un préfixe.

Il semble qu'il y ait un certain consensus pour proposer un suffixe en plus indiquant le sexe masculin, et à rendre non sexué les mots qui le sont par défaut tel que « patro » (père), « knabo » (garçon).

Les suffixes proposés sont -un-, -ol- et -iĉ-, et c'est ce dernier le plus utilisé actuellement à cette fin. De la sorte, avec cette modification introduisant -iĉ- comme suffixe de masculin, on obtiendrait :

patro : un parent (père ou mère)
patrino : mère
patriĉo : père

En fait, -iĉ- est employé parce qu'il se rapproche du suffixe déjà existant exprimant une relation tendre -ĉj- (comme il y a -nj- pour le féminin) :

patrino : mère. panjo : maman
patro : père. paĉjo : papa

Pour les pronoms

Le cas des pronoms semble poser beaucoup plus de difficultés. Certains veulent complêtement enlever le genre, par exemple en indiquant que « li » peut signifier soit masculin, soit féminin et en supprimant ŝi. D'autres préfèrent ajouter un autre pronom soit pour désigner le sexe indéfini (li devenant alors masculin), soit pour désigner le masculin (li devenant alors de sexe indéfini).

Il n'est pas facile de faire le tri de toutes les propositions. Je retiens que « ri » ne va pas en tant que pronom à cause de la confusion avec tous les verbes commençant par « ri » tel que « rigardi »

Après, j'aime bien la proposition de dire que « ĝi » désigne, en plus du neutre et d'un animal, quelqu'un de sexe indéterminé. « ŝli », contraction de « ŝi aŭ li » (elle ou il) est aussi intéressant mais plus difficile à prononcer (chli). Il y a aussi « gi » qui ferait tout autant l'affaire. Pas simple.

En résumé

Disons que lorsque je saurais l'écrire et le parler correctement, j'utiliserais vraissemblablement les formes suivantes :

-iĉ- pour les noms désignant des individus masculins. « patro » devenant un parent dont on ne précise pas le sexe, soit parce qu'on ne le connait pas, n'est pas important, ne veut pas le dire ou parce qu'il est déjà connu dans la phrase,
gi comme pronom indiquant une personne dont, de la même manière, on ne connait pas le sexe (ou ce n'est pas important, ou on veut pas le dire...)

Ça donnerait. Avant :

La patrino salutas min. Ŝi ridetas.
La patro iras hejmen. Li piediras.
Iu krias mian nomon. Li estas forega.

Après :

La patrino salutas min. Ŝi ridetas.
La patriĉo iras hejmen. Li piediras.
Iu krias mian nomon. Gi estas forega.

Ce qui peut se traduire par :

La mère me salue. Elle sourit.
Le père se dirige chez lui. Il est à pied.
Quelqu'un crie mon nom. Il est très loin.

Peut être que d'ici là une petite réforme de l'esperanto aura eu lieu :)

Ressources pour l'apprentissage de l'espéranto

Matthieu Marcillaud — 2012-08-29T14:13:20Z

Parce que même s'il est plus facile que d'autres langues, l'espéranto nécessite un apprentissage ! Et c'est relativement intéressant d'avoir quelques cours sous la main !

Commençons déjà par présenter une boutique où il est possible d'acheter de nombreuses revues, manuels, livres d'espéranto, par correspondance ou directement à Paris : chez Esperanto-france.

En général, découvrir l'espéranto passe par le site Lernu. Dedans il y a de quoi apprendre tout de l'espéranto ainsi que des exercices à faire. L'interface n'est pas toujours des plus agréables à regarder mais le site est très pratique, notamment avec le formulaire de recherche dans le dictionnaire présent dans la colonne qui permet à tout moment de nous remémorer les mots oubliés.

Il y a une très bonne émission de radio à Toulouse qui donne des cours d'Espéranto. J'avais toutes leurs archives, mais ils ont (malheureusement pour nous) refait leur site et seules les nouvelles archives depuis la refonte sont disponibles là

Le site Tatoeba permet de trouver des phrases traduites dans différentes langues. La diversité des phrases permet de découvrir pas mal de vocabulaire.

Il est possible d'écouter de la musique chez Muzaiko et plus généralement des documents sonores en espéranto sur Esperanto Radio et de la même manière des vidéos en esperanto sur Esperanto TV

Certains cours se retrouvent en vidéo, par exemple avec cette pièce de théâtre expliquée « La Passporto al la tuta mondo » (16 parties je crois, 4 * 2h).

On trouve également quelques jolis contes sous forme de courts métrages d'animation, traduits et sous-titrés sur le site Bookbox destiné à l'apprentissage des langues. Il faut choisir « esperanto » dans le sélecteur.

Le site Facila vento propose des textes simples pour débuter l'esperanto, que l'on peut également écouter.

Enfin difficile de passer au travers des outils de Google : la recherche en espéranto, et les traductions

Voilà déjà de quoi occuper la découverte de l'espéranto !

Réflexions sur l'espéranto

Matthieu Marcillaud — 2012-08-29T14:10:13Z

Cela fait quelques années déjà que je m'intéresse de près ou de loin à l'espéranto. Force est de constater que je n'ai pas encore poussé mon étude assez loin pour savoir suffisamment le parler. Cependant, aussi étrange que cela puisse me paraître, je comprends déjà mieux des textes d'espéranto que d'anglais. Je croise pourtant l'anglais presque tous les jours de part mon activité et je l'ai normalement appris à l'école. De ce regard là, il y a comme un mystère qui émane de l'espéranto et de sa facilité. Qu'est-ce qui me motive dans l'espéranto ? est-ce viable de l'apprendre ? peut elle réellement devenir une langue pont, une langue de travail, auxiliaire, de compréhension entre les cultures sur une plus grande population ? sa facilité peut elle survivre aux évolutions de toutes langues vivantes ? Je vais plus ou moins faire mon bilan de ces différentes questions que me parcourent l'échine ces jours-ci.

Motivations

J'ai précisément des difficultés à observer clairement quelles sont mes motivations envers l'espéranto. Plus clairement, je suis certain que son développement pourrait faciliter beaucoup l'échange de connaissances entre personnes de langues différentes, avec un minimum d'effort d'apprentissage des différentes parties. En tout cas un apprentissage bien plus rapide que l'anglais (150 heures d'espéranto apportent l'équivalent de 2000 heures de cours d'anglais) pour une efficacité bien meilleure : la prononciation, compréhension phonétique, régularité de l'espéranto apportent des bases solides, fiables sur la connaissance de la langue là où avec l'anglais, même avec beaucoup de pratique, il restera toujours difficile d'écrire une phrase correcte, de prononcer des mots correctement et inversement de comprendre le bon mot lorsqu'il est prononcé, tellement les subtilités phonétiques de cette langue sont grandes.

Le souci est que, actuellement, ce n'est pas encore l'espéranto qui est utilisé pour travailler entre les personnes d'horizons différents. S'ils n'ont pas une langue commune, c'est l'anglais qui est pris. C'est particulièrement vrai dans une des activités pour lesquelles je suis impliqué : le développement d'un logiciel (SPIP). Dans ce cadre là, notre logiciel - enfin son code source - est développé, écrit, exprimé en français (son interface d'utilisation et son usage est traduit, mais pas le code source ou ses gabarits). Nombreuses sont les remarques nous disant à peu près, le plus naturellement du monde : « Il y aurait bien plus de monde sur votre projet si vous passiez à l'anglais ». C'est peut être vrai, mais dans ce cas, pourquoi juste l'anglais, ou pourquoi l'anglais uniquement ?

L'anglais est devenu tellement la routine que de nombreux projets ne se donnent même plus la peine de se faire traduire. Ils restent en anglais, peut être supposant que tout le monde comprend ou doit comprendre cette langue. C'est le cas de la plate-forme de travail collaboratif « GitHub » permettant à des développeurs de logiciels de travailler ensemble.

Cette présence extrêmement grande de l'anglais comme langue de travail en informatique fait que j'arrive maintenant à comprendre à peu près le sens d'écrits techniques dans cette langue, au prix de beaucoup de fatigue psychique. Mais mon problème reste entier dès que je veux m'exprimer dans cette langue. J'ai l'impression systématique que je vais faire des erreurs et que je ne vais pas être compris. C'est d'autant plus frustrant que je n'ai rien contre le fait de savoir l'anglais et que j'aimerais bien pouvoir m'exprimer facilement dans cette langue, mais le constat est là : c'est difficile.

Je me suis souvent dit que je devais être un incompétent en langues étrangères, surtout en anglais, mais je me dis maintenant que ça ne vient peut être pas que de moi ! Particulièrement le visionnage des 10 présentations « Les langues : un défi » de Claude Piron apporte un éclairage différent. Malgré pour certains des études poussées en anglais, des erreurs d'interprétations, de mauvaises compréhension des mots sont présentes. En clair, ça dit que l'anglais est mal adapté comme langue de travail internationale.

Et donc l'espéranto est une solution très plaisante, à partir du moment où suffisamment de personne s'y mettent ! C'est bien là un problème. Certes il y a des locuteurs, assez nombreux en espéranto, mais on les trouve lorsqu'on veut voyager ou apprendre l'espéranto. Rarement dans la vie de tous les jours dans le cadre d'une de ses activités ou en se promenant sur internet. Et c'est là une baisse de motivation.

Lorsque j'ai appris à frapper au clavier avec la disposition de clavier bépo, à rouler en vélo couché ou fait des buttes de culture, la satisfaction de ces alternatives est immédiate : un grand confort d'utilisation et des améliorations aussitôt visibles, pratiques.

C'est un peu différent pour l'espéranto car c'est un changement qui implique d'autres personnes : il ne peut devenir utile quotidiennement que si suffisamment de gens s'y mettent afin que l'anglais ne soit plus considérée comme la langue naturelle de travail international, et que les ressources soient traduites !

Espéranto, le choix dans les langues construites

La question peut aussi se poser du choix de l'espéranto en lui-même alors qu'il existe de nombreuses autres langues régulières et langues construites, souvent plus compliquées, mais parfois extrêmement plus simple comme le récent Toki pona.

Il n'est pas évident de répondre à une telle question. On peut dire que l'espéranto a fait ses preuves car il est réellement une langue vivante auxiliaire pour une frange de la population mondiale et ce depuis plus d'un siècle.

On peut dire que le choix de l'espéranto plutôt qu'une langue appartenant à un peuple comme langue de travail internationale permet une égalité linguistique : chaque peuple est obligé de l'apprendre et n'a pas, dès lors, l'avantage de sa langue natale.

Mais qu'adviendrait-il, si l'espéranto était choisie comme langue auxiliaire internationale, et que plus tard, suite par exemple à une guerre entre 2 états, ces peuples choisissent l'espéranto comme langue nationale. Cet argument de la non-langue natale n'aurait plus de sens, et l'espéranto ne serait plus alors une langue « auxiliaire » pour eux. C'est embêtant car ce n'est pas le but que s'est fixé l'espéranto : servir de langue pivot, auxiliaire, de travail, mais absolument pas remplacer des langues natales.

Disons peut-être deux choses en sa faveur :

pour le moment c'est communément la langue auxiliaire la plus acceptée et parlée
apprendre l'espéranto facilite l'apprentissage d'autres langues ensuite. En fait c'est le cas de tout apprentissage de langue étrangère mais, comme le dit wikipedia :

Lorsque l'on a déjà appris une langue étrangère, l'apprentissage d'une nouvelle langue étrangère est plus facile, d'où l'intérêt de commencer par une langue étrangère facile.

Disons aussi que beaucoup de langues construites sont des tentatives de différents linguistes (le plus souvent) de créer ou tendre vers une langue « parfaite ». Là encore ce n'était pas l'objectif de l'Esperanto qui dit dans son fundamunto vouloir « rester intangible avec ses imperfections ». Cela dit, toute langue évolue.

L'esperanto comme langue vivante

De nombreux linguiste le soulignent : toute langue vivante évolue avec le temps, souvent régionalement. Est-ce que ce serait pareil pour l'espéranto ? C'est encore une question fort intéressante.

On peut certainement séparer en 2 les évolutions : d'une part le vocabulaire, et d'autre part la construction de la langue. Le risque avec le vocabulaire est l'entrée de mots issus du pays où le groupe espérantiste se trouve. Par exemple l'introduction de mots français chez les espérantistes parlant français. Si chacun fait cela à sa sauce il risque rapidement d'y avoir soit cacophonie, soit de nouveau hégémonie d'une culture sur une autre. Toujours est-il qu'au bout d'un siècle d'espéranto je n'ai pas l'impression que de nouveaux mots l'ont entaché, d'autant plus que sa nature même de langue agglutinante permet bien plus de constructions, comme des briques, que notre français ou anglais.

L'autre partie est sur la construction même de la langue. Une langue évolue avec la société et si elle reste figée il risque d'y avoir un décalage entre les envies de la société et les possibilités de la langue. C'est peut être le point le plus difficile à gérer. Effectivement les motivations politiques ne sont pas forcément les mêmes d'une région à une autre et là où certains veulent du changement, il n'est pas certain que d'autres le veuillent aussi. Il y a déjà une évolution sociétale forte qui pointe son nez depuis quelques temps en espéranto : l'envie d'avoir une langue « non-sexiste » (j'y reviendrais dans un prochain article). Chacun y va de sa solution et si une des propositions n'est pas acceptée par la fédération d'espéranto, elle risque néanmoins d'être utilisée, de fait par les locuteurs !

Mais même si ces changements auront lieu, ils n'entameront pas la volonté initiale de l'espéranto qui est d'être une langue facile, accessible au plus grand nombre, permettant de dialoguer entre différentes autres langues. Puis même si la langue évolue, on aura au moins fait mieux, l'espace de quelques années, que toutes les tentatives précédentes suggérant une langue internationale compliquée.

La présence de l'esperanto

L'espéranto a connu un regain d'intérêt avec internet. Aussi on ne peut pas nier que cette langue existe et est utilisée ! Il y a de nombreuses associations de promotion de l'espéranto de part le monde et on peut au moins citer ici 2 beaux projets où l'espéranto est loin d'être anecdotique :

Wikipedia, où il est la 27è langue d'après leurs statistiques avec 168 912 articles,
Tatoeba, où il est la 2è langue d'après leurs statistiques avec 177 367 phrases.

Le prochain article présente des sites de ressources pour apprendre l'espéranto.

SPIP 3, Documents, Mots

Matthieu Marcillaud — 2012-06-12T10:10:51Z

SPIP 3 permet d'attacher des mots à des documents, et il permet également de taguer des documents avec des mots clés. Fort pratique certainement, ce qui devient plus délicat, c'est ensuite les boucles à réaliser pour retrouver tout cela. Au vu des nombreuses questions sur les listes d'utilisateurs, voici un petit peu d'explication du fonctionnement.

Un énième message d'un utilisateur de SPIP et concepteur de squelette ne comprenait pas pourquoi sa boucle documents ne retournait rien.

(DOCUMENTS){id_mot}>...

En fait il s'attendait à ce que la boucle retourne la liste des documents qui ont un mot clé donné (les mots clés taguent des documents donc). C'est une compréhension fort logique, vu que c'est ce que fait la boucle :

(ARTICLES){id_mot}>

Les tables de liaisons

Mais ce n'est pourtant pas ce qui se passe avec la boucle documents. La différence est simple, il existe une table SQL « spip_documents_liens » qui sert de pivot (on parle souvent de table de liaison) où est stockée donc l'information disant tel document est lié à ceci, cela, c'est à dire à des objets éditoriaux (articles, rubriques, mots, tout ce que l'on veut).

Il existe la même table « spip_mots_liens » qui sert de pivot pour indiquer que tel mot est attaché à tel objet éditorial, lorsqu'on tague des articles, des documents d'un mot clé.

Mais il n'existe pas de table « spip_articles_liens ».

Cas non ambigus

Lorsqu'on écrit dans une boucle ARTICLES le critère {id_mot}, SPIP recherche comment il peut faire pour honorer la demande. Il cherche donc si la table SQL spip_articles possède un champ « id_mot » (ce qui n'est pas le cas), et du coup tente de trouver une construction de liaison entre tables SQL (on parle de jointure) qui permet d'obtenir ce id_mot qui est demandé. SPIP remarque que spip_mots_liens possède un champ « id_mot » et va donc demander une jointure avec cette table.
Il pourrait aussi rechercher une table ayant le couple de champs « objet » et « id_objet » et faire une jointure dessus en indiquant, du coup, que objet=mot et id_objet=l'identifiant.

Pour aller plus loin, disons simplement que s'il y a plusieurs possibilités de jointure pour obtenir id_mot, SPIP choisira la jointure la plus courte, c'est à dire qui nécessite d'interroger le moins de tables SQL possibles.

Cas ambigus

Indiquer un critère {id_mot} sur une boucle DOCUMENTS est plus ambigu. Effectivement, SPIP peut choisir de prendre le mot soit sur la liaison spip_documents_liens, soit sur la liaison spip_mots_liens. Les deux étant corrects, mais ils n'ont pas la même signification.

Il faut donc savoir que dans ce cas, SPIP choisit de préférence une liaison avec la même table que celle de la boucle, c'est à dire que comme nous sommes dans une boucle DOCUMENTS, SPIP choisira de préférence la liaison avec spip_documents_liens.

Alors, pourquoi y a t'il deux tables de liaisons possibles avec les documents ou avec les mots ? et à quoi servent-elles ? qu'est-ce qui les différencient ?

Des mots sur des documents, des documents sur des mots

Pour expliquer ce qui se passe :

Les documents en SPIP 3 peuvent être sur n'importe quel objet (y compris les mots) (des mots peuvent avoir des documents attachés)
Les mots en SPIP 3 peuvent être mis sur n'importe quel objet (y compris les documents) (des documents peuvent être tagués par dés mots)

On voit bien ici que c'est délicat pour SPIP de comprendre ce que signifie (DOCUMENTS){id_mot} : est-ce qu'on veut ?

les documents d'un mot clé ?
les documents tagués d'un mot clé ?

Il faut donc faire un peu d'analyse de fonctionnement de SPIP pour comprendre ce qui va se passer :

Lorsqu'on lie un document à un objet, la liaison est stockée dans la table spip_documents_liens
Lorsqu'on lie un mot à un objet, la liaison est stockée dans la table spip_mots_liens

Ce que SPIP va décider lorsqu'il y a ambiguïté, c'est à dire comme ici (DOCUMENTS){id_mot} alors qu'il existe les 2 tables spip_documents_liens et spip_mots_liens, c'est qu'il va préférer interpréter cela comme une liaison sur la table de lien de la boucle en cours, c'est à dire sur spip_documents_liens, ce qui signifie donc que ça va retourner « les documents attachés à un mot clé »

Pour lever les ambiguïtés, on peut indiquer, donc, la relation du lien de plusieurs manières, lorsqu'on veut l'autre relation :

Soit en l'indiquant comme table : (DOCUMENTS mots_liens){id_mot}
Soit en l'indiquant dans le critère (DOCUMENTS){mots_liens.id_mot}

Il faut noter que mettre simplement (DOCUMENTS){mots.id_mot} n'est pas suffisant pour lever l'ambiguïté.

D'autres exemples :
Liaison spip_documents_liens (Les documents attachés à un mot)

(DOCUMENTS){id_mot}>#ID_DOCUMENT

Liaison spip_mots_liens (Les documents tagués d'un mot)

(DOCUMENTS mots_liens){id_mot}>#ID_DOCUMENT
(DOCUMENTS mots_liens){mots.id_mot}>#ID_DOCUMENT
(DOCUMENTS){mots_liens.id_mot}>#ID_DOCUMENT

Télécharger

Attraper les documents tagués avec un mot clé appartenant à un certain groupe :

(DOCUMENTS mots_liens) {mots.id_groupe=1}>
#ID_DOCUMENT
 
(DOCUMENTS mots_liens) {mots.type=Nom}>
#ID_DOCUMENT

Télécharger

Intégrer une table existante dans SPIP 3 avec la fabrique (suite)

Matthieu Marcillaud — 2012-04-20T17:47:26Z

Nous l'avons vu dans Intégrer une table existante dans SPIP 3 avec la Fabrique, « La Fabrique » permet de créer des bases fonctionnelles de plugins gérant des objets éditoriaux. Nous allons continuer avec une autre problématique avec l'utilisation d'un autre objet, une table contenant des lieux.

Le principe va être le même et donc je ne vais pas détailler les mêmes choses. Cette table est volumineuse, et a des colonnes que nous allons également migrer dans des liaisons.

Voici ce que nous avons à migrer entre autres choses, qui diffèrent par rapport au premier article sur le sujet :

1 champ « pertinence » qui ira en champs extras 'pertinence' dans spip_gis
1 champ « pays » qui contient un nom de pays, et sera migré vers un identifiant de pays

Et ce qu'il faudra faire en plus de la migration :

créer / gérer le champs extra sur spip_gis,
des saisies spécifiques dans cette table comme la sélection d'une ville dans la table spip_villes du même plugin. Ce n'est pas un lien dans ce qu'on me demande, ça aide simplement à retrouver certaines données comme l'insee de la ville, aussi stocké dans cette table de lieu.

Déclarer l'objet dans la Fabrique

On l'a déjà vu, donc nous cliquons :

« Ajouter un objet éditorial »
Pré-construire le contenu du formulaire avec la table que l'on désire
Modifier certaines infos (ici la construction de sait pas que le singulier est « lieu », il faut donc le renseigner : dans la description, ET dans la partie « tables » / « spécificités des tables hors normes » on l'on indique le nom de clé primaire « id_lieu » et le type « lieu ». [1]
Pour chaque champs de la table, remplir plus précisément les infos (noms explicites, saisies souhaité pour l'édition, pondération de recherche) et éventuellement vérifier que les déclarations SQL n'ont pas de NULL autorisés sans valeur par défaut
On active dans « fichiers échafaudés » prive/squelettes/contenu/lieux.html, qui offre simplement en plus un petit formulaire de recherche, qui sera pratique sur notre table volumineuse

Créer le champ pertinence dans GIS

Il faut :

déclarer le champs extra (dans paquet.xml et dans base/prefixe.php)
ajouter les codes d'installation / désinstallation de ce champ
l'ajouter sa valeur en même temps que la migration

Dans la Fabrique, on ajoute la ligne du pipeline dans paquet > codes à insérer > paquet.xml ainsi que la dépendence au plugin Champs Extras. [2] [3]

 nom="cextras" compatibilite="[3.0.0;]" />
 nom="declarer_champs_extras" inclure="base/geoniche.php" />

Télécharger

On ajoute la fonction de déclaration du champs dans paquet > codes à insérer > bases > prefixe.php :

function geoniche_declarer_champs_extras($champs = array()) {
	$champs['spip_gis']['pertinence'] = array(
 'saisie' => 'input', // Type du champs (voir plugin Saisies)
 'options' => array(
 'nom' => 'pertinence', 
 'label' => _T('geoniche:pertinence'), 
 'sql' => "int(2) NOT NULL DEFAULT 0",
 'defaut' => '', // Valeur par défaut
 ),
	);
	return $champs;
}

Télécharger

Ainsi que les procédures d'installation / désinstallation dans administrations.php que l'on peut ajouter avant l'importation des données.

installation :

include_spip('inc/cextras');
include_spip('base/geoniche');
cextras_api_upgrade(geoniche_declarer_champs_extras(), $maj['create']);

Télécharger

déinstallation :

include_spip('inc/cextras');
include_spip('base/geoniche');
cextras_api_vider_tables(geoniche_declarer_champs_extras(), $maj['create']);

Télécharger

Il restera, à posteriori à ajouter la chaîne de langue geoniche:pertinence.

Ajouter une saisie pour le champ INSEE

Dans la table lieux, il faut faire renseigner un champ INSEE de commune. On retrouvera une liste de ces valeurs à partir du code postal choisi.

La saisie (à placer dans saisies/insee.html) peut ressembler à cela :

Télécharger

Aussi, on ajoutera un petit javascript qui rechargera la liste des INSEE possibles dès que la valeur du code postal change, dans le squelette du formulaire d'édition :

<script type="text/javascript">
(function($){
	$('.formulaire_#FORM .editer_zip input').change(function(){
 val = $(this).val();
 var select_insee = $('.formulaire_#FORM .editer_insee select');
 insee = select_insee.val();
 select_insee.val("");
 $.get('[(#URL_PAGE{ajax-insees})]', {zip: val, insee: insee}, function(data){
 select_insee.html(data);
 });
	});
})(jQuery);
script>

Télécharger

Ce squelette appelle une page « ajax-insees » qui peut contenir le strict minimum tel que :

#HTTP_HEADER{Content-Type: text/html; charset=#CHARSET}
(VILLES){par nom_ville_min}{zip}>

Télécharger

Conserver une partie des informations ajoutées au plugin après sa création

Avec la version 1.12.0 de la fabrique arrive un petit utilitaire pour simplifier certaines opérations à effectuer après la création du plugin lors de l'exécution du script post_creation. C'est une classe PHP nommée « Futilitaire » et incluse dans inc/futilitaire.php du plugin Fabrique.

Elle contient pour l'instant 2 fonctions utiles :

deplacer_fichiers($liste) qui indique de deplacer du backup (l'ancienne création) vers la nouvelle création la liste des fichiers indiques. C'est donc une liste des fichiers que l'on a ajouté au plugin qui est a donner.
inserer_lignes($chemin, $start, $len, $code) qui permet d'ajouter des lignes de code dans un des fichiers présents, à partir de la ligne indiquée dans $start (peut être négatif pour partir de la fin du fichier), en supprimant $len lignes du fichier, et en insérant le contenu de $code à cet emplacement.

Voici un exemple :
Dans l'interface de la fabrique, dans Paquet > Scripts à exécuter > post_creation, j'ai simplement l'inclusion d'un fichier et l'exécution d'une fonction :

include_once($destination_ancien_plugin . 'fabrique_geoniche_post_creation.php');
fabrique_geoniche_post_creation($data, $destination_plugin, $destination_ancien_plugin);

Télécharger

Dans le plugin généré, j'ajoute donc ce fichier à la racine fabrique_geoniche_post_creation.php (vous l'appelez comme bon vous semble) contenant :


 
include_spip('inc/futilitaire');
 
function fabrique_geoniche_post_creation($data, $destination_plugin, $destination_ancien_plugin) {
 
	// charger le Futilitaire
	$futil = new Futilitaire($data, $destination_plugin, $destination_ancien_plugin);
 
	// deplacer les fichiers crees, dont celui-ci
	$futil->deplacer_fichiers(array(
 'fabrique_geoniche_post_creation.php', 
 'base/importer_spip_villes.php', 
 'base/importer_spip_villes_donnees.gz',
 'base/importer_spip_lieux.php', 
 'base/importer_spip_lieux_donnees.gz',
 'saisies/thematique.html',
 'saisies-vues/thematique.html',
 'saisies/insee.html',
 'saisies-vues/insee.html',
 'saisies-vues/ape.html',
 'saisies/ape.html',
 'ajax-insees.html',
 'after.txt',
	));
 
	// ajouter du code dans lang/geoniche.php
$lignes =
<<
 
// P
'pertinence' => 'Pertinence',
EOF;
 
	$futil->ajouter_lignes('lang/geoniche_fr.php', -3, 0, fabrique_tabulations($lignes, 1));
 
 
	// ajouter du code dans formulaires/editer_lieux.html
$lignes =
<<
 
 
EOF;
 
	$futil->ajouter_lignes('formulaires/editer_lieu.html', -1, 0, $lignes);
}
 
?>

Télécharger

Du coup, à chaque fois que je génère mon plugin via la Fabrique, je ne perds pas les fichiers indiqués et il me remet ce code là où je lui dis.

À vrai dire, cela a peu d'utilité certainement pour vous, à part le fait de se dire qu'on peut regénérer le plugin sans perdre de modifications, pour peu qu'on ai listé ici toutes les modifications que l'on a fait. Pour ma part, cela m'aide à pouvoir ajouter de nouvelles fonctions dans la fabrique sans perdre de petites modifications de code déjà réalisées.

[1] Nota, la Fabrique 1.12.0 ou SPIP 3 ne savent pas gérer parfaitement une table dont le pluriel est identique au singulier tel que « un univers, des univers » (plus précisément où l'« objet » est identique au « type »), il faudra donc éviter ces noms là, sinon le plugin généré ne pourra pas lister tous les univers sur exec=univers (qui s'attend à afficher la vue d'un univers) et renverra un accès interdit. Il y a de multiples contournements possibles, mais j'ai préféré ne pas alourdir la Fabrique avec cela pour l'instant.

[2] Le plugin construit a été renommé en « Géoniche »

[3] On pourrait très bien ajouter ces codes après la création du plugin si on ne compte plus utiliser la Fabrique ensuite.

Intégrer une table existante dans SPIP 3 avec la Fabrique

Matthieu Marcillaud — 2012-04-20T17:28:22Z

Pour un site de mode fraîchement migré en SPIP 3 (toujours en développement à l'heure de ces lignes), et pour qu'il soit encore plus à la mode, on m'a demandé de pouvoir gérer des tables SQL déjà présentes en base, depuis l'interface privée de SPIP, et avec quelques contraintes. Ce document à un objectif de transfert de connaissances et se veut pédagogique. Il est fortement recommandé d'avoir lu Chats 2 - SPIP 3 avant de poursuivre.

Cet article va raconter la migration d'une table SQL nommée « villes » (qui n'a rien à voir avec le plugin « géographie »). Cette table devra pouvoir être parcourue depuis l'interface privée, mais seule une ou deux colonnes seront éditables (la table a 15 colonnes), et il ne sera pas possible de créer de nouvelles villes.

Nous créerons une première base du plugin grâce à un autre plugin « La Fabrique » que je développe actuellement. La Fabrique génère les fichiers d'un plugin et peut générer un plugin contenant des objets éditoriaux. Bien sûr, le code produit n'est qu'une base de travail (certes fonctionnel) que l'on édite ensuite à sa sauce.

Il nous faudra migrer les données présentes dans la table, pour créer une colonne de clé primaire id_ville, déplacer les coordonnées géographiques sur le plugin GIS 3, et charger à l'installation du plugin les données des villes.

Copie des tables pour une utilisation en serveur local

Tout d'abord, puisque je travaille uniquement sur un serveur local, j'ai ajouté les tables SQL en question dans une base de données crée sous PHPmyAdmin. Pour cela, j'avais à disposition un export des tables et données au format SQL. En ligne de commande (sous Ubuntu) je charge les données dans la base en me connectant à mysql :

cd repertoire/ou/est/l/export/sql
mysql -u nom_utilisateur -p
use nom_de_la_base
source nom_du_fichier.sql

Télécharger

Ensuite, dans un SPIP3 local, je vais déclarer ma nouvelle base sur la page « Maintenance technique » de sorte que je peux boucler sur ces nouvelles données

(nom_connecteur:VILLES){par insee}{pagination 10}>
...

Télécharger

Fabriquer la base du plugin

Nous allons générer un premier jet de plugin en utilisant la Fabrique. Dans un premier temps sans trop rien de plus. Une fois le plugin activé, il faut se rendre sur Squelettes > La Fabrique. Si un plugin avait été construit auparavant, il faut aller réinitialiser le formulaire dans l'onglet prévu.

On peut alors remplir les informations relatives au plugin. Cette première page (en ayant rempli la partie « paquet ») suffit à générer des fichiers du plugin (bouton « Créer le plugin ») mais nous allons continuer et ajouter un objet éditorial.

L'objet éditorial ajouté, l'interface propose d'utiliser une table existante pour en déduire la structure des données notre objet éditorial. Ici, j'utilise la table « villes » sur le connecteur « source ».

Au retour du pré-chargement, les infos de l'objet ont été déduites si cela était possible, et au mieux de l'information disponible. Il faudra donc apporter pour chaque partie quelques corrections ou informations supplémentaires.

En complétant quelques parties, on peut ajouter des logos, gérer les champs (en plus ou en moins), les déplacer, leur attribuer des types de saisies. On peut trouver des logos par exemple sur http://thenounproject.com, qui m'a servi dans cet exemple. Les chaînes de langues sont pré-remplies également (en français) et on peut lancer une première création du plugin.

Une fois créé, on peut se rendre sur la page d'administration des plugins pour l'activer et le tester.

Dans édition > villes on découvre la liste, vide, des villes. Et l'on peut alors créer une nouvelle ville. Évidemment, il faut avoir ajouté des saisies dans certains champs de notre objet dans la Fabrique, sinon le formulaire d'édition sera vide. Pour les tests, j'avais créé 2 champs en plus de ceux de la table d'origine : nom et description.

À la validation du formulaire, on obtient cependant un joli message d'erreur.

Cela signifie, dans notre cas qu'il y a eu une erreur SQL au moment de l'insertion. Un tour dans les logs nous indique l'erreur :

Apr 05 19:33:14 127.0.0.1 (pid 11008) :Pri:ERREUR: | 0 : 23000 | 1 : 19 | 2 : spip_villes.insee may not be NULL - INSERT INTO spip_villes (maj) VALUES (datetime('now'))

On comprend que la description SQL des champs de la table d'origine ne correspond pas tout à fait au fonctionnement de SPIP. En effet, SPIP crée d'abord une ligne vide dans un objet et obtient ainsi un identifiant de ligne (ici un id_ville) pour insérer ensuite les valeurs soumises par le formulaire d'édition. Or dans ce cas, des champs ne tolèrent pas d'être « NULL » mais n'ont pas de valeur par défaut de définis. Il nous faut donc, pour chaque champ dans ce cas, ajouter cette valeur par défaut, ce qui revient le plus souvent à ajouter « DEFAULT '' » dans l'expression SQL du champ

On retourne donc dans la fabrique pour le faire, on recrée le plugin, on désinstalle puis réinstalle notre plugin dans admin plugin, puis on reteste.
Cette fois l'insertion se passe bien.

Peupler notre plugin avec les données de la table d'origine

Tout ceci est bien joli, mais dans notre cas, ce qui nous intéresse est de peupler notre table de ville avec un contenu pré-défini, à l'installation du plugin. Le contenu se trouve actuellement dans la table source ayant servi de base de déclaration de notre objet. Une fois peuplé, il faut afficher les champs, mais ne mettre que la description éditable (le reste étant figé).

La Fabrique ne gère pas depuis le formulaire de création du plugin l'insertion de ces données, mais propose sur la page ?exec=fabrique_peuple un outil pour se faciliter cette tâche.

Cet outil crée un ou deux fichiers qui seront à placer dans le répertoire base/ du plugin que l'on a créé. Il faut également ajouter l'appel de la fonction d'insertion dans le fichier d'administration lors de la création de la table, avec :

$maj['create'] = array(array('maj_tables', array('spip_villes')));
include_spip('base/importer_spip_villes');
$maj['create'][] = array('importer_spip_villes');

Télécharger

Cette fonction d'import gère la reprise de l'insertion des données en cas de timeout (trop de temps utilisé par rapport à ce qui est autorisé dans la configuration de PHP). Très utile pour insérer ces 36000 lignes en SQLite notamment.

Du coup, nous pouvons voir sur la liste des villes que le compte est bon, mais que… nous n'avons pas correctement redéclaré le champ servant au calcul du titre. Je l'avais déclaré sur la colonne « nom » pour tester, colonne que j'avais créé, mais l'insertion insère les noms de nos villes dans une autre colonne. Il nous faut donc :

corriger soit directement notre plugin
soit en passant par la Fabrique, modifier les colonnes, recréer le plugin, remettre les fichiers d'imports, désinstaller et réinstaller notre plugin (réinstallation uniquement utile si une colonne a été ajoutée ou retirée, ce qui va être le cas car je vais supprimer la colonne « nom »).


Mettre le bon nom de colonne de titre

Les noms de ville s'affichent bien, mais il y a un problème de charset. Les données de la table d'origine ne semblent pas au bon format. Nous allons donc modifier notre script d'import pour corriger les caractères au passage et tester sur un panel d'insertion plus petit pour aller plus vite.

On choisit dans la fonction importer_spip_villes() du fichier du même nom de ne prendre que 100 villes, grâce à la fonction array_slice() :

	list($cles, $valeurs) = donnees_spip_villes();
	$valeurs = array_slice($valeurs, 0, 100);

Télécharger

Et l'on teste un utf8_encode() un peu plus loin :

- $i[ $correspondances[$cle] ] = $valeur;
+ $i[ $correspondances[$cle] ] = utf8_encode($valeur);

Télécharger

Une fois désinstallé et réinstallé le plugin, on obtient les bons accents (coup de bol !).

On peut donc enlever la limitation à 100 villes, et réinstaller le plugin complètement.

Perdre le moins de modifications possibles entre chaque recréation de notre plugin

Au fur et à mesure de ces travaux, je constate qu'il est effectivement embêtant de devoir remettre les modifications apportées au plugin après sa création, à chaque fois qu'on le recrée avec la Fabrique (comme les fichiers d'import de ville et l'ajout de notre fonction dans $maj).

Après 3 jours de réflexions, j'opte pour un compromis qui me satisfait pour le moment :

à chaque fois que l'on crée le plugin, une copie de l'ancien est sauvegardée et la Fabrique génère un « diff » entre les répertoires. Si des fichiers manquent dans le nouveau plugin, une alerte est levée et on affiche la liste de ces fichiers absents bien visibles après la création. Ainsi, si c'est un oubli de les remettre dans le nouveau plugin, on peut les récupérer dans la sauvegarde.
des points d'insertions sont ajoutés où l'on peut intégrer son propre code, rempli depuis l'interface de création du plugin. Évidemment, il faut que ce code soit valide, la Fabrique ne peut pas le vérifier !
des points d'exécution de scripts sont ajoutés où l'on peut faire exécuter du code (via eval()) que l'on rempli depuis l'interface également. Ce code ne sera exécuté uniquement si l'on est webmestre (sinon c'est potentiellement très dangereux). Ainsi, on peut, après la création du plugin, déplacer des fichiers qui étaient présents dans la sauvegarde.

Nous ajoutons donc, dans la partie insertions le code d'insertion des données de la ville, et dans la partie script, la recopie des fichiers allant avec :

Le code de recopie est donc assez simple :

foreach(array(
 'base/importer_spip_villes.php', 
 'base/importer_spip_villes_donnees.gz',
) as $f) {
 copy($destination_ancien_plugin . $f, $destination_plugin . $f);
}

Télécharger

Migrer à l'installation les données géographique des villes vers le plugin GIS

L'ancienne table de villes contient des données géographiques que l'on va migrer vers des points du plugin GIS. Chaque ville sera donc liée à 1 point géographique. Il va donc nous falloir modifier le script d'import qui avait été automatiquement créé, pour gérer notre spécificité.

Pour s'en sortir et tester, on remet déjà une liste courte de villes, et non les 37000. En prendre 10 suffira largement. On remet donc le array_slice sur le fichier d'import :

$valeurs = array_slice($valeurs, 0, 10);

Sur le principe, il faudra :

créer un point géographique pour chaque ville (table spip_gis) et récupérer d'identifiant
créer la ville et récupérer son identifiant (table spip_villes)
ajouter le lien entre les 2 (table spip_gis_liens)

Du coup, on ne peut plus utiliser la fonction d'insertions multiples (sql_instertq_multi), puisqu'il va falloir agir ligne par ligne.

Commençons pas ajouter le plugin GIS dans les dépendances du plugin.
Pour cela, on ajoute dans la Fabrique, paquet > insertions de code > paquet.xml la ligne :

 nom="gis" compatibilite="[3.2.0;]" />

Nous n'avons plus besoin des colonnes « lon » et « lng » de la table « spip_villes » que l'on supprime alors dans la Fabrique. On observe un peu les tables de GIS (dans base/gis.php du plugin GIS). On en déduit comment doit se réaliser notre migration. On fait un premier jet de code.

 // inserer les donnees en base.
 $nb_deja_la = sql_countsel($table);
 // ne pas reimporter ceux deja la (en cas de timeout)
 $inserts = array_slice($inserts, $nb_deja_la);
 foreach ($inserts as $i) {
 
 // point gis
 $id_gis = sql_insertq("spip_gis", array(
 'titre' => $i['nom_ville_min'],
 'lat' => $i['lat'],
 'lon' => $i['lng'],
 'ville' => $i['nom_ville_min'],
 'code_postal' => $i['zip'],
 ));
 
 // ville
 unset($i['lat'], $i['lng']);
 $id_ville = sql_insertq($table, $i);
 
 // liaison gis / ville
 sql_insertq("spip_gis_liens", array(
 'id_gis' => $id_gis,
 'objet' => 'ville',
 'id_objet' => $id_ville,
 ));
 
 if (time() >= _TIME_OUT) { return; }
 }

Télécharger

On installe désinstalle notre plugin, ainsi que GIS s'il était là, puis le réinstalle.
On va dans la configuration GIS dire qu'on a besoin de GIS sur les villes, mettre un générateur de carte et une position par défaut (on fera cela dans une fonction d'installation ensuite pour automatiser), et on se rend sur une ville pour voir.

On voit entre autres que… la ville française est placée quelque part en Afrique. Quelque chose cloche ! Il faut comparer nos données en base avec la table originale pour savoir si on a bien remis les mêmes valeurs.

Dans la table source, j'ai :

lng	lat
45.979851	5.33689

Dans la table de GIS, j'ai :

lon	lat
45.979851	5.33689

Manifestement, ce sont bien les mêmes données. Le problème est ailleurs.
Je vais donc créer un nouveau point dans GIS pour comparer. Au hasard, je prends Grenoble, qui ne semble pas très loin en coordonnées.

Et là je lis dans ma table

lon	lat
5.745458496026258	45.17920020811579

Soit l'inverse. Ce qui veut dire que les coordonnées sont inversées dans la table source ! Magnifique. Plutôt que d'adapter notre script, on inverse les colonnes dans la table source (via phpmyadmin ou sqlite manager selon), et on la réexporte depuis la Fabrique. On remplace simplement le fichier compressé de données ensuite et on inverse les colonnes dans le tableau $cles du fichier importer_spip_villes.php. On retourne désinstaller, réinstaller GIS et notre plugin, on reconfigure GIS, puis on va tester une ville. Aussitôt, c'est bien mieux placé.

Configurer GIS au démarrage de notre plugin

Puisque notre plugin ajoute des points sur les villes, autant activer les villes sur GIS dès l'installation de notre plugin. Pour cela, on génère un tableau de la configuration de GIS (une fois configuré), en écrivant dans un quelconque squelette (disons test.html que l'on appellera ensuite par ?page=test) :


include_spip('inc/config');
var_export(lire_config('gis'));
?>

Télécharger

Ce qui nous donne (ici) :

array (
 'lat' => '46.50764083069263',
 'lon' => '0.32931686417954',
 'zoom' => '6',
 'geocoder' => '',
 'adresse' => '',
 'geolocaliser_user_html5' => '',
 'api_key_cloudmade' => '',
 'api_key_google' => '',
 'api_key_yandex' => '',
 'gis_objets' => 
 array (
 0 => 'spip_villes',
 1 => '',
 ),
 'api' => 'openlayers',
 'maptype' => 'ROAD',
)

Télécharger

On ne garde que les infos que l'on veut proposer :

array (
 'lat' => '46.50764083069263',
 'lon' => '0.32931686417954',
 'zoom' => '6',
 'gis_objets' => 
 array( 'spip_villes'),
 'api' => 'openlayers',
)

Télécharger

On s'arrangera pour qu'à l'installation, si GIS est déjà configuré, que l'on n'écrase pas sa configuration, mais que l'on ajoute simplement la ville. On utilisera pour cela la fonction array merge de PHP.

Et on ajoute au code inséré par la Fabrique dans l'installation notre modification de la configuration de GIS, en créant une fonction (qui se retrouvera l'intérieur de la fonction de mise à jour, mais PHP tolère cela).

include_spip('base/importer_spip_villes');
$maj['create'][] = array('importer_spip_villes');
// configurer GIS sans toucher aux valeurs deja configurees si c'est le cas
function configurer_gis_ville() {
	$conf = lire_config('gis', array());
	$conf = array_merge(array(
 'lat' => '46.50764083069263',
 'lon' => '0.32931686417954',
 'zoom' => '6',
 'gis_objets' => array(),
 'api' => 'openlayers',
	), $conf);
	$conf['gis_objets'] = array_merge($conf['gis_objets'], array('spip_villes'));
	ecrire_config('gis', $conf);
}
$maj['create'][] = array('configurer_gis_ville');

Télécharger

Améliorer le chargement des points

On peut maintenant améliorer un peu notre fonction de peuplement en :

encapsulant dans une transaction l'ensemble des requêtes si le moteur le préfère. C'est en fait un hack pas terrible pour SQLite, qui permet de ne pas lui faire générer de verrous pour chaque requête, ce qui lui prend du temps. Du coup, il en génère un pour un groupe de requêtes cohérent.
en testant qu'un point GIS identique n'existe pas déjà avant d'en créer un nouveau
en utilisant une fonction interne de SPIP pour les liaisons entre gis et la ville.

Cela donne :

 include_spip('action/editer_liens');
 foreach ($inserts as $i) {
 
 // eviter des creation / suppression de verrous pour SQLite
 if (sql_preferer_transaction()) {
 sql_demarrer_transaction();
 }
 
 // un point existe deja ?
 if (!$id_gis = sql_getfetsel("id_gis", "spip_gis", array(
 'titre = ' . sql_quote($i['nom_ville_min']),
 'lat = ' . sql_quote($i['lat']),
 'lon = ' . sql_quote($i['lng'])
 ))) {
 // sinon on le cree...
 $id_gis = sql_insertq("spip_gis", array(
 'titre' => $i['nom_ville_min'],
 'lat' => $i['lat'],
 'lon' => $i['lng'],
 'ville' => $i['nom_ville_min'],
 'code_postal' => $i['zip'],
 ));
 }
 
 // ville
 unset($i['lat'], $i['lng']);
 $id_ville = sql_insertq($table, $i);
 
 // liaison gis / ville
 objet_associer(array('gis'=>$id_gis), array('ville'=>$id_ville));
 
 if (sql_preferer_transaction()) {
 sql_terminer_transaction();
 }
 
 if (time() >= _TIME_OUT) { return; }
 }

Télécharger

Supprimer les informations liées à GIS à la désinstallation de notre plugin

Comme on l'a fait pour l'installation, il faut également supprimer nos informations à la désinstallation :

la table « spip_villes » dans la config de GIS
les liaisons « spip_gis_liens » avec les villes
les points GIS qui étaient liés à une ville mais qui ne sont plus utilisés.

On insère notre code dans la partie prévue par la Fabrique (insérer > administrations > vider_table).

// enlever les villes de la configuration de GIS
$conf = lire_config('gis');
$conf['gis_objets'] = array_diff($conf['gis_objets'], array('spip_villes'));
ecrire_config('gis', $conf);
// recuperer tous les points lies a une ville
$ids_gis = sql_allfetsel('id_gis', 'spip_gis_liens', 'objet=' . sql_quote('ville'));
$ids_gis = array_map('array_shift', $ids_gis);
// supprimer les liaisons avec une ville
sql_delete('spip_gis_liens', 'objet=' . sql_quote('ville'));
// trouver les points encore utilises
if ($ids_gis_utilises = sql_allfetsel('id_gis', 'spip_gis_liens', sql_in('id_gis', $ids_gis))) {
	$ids_gis_utilises = array_map('array_shift', $ids_gis_utilises);
	// les points a supprimer sont les autres !
	$ids_gis = array_diff($ids_gis, $ids_gis_utilises);
}
// on supprime les points GIS non utilises
sql_delete('spip_gis', sql_in('id_gis', $ids_gis));

Télécharger

Fin du premier épisode

Bien, nous avons avec ceci à peu près migré correctement une table en l'intégrant dans un objet éditorial géré par SPIP. Il y a eu depuis quelques petits changements dans les codes qui n'ont pas lieu d'être commentés ici. Par exemple le script d'importation de données indique le nombre d'éléments qui sont insérés s'il doit se relancer en cas de timeout.

Dans le prochain article nous allons ajouter à notre plugin un autre objet avec d'autres contraintes.

Chats 2 - SPIP 3

Matthieu Marcillaud — 2011-09-01T18:36:26Z

Il y a presque deux ans, j'écrivais l'article Créer un nouvel objet éditorial en mettant des félins dans l'interface privée. Le développement de SPIP 3.0 (en alpha2 actuellement) fait des prouesses extraordinaires pour tout ce qui est la création et l'utilisation de nouveaux objets éditoriaux. Je propose ici de décrire la création d'une version 2.0 du plugin d'exemple Chats, en partant de rien.

SPIP 3.0 alpha 2

C'est le nom de la version en cours de développement et qui externalise un certain nombre de fonctionnalités de SPIP, tout en rendant générique un grand nombre de processus habituels (Cédric a effectué là de biens beaux travaux !). Cette version se voit dotée d'un espace privé entièrement en squelettes (et donc facilement surchargeable), découpé en Z, tout en normalisant le code HTML sous-jacent qui en avait besoin. Certaines fonctions anciennement en plugin ont été intégrées : les itérateurs, une partie de CFG, une partie de Bonux, Textwheel, Job Queue, et d'autres ont atterri en tant qu'extension par défaut de la distribution SPIP comme la médiathèque ou le plugin de boites modales (mediabox). La liste est longue des nouveautés et comme c'est encore loin d'être finalisé nous nous attarderons juste sur ce qui nous intéresse pour notre nouvel objet éditorial.

Il faut noter tout de même que dans cette nouvelle version, on peut déclarer, comme on le faisait pour déclarer des tables SQL à SPIP un nouvel objet éditorial. Ceci fait, la simple présence d'un champ « id_rubrique » permet de ranger l'objet dans une rubrique. La simple présence de « lang » permet de gérer des langues... la simple présence de « id_trad » permet de gérer les traductions... la simple déclaration de l'objet permet d'y lier des mots, des documents, des forums, de gérer les révisions de l'objet, déclarer des statuts permet d'afficher l'encart de changement de statut, d'accéder aux prévisualisations, ... Enfin presque !

Voilà... SPIP 3, c'est ça... mais c'est aussi que... on peut pratiquement ne rien écrire, SPIP est capable de générer à la volée une partie des pages nécessaires à l'affichage de l'objet si elles n'existent pas dans le plugin (ou en tant que surcharge ailleurs).

En fait, à l'heure ou j'écris, il faut tout de même écrire le code HTML du formulaire, et son code PHP. Mais vous allez voir que c'est impressionnant !

Débuter le plugin

Créons un plugin « chats » dans notre dossier plugins/ avec les fichiers :

paquet.xml
prive/themes/spip/images/chat-24.png de même que -48, -128 et -16
base/chats.php
chats_administrations.php
lang/chat_fr.php
lang/paquet-chats_fr.php

Nous allons les remplir au fur et à mesure. Tout d'abord, le paquet.xml.

paquet.xml

Comme on le remarque, la déclaration se fait maintenant avec un fichier nommé « paquet.xml » en lieu et place de « plugin.xml » (ce dernier est toujours compris par SPIP 3.0 alpha 2). « paquet.xml » a une écriture plus cohérente et concise.

Peu de choses ont changé dans les pipelines à l'exception notable, d'un nouveau pipeline pour déclarer l'objet (et sa table SQL). Il se nomme « declarer_tables_objets_sql ».

Enfin, une partie des descriptions du plugin (slogan, descriptif et éventuellement le nom) passent dans les chaînes de langue (lang/paquet-chats_fr.php), et peuvent ainsi être traduits.


	prefix="chats"
	categorie="edition"
	version="2.0.0"
	etat="stable"
	compatibilite="[3.0.0-alpha2;["
	logo="prive/themes/spip/images/chat-128.png"
	schema="1.0.0"
	documentation="http://marcimat.magraine.net/?article356"
>	
 
	>Chats (Plugin d'exemple)>
	
 
	 lien="http://magraine.net/">Matthieu Marcillaud>
	>GNU/GPL>
 
	 lien="http://www.yootheme.com/icons">Logo de YOOtheme>
 
 
	 nom="declarer_tables_objets_sql" inclure="base/chats.php" />
 
	
	 nom="saisies" compatibilite="[1.14.0;]" />
 
>

Télécharger

Nous retrouvons

le nom, l'auteur, la version
l'état (stable, test, dev)
le préfixe
la version de la structure des tables SQL du plugin se nomme maintenant « schéma »

chats_administrations.php

Le fichier d'installation, simple. Il peut changer (par rapport à SPIP 2.1) car on peut maintenant dans les mises à jour d'un plugin utiliser la même procédure que celle de SPIP Core pour les déclarer. Ainsi, une fonction « maj_plugin » permet de passer : la version actuelle, la version future, et un tableau de la liste des actions à faire. Contentons nous de la création et de la suppression du plugin :

function chats_upgrade($nom_meta_base_version, $version_cible){
 
	$maj = array();
	$maj['create'] = array(
 array('maj_tables', array('spip_chats')),
	);
 
	include_spip('base/upgrade');
	maj_plugin($nom_meta_base_version, $version_cible, $maj);
}
 
function chats_vider_tables($nom_meta_base_version) {
	sql_drop_table("spip_chats");
	effacer_meta($nom_meta_base_version);
}

Télécharger

Dans la variable $maj la clé « create » est appliquée à la première installation du plugin, et contient un tableau listant les fonctions à appeler avec leurs paramètres. Ici, on appelera donc l'équivalent de : maj_tables('spip_chats');.

Pour une mise à jour, on utilise par exemple $maj['numéro'] = array(...) tel que $maj['1.1.0'] = .... Nous le verrons plus loin.

base/chats.php

Le fichier de déclaration comporte les fonctions appelées par le pipeline « declarer_tables_objets_sql ». Voyons cela :

function chats_declarer_tables_objets_sql($tables){
	$tables['spip_chats'] = array(
 
 'principale' => "oui",
 'field'=> array(
 "id_chat"	=> "bigint(21) NOT NULL",
 "nom"	=> "tinytext DEFAULT '' NOT NULL",
 "race"	=> "tinytext DEFAULT '' NOT NULL",
 "date" => "datetime DEFAULT '0000-00-00 00:00:00' NOT NULL",
 "date_naissance" => "datetime DEFAULT '0000-00-00 00:00:00' NOT NULL",
 "robe"	=> "tinytext DEFAULT '' NOT NULL",
 "infos"	=> "text DEFAULT '' NOT NULL",
 "maj"	=> "TIMESTAMP"
 ),
 'key' => array(
 "PRIMARY KEY"	=> "id_chat",
 ),
 'titre' => "nom AS titre, '' AS lang",
 'date' => "date",
	);
 
	return $tables;
}

Télécharger

Ce tableau de la table peut prendre de nombreux autres attributs. Ils sont optionnels et complétés automatiquement par SPIP en absence de leur déclaration pour certains. Nous en verrons quelques-uns par la suite.

Nous remarquons les déclarations 'field' et 'key' qui n'ont pas changé, présentant le nom des champs et leur description SQL pour 'field', de même que le type de clé et le ou les champs d'application pour 'key'.

La clé "principale" indique que la table est une table qui s'auto-incrémente. Les clés "titre" et "date" (déclarées avant dans le pipeline declarer_tables_interfaces) indiquent respectivement les colonnes servant au calculs des titres d'URLs, et aux calculs de date (si besoin).

lang/paquet-chats.php

Mettons un peu de texte sur la signification du plugin dans le fichier lang/paquet-chats.php , tel que :

if (!defined('_ECRIRE_INC_VERSION')) return;
 
$GLOBALS[$GLOBALS['idx_lang']] = array(
	'chats_nom' => "Chats",
	'chats_slogan' => "Plugin d'apprentissage",
	'chats_description' => "Crée un nouvel objet éditorial de façon simple,
 donnant un exemple de code pour les développeurs.",
);

Télécharger

Ces descriptions pourront ainsi être traduites. Remarque : chats_nom n'est pas encore pris en compte à l'heure de l'écriture de ces lignes, mais c'est prévu.

Premier test

À partir de maintenant, le plugin doit pouvoir s'activer et s'installer. Il est présent dans la liste des plugins.


Affichage du plugin dans la liste des plugins: En cas d'erreurs dans le fichier paquet.xml, celles-ci seraient affichées de façon précise.

Une fois coché, et la configuration enregistrée, l'activation indique l'état de l'installation. Ici, le plugin installe la version 1.0 de sa structure SQL.


Activation du plugin chats: La version 1.0.0 du plugin chats est installée.

On peut alors aller sur l'URL privée ?exec=chats qui affiche en clignotant (pour l'instant) cela :


Liste des chats...: Les chaînes de langues absentes sont affichées en rouge

Ajout d'un bouton d'accès et des chaînes manquantes

Pour pourvoir accéder à la page ?exec=chats facilement, nous allons créer un bouton dans le menu, depuis la déclaration de paquet.xml. On en profitera pour ajouter dans la foulée un bouton d'ajout rapide d'un chat. Ces 2 lignes sont donc ajoutées à paquet.xml :

 nom="chats" titre="chat:titre_chats" parent="menu_edition" icone="images/chat-16.png" />
 
 nom="chat_creer" titre="chat:icone_creer_chat" parent="outils_rapides" icone="images/chat-new-16.png" action="chat_edit" parametres="new=oui" />

Télécharger

Il faudra ajouter une image « chat-new-16.png » qui est la même que « chats-16.png », avec un + de dessiné. Cette image (pour faciliter la création) se trouve dans SPIP dans prive/themes/images/add-16.png

Nous pouvons ensuite ajouter quelques chaînes de langue dans le fichier lang/chat_fr.php. Attention dans le nom du fichier : ici, c'est l'objet désiré au singulier, alors que pour le fichier de langue du paquet, c'est le préfixe du plugin qui est utilisé.

$GLOBALS[$GLOBALS['idx_lang']] = array(
	// I
	'icone_creer_chat' => "Créer un chat",
	'info_aucun_chat' => "Aucun chat",
 
	// T
	'titre_chats' => "Chats",
 
);

Télécharger

Aussitôt, on peut voir (en repassant sur la page d'administration des plugins pour mettre à jour les informations du paquet) les icônes et le texte :


Icone de chat rapide, et chaînes de langues présentes

Voilà qui est maintenant plus clair. On comprend que SPIP génère automatiquement cette page, car nous n'avons créé encore aucun squelette pour afficher quoi que ce soit. Cela pourrait être fait, mais nous allons essayer le lui faire faire le maximum de chose sans rien toucher.

Créer un chat

En cliquant le bouton de création d'un chat, on voit qu'il manque des choses :
une chaîne de langue... et un formulaire !


Édition d'un chat.: Il manque le formulaire !

La chaîne de langue va dans lang/chat.php en ajoutant

'icone_modifier_chat' => "Modifier ce chat",

Par la suite, et pour simplifier, je ne parlerai plus de l'ajout des chaînes de langue dans ce fichier. Vous saurez faire de toutes façons :)

Pour le formulaire, il va falloir un peu plus de travail, en créant les fichiers :

formulaires/editer_chat.html et
formulaires/editer_chat.php

Le fichier HTML est semblable à SPIP 2.1 et utilise ici le plugin « saisies » :


	[(#ENV**{message_ok})
]
	[(#ENV*{message_erreur})
]
 
	[(#ENV{editable})
	
 #ACTION_FORMULAIRE{#ENV{action}}
 
 
 [(#SAISIE{input, nom, label=<:chat:label_nom:>})]
 [(#SAISIE{input, race, label=<:chat:label_race:>})]
 [(#SAISIE{input, robe, label=<:chat:label_robe:>})]
 [(#SAISIE{textarea, infos, label=<:chat:label_infos:>})]
 
 [(#REM) ajouter les saisies supplementaires : extra et autre, a cet endroit ]

]

Télécharger

Le fichier PHP appelle des fonctions génériques de traitement des objets :

if (!defined("_ECRIRE_INC_VERSION")) return;
 
include_spip('inc/actions');
include_spip('inc/editer');
 
 
function formulaires_editer_chat_charger_dist($id_chat='new', $id_rubrique=0, $retour='', $lier_trad=0, $config_fonc='', $row=array(), $hidden=''){
	$valeurs = formulaires_editer_objet_charger('chat',$id_chat,$id_rubrique,$lier_trad,$retour,$config_fonc,$row,$hidden);
	return $valeurs;
}
 
/**
 * Identifier le formulaire en faisant abstraction des parametres qui ne representent pas l'objet edite
 */
function formulaires_editer_chat_identifier_dist($id_chat='new', $id_rubrique=0, $retour='', $lier_trad=0, $config_fonc='', $row=array(), $hidden=''){
	return serialize(array(intval($id_chat)));
}
 
function formulaires_editer_chat_verifier_dist($id_chat='new', $id_rubrique=0, $retour='', $lier_trad=0, $config_fonc='', $row=array(), $hidden=''){
	return formulaires_editer_objet_verifier('chat', $id_chat);
}
 
function formulaires_editer_chat_traiter_dist($id_chat='new', $id_rubrique=0, $retour='', $lier_trad=0, $config_fonc='', $row=array(), $hidden=''){
	return formulaires_editer_objet_traiter('chat',$id_chat,$id_rubrique,$lier_trad,$retour,$config_fonc,$row,$hidden);
}

Télécharger

Enfin, dans la déclaration de l'objet (base/chats.php), il faut indiquer à SPIP les champs qu'il a le droit de modifier en ajoutant la clé :

'champs_editables' => array(
	"nom", "race", "robe", "infos", "date_naissance"
),

Télécharger

Avec quelques chaînes de langues en plus, voici ce que l'on obtient : le formulaire est visible et fonctionne (cependant il ne réaffiche pas les textes saisis après une création).


Formulaire de modification du chat

La liste des chats liste les créations.


Liste des chats

Enfin, la vue d'un chat permet de changer la date de publication et de mettre un logo. Elle n'affiche pas automatiquement autre chose que le titre.


Vue d'un chat

Lier des documents et des mots clés

Pour lier des documents au chat il suffit de cocher les « Chats » dans la configuration des documents sur ?exec=configurer_contenu.

Pour lier des mots clés, il suffit de créer un groupe de mot permettant la liaison avec des chats.


Mots clés, document et logo

Versionner les modifications des chats

Pour pouvoir revenir sur des modifications effectuées sur le contenu de la table chats, il faut indiquer quels champs sont versionnables, puis activer les « révisions » sur l'objet Chats (?exec=configurer_revisions). On ajoute donc, dans la déclaration de notre objet éditorial :

'champs_versionnes' => array(
	"nom", "race", "robe", "infos", "date_naissance", 
),

Télécharger

Sur l'accueil, on peut ainsi suivre les modifications faites, puis revenir dessus éventuellement depuis la page des révisions :


Révisions sur l'accueil


Révision d'un chat

Lier les chats aux rubriques

Pour pouvoir lier un chat à une, et une seule rubrique, il suffit de créer un champ « id_rubrique » dans la table spip_chats et d'ajouter un sélecteur de rubrique dans le formulaire d'édition.

Déclarons le dans base/chats.php, avec les autres champs :

'field'=> array(
	"id_chat"	=> "bigint(21) NOT NULL",
	"id_rubrique" => "bigint(21) NOT NULL DEFAULT 0",
	...

Télécharger

Créons la mise à jour dans chats_administrations.php en ajoutant la version 1.1.0, qui ajoute le champs id_rubrique et un index dessus :

$maj['1.1.0'] = array(
	array('maj_tables', array('spip_chats')),
	array('sql_alter', "TABLE spip_chats ADD INDEX id_rubrique(id_rubrique)")
);

Télécharger

Changeons le schéma dans paquet.xml pour refléter la mise à jour :

	schema="1.1.0"

Enfin, ajoutons un sélecteur de rubrique sur le formulaire d'édition (repris de celui sur le formulaire d'édition d'un article) :

[
[ (#ENV**{erreurs}|table_valeur{id_parent}|oui)erreur]">

<:titre_cadre_interieur_rubrique:>[

(#ENV**{erreurs}|table_valeur{id_parent})

]

(#VAL|chercher_rubrique{#ENV{id_chat},#ENV{id_parent},'chat',#ENV{id_secteur},'',0,form_simple})

]

Télécharger

Et regardons maintenant :


Choix d'une rubrique

Afficher les chats sur les rubriques

Pour aller plus loin, on va vite souhaiter pouvoir créer et voir des chats depuis les rubriques. Pour cela, il va nous falloir d'une part se brancher sur le pipeline « affiche_enfants », et d'autre part créer un premier squelette de liste de chats, permettant de trier les chats, mais surtout de filtrer par rubrique la liste.

Ajoutons l'utilisation du pipeline dans paquets.xml :

 nom="affiche_enfants" inclure="chats_pipelines.php" />

Ajoutons dans le pipeline, l'appel à notre future nouvelle liste d'éléments, ainsi que le bouton pour ajouter de nouveaux chats si l'on peut. Avec la fonction trouver_objet_exec() qui retourne des informations utiles sur la page en cours de lecture dans l'espace privé, on peut filtrer l'affichage sur le type d'objet, et le fait qu'il soit ou non en édition.

function chats_affiche_enfants($flux) {
	if ($e = trouver_objet_exec($flux['args']['exec'])
 AND $e['type'] == 'rubrique'
 AND $e['edition'] == false) {
 
 $id_rubrique = $flux['args']['id_rubrique'];
 
 $bouton = '';
 if (autoriser('creerchatdans','rubrique', $id_rubrique)) {
 $bouton .= icone_verticale(_T('chat:icone_creer_chat'), generer_url_ecrire('chat_edit', "id_rubrique=$id_rubrique"), "chat-24.png", "new", 'right')
 . "
";
 }
 
 $lister_objets = charger_fonction('lister_objets','inc');	
 $flux['data'] .= $lister_objets('chats', array('titre'=>_T('chat:titre_chats_rubrique') , 'id_rubrique'=>$id_rubrique, 'par'=>'nom'));
 $flux['data'] .= $bouton;
 
	}
	return $flux;
}

Télécharger

La fonction lister_objet permet d'appeler un squelette affichant une liste de l'objet souhaité. Il est stocké dans prive/objets/liste/chats.html. Son code peut ressembler à ça :

[(#SET{defaut_tri,#ARRAY{
	nom,1,
	date,#ENV{date_sens,-1},
	id_chat,1
}})
]
#ANCRE_PAGINATION
[
]	
 
 
 
 
 
 
 
	
	
	(CHATS){id_rubrique?}{id_mot?}{id_auteur?}{where?}{statut?}{recherche?}{tri #ENV{par,num nom},#GET{defaut_tri}}{pagination #ENV{nb,10}}>
 
[(#COMPTEUR_BOUCLE|alterner{row_odd,row_even})]"> 
 
 
 
 
 
	
	
(#ENV*{titre,#GRAND_TOTAL|singulier_ou_pluriel{chat:info_1_chat,chat:info_nb_chats}}) [(#TRI{nom,<:chat:label_nom:>,ajax})] [(#TRI{date,<:date:>,ajax})] [(#TRI{id_chat,<:info_numero_abbreviation:>,ajax})]
[(#CHEMIN_IMAGE{chat-16.png}|balise_img)] [(#LOGO_CHAT|image_reduire{20,26})][(#ID_CHAT|generer_url_entite{chat})]" title="<:info_numero_abbreviation|attribut_html:> #ID_RUBRIQUE">[(#RANG). ]#NOM [(#DATE|affdate_jourcourt)] [(#AUTORISER{modifier,chat,#ID_CHAT}|?{ [(#URL_ECRIRE{chats_edit,id_chat=#ID_CHAT})]">#ID_CHAT,
 #ID_CHAT
 })]
[(#PAGINATION{prive})
]

**(#ENV*{titre,#GRAND_TOTAL|singulier_ou_pluriel{chat:info_1_chat,chat:info_nb_chats}})**
	[(#TRI{nom,<:chat:label_nom:>,ajax})]		[(#TRI{date,<:date:>,ajax})]	[(#TRI{id_chat,<:info_numero_abbreviation:>,ajax})]
[(#CHEMIN_IMAGE{chat-16.png}\|balise_img)]	[(#LOGO_CHAT\|image_reduire{20,26})][(#ID_CHAT\|generer_url_entite{chat})]" title="<:info_numero_abbreviation\|attribut_html:> #ID_RUBRIQUE">[(#RANG). ]#NOM		[(#DATE\|affdate_jourcourt)]	[(#AUTORISER{modifier,chat,#ID_CHAT}\|?{ [(#URL_ECRIRE{chats_edit,id_chat=#ID_CHAT})]">#ID_CHAT, #ID_CHAT })]

[

(#ENV*{sinon,''})

]

Télécharger

On peut ainsi voir la liste des chats appartenant à une rubrique, dans la vue de la rubrique :


Chats dans une rubrique

Donner sa langue au chat

La présence des champs "lang" et "langue_choisie" dans la table SQL des chats suffit à faire afficher un formulaire de changement de langue de l'objet. Ajoutons les.

Dans base/chats.php ajouter :

"lang" => "VARCHAR(10) DEFAULT '' NOT NULL",
"langue_choisie"	=> "VARCHAR(3) DEFAULT 'non'",

Télécharger

Dans base/chats_administrations.php ajouter :

$maj['1.3.0'] = array(array('maj_tables', array('spip_chats')));

Enfin, changer la version du schéma dans paquet.xml :

schema="1.3.0"

Après un passage sur la page d'administration des plugins pour effectuer la mise à jour, sur la page de configuration de multilinguisme, on peut cocher la présence du formulaire de langue sur les Chats :


Configuration du multilinguisme

Ainsi, pour tout nouveau chat créé, le formulaire de langue s'affiche et on peut modifier la langue (pour peu qu'il y ait au moins 2 langues possibles dans la configuration du multilinguisme). Pour les anciens chats, il faudrait faire une mise à jour de la base en leur définissant une langue par défaut, sinon, le bouton [changer] n'apparaît pas.


Langue au chat

Traductions de chats

Sur le même principe que précédemment, on ajoute le champ « id_trad » tel que :

"bigint(21) DEFAULT '0' NOT NULL",">

"id_trad" => "bigint(21) DEFAULT '0' NOT NULL",

Sur la page de configuration du multilinguisme, il faut cocher la gestion des traductions sur les chats :


Gestion des traductions sur les chats

Il faut aussi appeler des fonctions qui vont peupler le formulaire de création d'un chat, traduction d'un autre, par les textes de la traductions. Pour cela, il faut créer le fichier inc/precharger_chat.php contenant au moins la première fonction (la seconde étant facultative si on ne change pas le code qui est présenté ici) :

include_spip('inc/precharger_objet');
 
function inc_precharger_chat_dist($id_chat, $id_rubrique=0, $lier_trad=0) {
	return precharger_objet('chat', $id_chat, $id_rubrique, $lier_trad, 'nom');
}
 
// fonction facultative si pas de changement dans les traitements
function inc_precharger_traduction_chat_dist($id_chat, $id_rubrique=0, $lier_trad=0) {
	return precharger_traduction_objet('chat', $id_chat, $id_rubrique, $lier_trad, 'nom');
});
}

Télécharger

On peut ainsi traduire un chat :


Formulaire de traduction d'un chat


Traduction préremplie du texte d'origine

Lier des auteurs aux chats

On pourrait créer le squelette qui affiche le contenu de notre chat, qui afficherait le formulaire de liaison entre auteurs et chat dedans, ainsi que les autres formulaires souhaités.

Nous pouvons aussi continuer d'utiliser le squelette créé automatiquement par SPIP et se brancher sur le pipeline « affiche_milieu » pour ajouter le formulaire d'auteurs sur les chats. C'est ce que nous allons voir ici. Dans paquet.xml, on ajoute l'appel au pipeline :

 nom="affiche_milieu" inclure="chats_pipelines.php" />

Son utilisation appelle l'inclusion de SPIP prive/objets/editer/liens, qui elle-même appelle le formulaire éditer liens, permettant de lier 2 objets entre eux et d'afficher les liaisons existantes. Il suffit d'indiquer la source (les auteurs) et la cible, et le tour est joué :

function chats_affiche_milieu($flux) {
	if ($e = trouver_objet_exec($flux['args']['exec'])
 AND $e['type'] == 'chat'
 AND $e['edition'] == false) {
 $texte = recuperer_fond('prive/objets/editer/liens', array(
 'table_source' => 'auteurs',
 'objet' => $e['type'],
 'id_objet' => $e['id_objet'],
 #'editable'=>autoriser('associerauteurs', $e['type'], $e['id_objet']) ? 'oui' : 'non'
 ));
 if ($p=strpos($flux['data'],""))
 $flux['data'] = substr_replace($flux['data'],$texte,$p,0);
 else
 $flux['data'] .= $texte;
	}
 
	return $flux;
}

Télécharger


Auteurs liés à un chat

Mettre des statuts sur les chats

Pour mettre des statuts de publication sur les chats, il faut un champ « statut » sur la table SQL, quelques déclarations et des chaînes de langues, éventuellement quelques autorisations.

Sur le principe habituel, on ajoute le champ statut dans la déclaration de base/chats.php (il faudra faire une mise à jour dans chats_administrations.php).

"varchar(255) DEFAULT '0' NOT NULL",">

"statut" => "varchar(255) DEFAULT '0' NOT NULL",

Le code de la mise à jour ajoute aussi la valeur "publie" a tous les chats déjà existants :

$maj['1.5.0'] = array(
	array('maj_tables', array('spip_chats')),
	array('sql_updateq', 'spip_chats', array('statut'=>'publie'))
);

Télécharger

On ajoutera aussi une déclaration des statuts prévus, toujours dans la déclaration de l'objet, ainsi qu'une description des critères limitant l'affichage d'une boucle CHATS en fonction du statut du chat :

'statut_textes_instituer' => array(
	'prepa' => 'texte_statut_en_cours_redaction',
	'prop' => 'texte_statut_propose_evaluation',
	'publie' => 'texte_statut_publie',
	'refuse' => 'texte_statut_refuse',
	'poubelle' => 'texte_statut_poubelle',
),
'statut'=> array(
	array(
 'champ' => 'statut',
 'publie' => 'publie',
 'previsu' => 'publie,prop,prepa',
 'post_date' => 'date',	
 'exception' => array('statut','tout')
	)
),

Télécharger

La clé statut_textes_instituer indique la liste des statuts de notre objet éditorial ainsi que le nom des chaînes de langue correspondantes.

La clé statut dit à peu près : que restreint-on d'afficher en fonction de tel champ ? La restriction porte sur quel champ SQL ? Quel est la valeur de ce champ lorsqu'un chat est publié, lorsqu'il peut être prévisualisé. Y a t'il une date à prendre en compte pour ne pas publier les chats avant une certaine date (post_date) ? et quels critères de boucles annulent la prise en compte de cette restriction : ici {statut} et {tout}.


Statuts sur les chats

Lier des chats à des articles

Voici la plus grosse partie des squelettes et codes PHP à produire dès lors que l'on veut lier notre objet à 0 ou plusieurs autres objets, depuis la page de ceux-ci, par exemple lier des chats à des articles, depuis la page d'un article.

Pour installer un formulaire de liaison de chats sur les articles, un peu comme pour les auteurs précédemment, il va falloir insérer le formulaire sur les articles, en utilisant le même pipeline affiche_milieu. Il faut avant tout qu'il existe une table spip_chats_liens pour pouvoir lier des chats. Créons tout ça.

Dans paquet.xml, on change le schéma, et on ajoute le pipeline declarer_table_auxiliaires :

<pipeline nom="declarer_tables_auxiliaires" inclure="base/chats.php" />

On déclare dans ce pipeline notre table de liaison :

function chats_declarer_tables_auxiliaires($tables) {
	$tables['spip_chats_liens'] = array(
 'field' => array(
 "id_chat"	=> "bigint(21) DEFAULT '0' NOT NULL",
 "id_objet"	=> "bigint(21) DEFAULT '0' NOT NULL",
 "objet"	=> "VARCHAR (25) DEFAULT '' NOT NULL",
 "vu"	=> "VARCHAR(6) DEFAULT 'non' NOT NULL"
 ),
 'key' => array(
 "PRIMARY KEY"	=> "id_chat,id_objet,objet",
 "KEY id_chat"	=> "id_chat"
 )
	);
	return $tables;
}

Télécharger

On crée la mise à jour dans chats_administrations.php :

$maj['1.6.0'] = array(array('maj_tables', array('spip_chats_liens')));

Ceci fait, il va nous falloir créer plusieurs squelettes de liste. Le premier prive/objets/liste/chats_lie.html est une liste affichée lorsque des chats sont liés à un objet.

Il peut être (inspiré de celui des mots-clés) :

[(#SET{defaut_tri,#ARRAY{
	num nom,1,
	nom,1,
	race,1,
	id_chat,1
}})
]
#ANCRE_PAGINATION
[
]	
 
 
 
 
 
 
	
	
	(CHATS){statut==.*}{id_chat?}{id_rubrique?}{id_objet?}{objet}{where?}{tri #ENV{par,nom},#GET{defaut_tri}}{par num nom,nom}{pagination #ENV{nb,10} chatl}>
 
[(#COMPTEUR_BOUCLE|alterner{row_odd,row_even})][(#ID_CHAT|=={#ENV{id_lien_ajoute}}|oui)append]"> 
 
 
 
 
	
	
(#ENV*{titre,#GRAND_TOTAL|singulier_ou_pluriel{chat:info_1_chat,chat:info_nb_chats}}) [(#TRI{nom,<:chat:label_nom:>,ajax})] [(#TRI{race,<:chat:label_race:>,ajax})]  
[(#CHEMIN_IMAGE{chat-16.png}|balise_img)] [(#LOGO_CHAT|image_reduire{20,20})][(#ID_CHAT|generer_url_entite{chat})]" title="<:info_numero_abbreviation|attribut_html:> #ID_CHAT">[(#RANG). ]#NOM #RACE 
[(#PAGINATION{prive})
]
[(#GRAND_TOTAL|>{3}|oui)
]

**(#ENV*{titre,#GRAND_TOTAL|singulier_ou_pluriel{chat:info_1_chat,chat:info_nb_chats}})**
	[(#TRI{nom,<:chat:label_nom:>,ajax})]	[(#TRI{race,<:chat:label_race:>,ajax})]
[(#CHEMIN_IMAGE{chat-16.png}\|balise_img)]	[(#LOGO_CHAT\|image_reduire{20,20})][(#ID_CHAT\|generer_url_entite{chat})]" title="<:info_numero_abbreviation\|attribut_html:> #ID_CHAT">[(#RANG). ]#NOM	#RACE

[(#ENV*{titre,<:chat:info_aucun_chat:>}) ]

Télécharger

La seconde liste est utilisée pour rechercher des chats à lier, et doit se créer dans prive/objets/liste/chats_associer.html. Il peut être ainsi, et fait appel à un troisième squelette s'il y a un trop grand nombre de chats :

[(#SET{defaut_tri,#ARRAY{
	statut,1,
	multi nom,1,
}})]
[(#SET{_MAX_CHATS_LISTE,[(#VAL{_MAX_CHATS_LISTE}|defined|?{[(#VAL{_MAX_CHATS_LISTE}|constant)],50})]})]
(CHATS){tout}{id_objet}{objet}{doublons 1}{doublons 2} />
(CHATS){tout}{doublons 1} />#SET{total,#TOTAL_BOUCLE}
 
(CONDITION){si #GET{total}|>{#GET{_MAX_CHATS_LISTE}}}>
 
	[(#INCLURE{fond=prive/objets/liste/chats_associer-recherche,env,doublons})]
 
 
[(#REM) Pas beaucoup de chat ]
#ANCRE_PAGINATION
[
]	
 
 
 
 
 
	
	
	(CHATS){doublons 2}{tri #ENV{par,nom},#GET{defaut_tri}}{par num nom, nom}{pagination 10}>
 
[(#COMPTEUR_BOUCLE|alterner{row_odd,row_even})]"> 
 
 
 
	
	
(#ENV*{titre,#GRAND_TOTAL|singulier_ou_pluriel{chat:info_1_chat,chat:info_nb_chats}}) [(#TRI{nom,<:chat:label_nom:>,ajax})]  
[(#CHEMIN_IMAGE{chat-16.png}|balise_img)] [(#LOGO_CHAT|image_reduire{20,20})][(#ID_CHAT|generer_url_entite{chat})]" title="<:info_numero_abbreviation|attribut_html:> #ID_CHAT">[(#RANG). ]#NOM 
[(#PAGINATION{prive})
]

**(#ENV*{titre,#GRAND_TOTAL|singulier_ou_pluriel{chat:info_1_chat,chat:info_nb_chats}})**
	[(#TRI{nom,<:chat:label_nom:>,ajax})]
[(#CHEMIN_IMAGE{chat-16.png}\|balise_img)]	[(#LOGO_CHAT\|image_reduire{20,20})][(#ID_CHAT\|generer_url_entite{chat})]" title="<:info_numero_abbreviation\|attribut_html:> #ID_CHAT">[(#RANG). ]#NOM

[(#ENV*{titre,<:chat:info_aucun_chat:>}) ]

Télécharger

Lorsqu'il y a trop de résultats à afficher, c'est un autre squelette qui est appelé, prive/objets/liste/chats_associer-recherche.html qui offre un champ de saisie pour rechercher parmi les chats afin de restreindre les résultats. Il peut être :

[(#ENV*{recherche})]" />
<:info_rechercher:>" />
#SET{recherche,#ENV*{recherche}}
[(#GET{recherche}|non|et{#ENV*{rechercheb}})
	#SET{recherche,'/./'}
	
]
#ANCRE_PAGINATION
[
]	
 
 
 
 
 
 
	
	
	(CHATS){doublons 2}{recherche #GET{recherche}}{tri #ENV{par,nom},#GET{defaut_tri}}{par num nom}{pagination 10 chata}>
 
[(#COMPTEUR_BOUCLE|alterner{row_odd,row_even})]"> 
 
 
 
 
	
	
(#ENV*{titre,#GRAND_TOTAL|singulier_ou_pluriel{chat:info_1_chat,chat:info_nb_chats}}) [(#TRI{nom,<:chat:label_nom:>,ajax})] [(#TRI{race,<:chat:label_race:>,ajax})]  
[(#CHEMIN_IMAGE{chat-16.png}|balise_img)] [(#LOGO_CHAT|image_reduire{20,20})][(#ID_CHAT|generer_url_entite{chat})]" title="<:info_numero_abbreviation|attribut_html:> #ID_CHAT">[(#RANG). ]#NOM #RACE 
[(#PAGINATION{prive})
]

**(#ENV*{titre,#GRAND_TOTAL|singulier_ou_pluriel{chat:info_1_chat,chat:info_nb_chats}})**
	[(#TRI{nom,<:chat:label_nom:>,ajax})]	[(#TRI{race,<:chat:label_race:>,ajax})]
[(#CHEMIN_IMAGE{chat-16.png}\|balise_img)]	[(#LOGO_CHAT\|image_reduire{20,20})][(#ID_CHAT\|generer_url_entite{chat})]" title="<:info_numero_abbreviation\|attribut_html:> #ID_CHAT">[(#RANG). ]#NOM	#RACE

[(#ENV*{recherche}|oui)

[(#ENV*{titre,<:chat:info_aucun_chat:>}) ]

]

Télécharger

Note : Il y a certainement moyen de regrouper ces 2 derniers squelettes en un seul, mais je n'ai pas pris le temps de le faire.

On obtient donc, sur la page d'un article :


Des chats sur les articles

Permettre de chercher des chats

Pour permettre la recherche de chat dans l'espace privé ou via le critère {recherche} sur une boucle chat, il faut le déclarer dans la description de l'objet, en ajoutant dedans :

'rechercher_champs' => array(
	'nom' => 8, 'race' => 1, 'robe' => 1, 'infos' => 2
),

Télécharger


Recherche parmi les chats

Conclusion

Voilà une petite démonstration prometteuse donc, pour ce qui concerne les objets éditoriaux. L'espace privé utilisant Zpip permet d'adapter facilement les pages que créée SPIP, ce qui n'est pas montré ici. Une prochaine fois peut être :)

Culture sur butte

Matthieu Marcillaud — 2011-08-16T13:17:46Z

Puisque nous avons un jardin devant la maison que nous louons, nous en profitons pour tester et mettre en pratique des méthodes de cultures, et notamment le jardinage sur buttes de cultures permanentes. Une fois construites, la pénibilité que peut représenter le jardinage, à se baisser constamment au sol, et à y travailler la terre, disparaît. Les plantations se font à hauteur de genoux, les récoltes aussi, ce qui est bien moins ruinant pour le dos. L'organisation des plantations, à la fois espacées et mélangées, permettent d'être plus résistant aux éventuelles maladies et prédateurs tout en favorisant des associations bénéfiques. Un couvert ou paillage végétal permet de limiter l'envahissement des herbes tout en apportant abri et nourriture pour la microfaune du sol. Voici donc quelques photos de nos premières buttes, inspirées des travaux de Richard Wallner.

Construction

Nous sommes partis sur la création de 2 buttes de 1m70 de large, et de 8m de long. 3 allées de 60cm le large et 40cm de profondeur sont nécessaires, que nous complétons avec 2 petites buttes (80cm et 60cm de large), ce qui donne, de façon très schématique, ceci :


Schéma en perspective des buttes.

Nous avons choisi, comme matériaux pour retenir la terre des buttes dans les allées des demi-rondins de châtaigniers, ainsi que des piquets de vigne en châtaigniers aussi pour les maintenir.

La construction commença début mai et fut finie début juillet (on s'y consacrait de temps en temps 1h, ce qui n'avançait pas vite, le sol était extrêmement sec... sans parler des rochers !).

Les étapes consistent à :

désherber la partie qui recevra les buttes et conserver les herbes, qui serviront de paillage dans les allées
enlever 3 à 5 cm de terre sur la surface, la plus riche biologiquement, et la conserver. Elle sera remise sur les buttes une fois réalisées.
creuser les allées. La terre évacuée des allées va sur l'emplacement des buttes, qui se forment alors.
installer les planches ou demi-rondins qui retiennent la terre des allées
modeler la butte
installer un système d'arrosage goutte à goutte
pailler
planter :)

Voici quelques photos des buttes et de la construction :


Le déserbage: Les herbes sont enlevées et mises en tas


Herbes en tas: Toutes les herbes ont étés enlevées


3 à 5cm de terre mis de côté: La terre de surface est mise de côté.


Retenir la terre: La terre qui sera pelletée des allées sera retenue dans un premiers temps, à l'emplacement des buttes, par des planches (ici des demi-rondins de châtaigniers).


Creuser une allée: La terre est donc creusée de 40cm, dans notre cas, à la grelinette (50cm de large) et à la fourche. Surprise... à 40cm... on trouve du « platin » : plein de petits et gros cailloux calcaires, voire parfois des rochers.


Début de l'allée: Au fur et à mesure de l'avancement, on installe les demi-rondins pour retenir la terre.


Seconde allée: L'expérience de la première butte à montré qu'il vallait mieux 2 rondins pour retenir temporairement la terre (ça permet d'en mettre plus sur une plus petite largeur).


Trois phases: La troisième allée se creuse. Sur la première butte, la terre mis de côté et en peu de compost du jardin ont été mis, ainsi que les tuyaux de gouttes à gouttes (récupérés chez un maraîcher). Sur la mini-butte à gauche, l'arrosage et un paillage en copeau de châtaigniers est mis, avec quelques plantations.

Puis est arrivé « le drame » :) Un violent orage. Et les buttes se sont inclinées. En fait, comme le sol à 40 cm était en pierre, il avait été difficile de bien enfoncer les piquets. Ils sont du coup tombés :


Un violent orage, et c'est la cata !

Nous avons du employer les grands moyens pour corriger ça : une perceuse à percussion, une mèche à pierre de 3cm de diamètre, des trous dans les cailloux, la barre à mine, la masse, et les piquets sont tout de suite bien mieux enfoncés. Depuis, rien n'a bougé.

Plantations

Quelques photos des buttes. Au 14 juillet :


Buttes (le 14 juillet): La butte de droite, qui avait eu moins de paillage commence à voir pousser de nombreuses herbes. Elles restent limitées sur celle de gauche, qui a eu en plus de nombreuses plantations.

Au 4 août, la butte ressemblait à cela. Dessous, le schéma d'implantation des différentes plantes présentes, relevé ce jour là pour mémoire.


Buttes (4 août): Toutes les plantations ont bien pris. Une petite exception pour les pieds d'aubergines qui restent de petite taille.


Schéma implantation (4 aout)

Aujourd'hui, 16 août, avec quelques gros plans :


Buttes (16 août)


Bourrache: Ce plant de bourrache, à l'extrémité chaude de la butte se plaît merveilleusement bien. Il offre de jolis fleurs pour décorer les salades et attire les pollinisateurs.


Long concombre: Sous les haricots et les œillets, un concombre.


Consoude et luzerne: La consoude (en bas à gauche) et la luzerne, encore jeunes ici, servent d'engrais vert, et seront utilisés comme paillage l'année prochaine, en plus de la vesce qui sera semée sur certaines parties des buttes en septembre.

Affaire à suivre...

BREFT (découpe)

Matthieu Marcillaud — 2011-04-21T18:29:24Z

Petit mot pour dire que le BREFT (Bois Raméal En Fins Tronçons) présenté dans l'article précédent se « fabrique » bien mieux avec une petite scie égoïne.

Le magasin de bricolage/jardinage nous a très bien conseillé sur ce coup là. Nous nous retrouvons donc à découper du BREFT bien plus rapidement avec une petite scie égoïne (18€) et dans une moindre mesure, avec un nouveau sécateur (10€).


Petite scie égoïne: Idéale pour couper ces petites branches d'1 cm de diamètre maximum.

Du coup, nous pouvons placer une plus grande quantité de branchages sur la chèvre et n'avons plus besoin d'utiliser de bûche pour appuyer dessus. Tout le travail de découpe en est donc facilité.


Découpe de BREFT avec scie égoïne: Il manque une main sur cette vue : celle qui appuie sur les branches à droite de la scie, mais elle prenait une photo :) . On réceptionne donc les branches dans l'espace en V de la chèvre en maintenant ces branches d'une main. Un opérateur tient l'autre coté des branches pendant que la coupe se fait.

L'inconvénient des feuilles de cette époque est qu'à un moment, le volume dépasse largement la hauteur du tréteau et qu'il faut donc maintenir ce fagot pour ne pas qu'il chute.


Débordement de verdure !: Lorsque l'on met de nombreuses tiges, le volume des feuilles est difficile à gérer sur une partie car il déborde de la chèvre.

Nous avons ainsi récolté en 2h environ 2 fois ce qu'on avait récolté hier en 1h30, soit 1,5 fois plus pour une même durée, sans se presser. Comme quoi, avoir un bon outil adapté est plus agréable à utiliser et plus efficace.


Récolte de BREFT: Voilà donc ce qu'on a produit en 2h (à deux personnes).