Accueil > SPIP > Champs extras > Champ extra, crayons, sqlite
Champ extra, crayons, sqlite
mardi 7 décembre 2010, par
Pour un projet associatif, j’utilise une base de donnée [?SQLite] que je gère via SPIP.
J’ai ajouté à la table spip_articles de SPIP un champ extra, et je souhaitais pouvoir l’éditer via les Crayons.
Voilà comment j’ai procédé, une fois le champ extra ajouté.
Pour rendre éditable le champs (que j’appel ici #CHAMP) via les crayons, rien de plus simple.
<div class='#EDIT{champ}'>
#CHAMPSeulement voilà : j’obtenais lors de l’édition, non un textarea mais un simple input, ce qui pour rend l’édition compliqué, puisque le contenu du champ peut faire plusieur ligne.
Le plugin crayon définit le type de champ de formulaire, appelé « Contrôleurs » affiché selon le type du champ SQL. Pour les champs de type TEXT, cela dépend de la longueur.
Seulement voilà, en SQLite, les champs de type TEXT ne peuvent avoir qu’une seule longueur. Il n’y a pas de TINYTEXT ou de MEDIUMTEXT ou autre BIGTEXT. C’est pourquoi j’avais systématiquement un input, et non pas un textarea.
Les crayons ont un contrôleur et une vue [1] par défaut pour les champs extra, mais on peut en définir des nouveaux pour chaques types de champ.
Le contrôleur
Dans mon dossier de squelettes [2], j’ai créé un dossier controleurs, dedans un squelette champ.html, qui contient ceci
[(#REM)
Controleur pour le crayon 'champ' , uniquement html
]
#CACHE{0}
<BOUCLE_a(ARTICLES){id_article}{statut==.}>
<textarea class="crayon-active" name="#ENV{name_champ}"
style="width:#ENV{largeur}px; height:#ENV{hauteur}px;#ENV{style}">
[(#CHAMP**)]</textarea>
</BOUCLE_a>La vue
Idem, dans mon dossier de squelettes, j’ai créé un dossier vues.
Et dans ce dossier un fichier champ.html, qui contient
[(#REM)
Vue pour le crayon 'champ'
]
#CACHE{0}
<BOUCLE_a(ARTICLES){id_article}{statut==.}>
[(#CHAMP|propre)]
</BOUCLE_a>Et voilà, j’ai désormais mes crayons qui me permettent d’éditer un champ texte long avec une base SQLite.
J’ai choisi d’utiliser SQLite
- Pour économiser une base [?MySQL] chez L’Autre.net, qui limite le nombre à six par adhérents
- Parce que je n’avais pas besoin d’une base MySQL, étant donné que seulement cinq personnes peuvent la consulter, et que donc les performances ne sont pas vraiment en jeux.
- Parce qu’il est plus simple de récupérer par FTP le fichier SQLite que de passer par PhpMyAdmin pour faire un export [3].
[1] i. e. ce qui est affiché après la modification d’un champ via les crayons.
[2] Qui est sous forme de plugin, .cf mon article « Jeux de squelettes sous forme de plugin ».
[3] SQLite ne fonctionne pas selon un schéma client/serveur, mais avec un fichier local. Cause, en partie, de ses faibles performances.