[spip-dev] ajouter des colonnes dans les articles

615beda9217b323297ed · Mai 26, 2003, 9:05

Bonjour,
Me revoila à propos d'une question d'il y a quelques temps :

J'aimerai savoir s'il est possible de rajouter des zones personnalisables
(comme les zones 'Titre' ou 'Texte') à l'intérieur des articles.

J'avais proposé une solution consistant à détourner un champ existant.
Comme j'ai également un besoin de ce style, j'ai codé ça ce week-end.

Ci-joint, un petit "readme" associé. Si le principe vous parait
intéressant, le patch et les fichiers supplémentaires sont dispo ici :
http://piif.lautre.net/tmp/ (prendre le tgz puisque les .php3 sont
interprétés ...) le patch est un peu bancale puisque je n'ai pas la
version cvs des sources.

Soit vous jetez tout en vrac, soit on intègre dans spip, soit on en
fait une contrib. Dans le dernier cas, ça marche comment ? il faut que
je m'inscrive rédacteur sur spip-contrib et que j'en fasse une
proposition d'article ?

(comme je suis en php4 chez moi, et que je maitrise pas trop les
finesses de php, il est possible qu'il y ait des incompatibilités,
n'hésitez pas à me le signaler).

À+, Pif

champs_suppl.txt (2.18 KB)

fil · Mai 26, 2003, 9:17

Salut Pif,

Ci-joint, un petit "readme" associé. Si le principe vous parait
intéressant, le patch et les fichiers supplémentaires sont dispo ici :

dans la TODO (ainsi que dans pas mal de mails dans les archives), on aborde
le problème de l'"extension" d'objets

* Comment fait-on pour les extensions d'objets ? Un simple champ extension,
  valable pour tout le monde, et contenant un tableau serialize(), ou bien
  création/délétion d'une colonne MySQL depuis la page de configuration
  avancée ?

Ce que tu proposes correspond à la solution "serialize" (mais "serialize est
peut-être un peu plus propre que ce que tu as choisi).

Par contre il ne faut pas détourner le champ PS, il est trop court pour
qu'on n'arrive pas tout de suite aux limites, et il est déjà utilisé sur
nombre de sites. Il faudrait plutôt ajouter un champ "extension(s)" à chaque
type d'objet (articles, breves, auteurs, ...), une page de configuration des
extensions, et les filtres qui vont bien pour l'espace public (comme celui
que tu proposes).

Par ailleurs, tu as accès comme tout le monde à la "version cvs des
sources", en lecture seule, cf. les explications sur
http://rezo.net/spip-dev/devel/

-- Fil

Nicolas_Hoizey2 · Mai 26, 2003, 9:32

Hello,

dans la TODO (ainsi que dans pas mal de mails dans les archives), on
aborde le problème de l'"extension" d'objets

* Comment fait-on pour les extensions d'objets ? Un simple champ
extension, valable pour tout le monde, et contenant un tableau
serialize(), ou bien création/délétion d'une colonne MySQL depuis la
page de configuration avancée ?

Si on commence à gérer des colonnes supplémentaires par configuration,
ça va poser des problèmes techniques pénibles.

Quitte à revoir cela, autant passer sur un méta modèle de documents,
qui permette de composer soi-même des types de documents en y plaçant
autant de champs que l'on veut, avec des types pré-définis. C'est ce
qui est fait dans un grand nombre de softs.

Ca apporte une souplesse formidable, certes, mais ça complique aussi
pas mal les choses côté squelettes et gestion "humaine" de la
cohérence globale. A l'administrateur de créer les quelques types dont
il a besoin.

Pour les squelettes, je vois pas trop à priori comment faire des
boucles génériques, faut réfléchir.

En gros, ce serait super intéressant, y'a sans doute beaucoup à
apprendre dans les autres projets, mais c'est à mon avis un peu
ambitieux pour SPIP à l'heure actuelle.

Une solution intermédiaire plus pertinente serait à mon avis de
simplifier dans le code de SPIP la création de nouveaux types
d'objets, mais sans essayer de rendre cela faisable au niveau
fonctionnel. En gros, simplifier le travail des développeurs, avant de
penser simplifier celui des fonctionnels.

Notre travail d'abstraction de données devrait déjà simplifier cela,
notamment pour créer un type d'objet "événement" ...

-Nicolas

fil · Mai 26, 2003, 9:38

En gros, simplifier le travail des développeurs, avant de penser
simplifier celui des fonctionnels.

Oui, pourquoi pas, sauf que je ne sais pas faire

Notre travail d'abstraction de données devrait déjà simplifier cela,
notamment pour créer un type d'objet "événement" ...

"Notre travail de..." : de quoi parles-tu ?

-- Fil

615beda9217b323297ed · Mai 26, 2003, 10:00

Salut Pif,

> Ci-joint, un petit "readme" associé. Si le principe vous parait
> intéressant, le patch et les fichiers supplémentaires sont dispo ici :

dans la TODO (ainsi que dans pas mal de mails dans les archives), on aborde
le problème de l'"extension" d'objets
[...]
Ce que tu proposes correspond à la solution "serialize" (mais "serialize est
peut-être un peu plus propre que ce que tu as choisi).

  Effectivement
  En fait, j'ai juste fait ça pour régler mon problème spécifique, mais
c'est clair que si on peut en faire quelque chose de propre, faut pas se
géner
  Ajouter une colonne me semblais plus lourd (dans le sens plus loin de
l'existant), et donc plus difficile à caser dans une contrib. Par
contre, puisque c'est dans les todo, je vais y regarder de plus près.

Par ailleurs, tu as accès comme tout le monde à la "version cvs des
sources", en lecture seule, cf. les explications sur
http://rezo.net/spip-dev/devel/

  Heu oui, mais de chez moi, via oreka, c'est moins évident ;-))
  En fait, c'est un export de la dernière version en date, c'est ça ?
  Donc pour y faire des modifs, il faut te filer un patch ? sous quel
format ?

À+, Pif.

Nicolas_Hoizey2 · Mai 26, 2003, 10:09

En gros, simplifier le travail des développeurs, avant de penser
simplifier celui des fonctionnels.

Oui, pourquoi pas, sauf que je ne sais pas faire

A priori, Antoine sait faire, puisqu'il avait si je ne m'abuse
commencé un boulot orienté objet, et quelques contributeurs savent
aussi ...

Notre travail d'abstraction de données devrait déjà simplifier
cela, notamment pour créer un type d'objet "événement" ...

"Notre travail de..." : de quoi parles-tu ?

Toujours la même chose, une couche intermédiaire d'accès aux données,
qui permet d'utiliser (à priori) toute base de données compatible
ANSI92. C'est en cours de finalisation, et testé avec succès sur
MySQL (compatibilité conservée, c'est le minimum ), Oracle,
SQL Server et PostgreSQL.

Cette couche est complètement objet, permet d'accéder aux données sans
taper la moindre requête SQL, et est ainsi plus facilement extensible.

Il nous reste à régler le problème sans doute assez épineux des
squelettes, mais tout 'ecrire/' est déjà opérationnel.

-Nicolas

fil · Mai 26, 2003, 10:13

> http://rezo.net/spip-dev/devel/
Heu oui, mais de chez moi, via oreka, c'est moins évident ;-))

??? N'importe quel client CVS fonctionne, tu as accès à tout l'historique
des version, etc.

  En fait, c'est un export de la dernière version en date, c'est ça ?
  Donc pour y faire des modifs, il faut te filer un patch ? sous quel
  format ?

Format 'unix patch'

-- Fil

615beda9217b323297ed · Mai 26, 2003, 11:48

bon, petit résumé de ce qui m'est passé par la tête depuis ce matin :

Pour le stockage :
- ajouter une colonne "data" de type blob aux tables rubrique, article,
forum, motclé ... dedans, on y met un tableau associatif stocké via
appel à serialize() et unserialize().

Pour l'affichage :
- ajouter une balise #DATA qui retourne un objet tableau (donc cas
particlier => effets de bord ?)
- prévoir le champ data dans tous les selects (il y a une liste des
champs à sélectionner tout le temps je crois) et le désérialiser
- ajouter un filtre get_data{nom du champ}

Pour l'édition
  comment savoir quels champs sont à mettre sur quel objet ?
=> une fonction personnalisable retournant la liste des champs à prévoir
   pour un objet donné (cette fonction doit simplement retourner une
   liste de noms). => arguments ?
+ intégrer l'équivalent des champs_suppl_* proposés ce matin dans
   le code.

amélioration : spécifier des contraintes sur ces champs ?

À vos commentaires, propositions, idées, injures, ...

À+, Pif.