[spip-dev] extension des tables

Dev
1

Idée à débattre : on pourrait ajouter UN champ extension à chaque table
d'objet (articles, auteurs, etc.) ; ce champ serait rempli avec un tableau
serializé (comme $prefs[] pour les auteurs).

On pourrait alors définir, dans un fichier inc_extension.php3, pour chaque
objet, la structure de son champ ext (quelles variables il contient, et
comment présenter ces variables dans le formulaire d'édition).

L'inconvénient de cette démarche, c'est qu'il sera un peu difficile de faire
des requêtes MySQL sur telle ou telle variable du champ ext - et qu'on ne
pourra pas l'indexer. L'avantage c'est qu'il suffit d'une modif de la base
pour étendre les objets de spip de manière confortable et "intercompatible"
(entre différentes bases spip).

(Il n'y aurait pas d'interface pour modifier le fichier inc_extension.php3,
mais des modèles à copier-coller depuis la doc.)

Je pense à un contenu du type :

<?php
    ...
    $ext['spip_articles'] = array(
                                  "nom_site" => "ligne",
                                  "url" => "ligne",
                                  "blahblah" => "textelong"
                                 );

    ...
?>

"ligne" ou "textelong" définiraient des formats d'entrée de données dans
l'interface d'édition d'articles. Ces formats pourraient être définis dans
inc_extension lui-même, ou pas (à voir).

Une balise #EXT_URL afficherait le contenu de (en gros)
unserialize(spip_articles.ext)['url']...

Commentaires ?

-- Fil

2

Idée à débattre : on pourrait ajouter UN champ extension à chaque table
d'objet (articles, auteurs, etc.) ; ce champ serait rempli avec un
tableau serializé (comme $prefs pour les auteurs).

On pourrait alors définir, dans un fichier inc_extension.php3, pour
chaque objet, la structure de son champ ext (quelles variables il
contient, et comment présenter ces variables dans le formulaire
d'édition).

Ultra-bof. Si on veut faire ce genre de choses, il vaut mieux y
réfléchir très profondément et pondre un machin bien conçu, plutôt
que de s'engluer dans la compatibilité avec une bidouille.

D'autre part il faudrait éviter, à mon goût, la multiplication
des fichiers de config, vu que ce n'est pas trop la philosophie
de SPIP (et que ça fout en l'air les upgrades).

Sur le principe le champ "ext" est une idée intéressante.

3

toujours dans la série : " je suis utilisateur pas developpeur .. et si mon
idéee ne plait pas "je la remet dans ma c .... et n'en parlons plus" comme
dit le chanteur

je vais peut etre dire une grosse betise
mais est ce qu'on pourrait inclure des valeurs numériques dans ce tableau,
et apres faire quelques calculs dessus (sommes, multiplication), et les
afficher dans un formulaire ... ca pourrait permettre de se bricoler,
associés à des tris sur mots clefs d'articles (ou nom, ou date, ou
sous-rubrique, ou etc ...), par exemple des gestion basique associative :
nbre d'adhérent, total cotisations, paye/pas paye, etc ..., total frais sur
un évenement .... bon je sais ca sort quelque peu du champ originel de SPIP,
mais spip est tellement pratique à utiliser pour le travail partagé
éditorial que l'on aimerait étendre son usage aux autres fonctions cruciales
d'une petite asso (moi c'est un club sportif)

@+
NicolasR

4

Bonjour,

Idée à débattre : on pourrait ajouter UN champ extension à chaque
table d'objet (articles, auteurs, etc.) ; ce champ serait rempli
avec un tableau serializé (comme $prefs pour les auteurs).

J'ai sur certains projets un grand besoin d'enrichir les articles,
mais surtout de disposer de plusieurs types d'articles, avec des
champs différents.
http://tincan.co.uk/?lid=322
http://doc.ez.no/article/articleview/52/1/7/

Il me semble par contre que ta solution est un poil trop technique
pour 95% des utilisateurs de SPIP ... :wink:

Donc en gros, ce serait super bien de pouvoir étendre le modèle de
données, tout en gardant une interface fonctionnelle ...

La méthode courante dans d'autres softs de gestion de contenu (dont à
priori tous les commerciaux, mais ce n'est pas le meilleurs critère),
comme vous le savez sans doute, est de laisser aux admins le soin de
créer des types de documents, et que les rédacteurs puissent ensuite
choisir quel type utiliser.

Du coup, aucune limite, mais il reste à savoir si c'est souhaitable.
On pourrait avoir un mode par défaut avec deux types, brèves et
articles, et un mode expert plus configurable.

Après, on peut faire les malins en stockant les descriptions de types
en XML ... :wink:

-Nicolas

5

ah oui
super idee, bien dans la logique de spip fourni avec un squelette de base
pour démarrer rapidement, mais ou chacun peut adapter les squelettes ensuite
à son idée

si en plus on pouvait mettre des valeurs numériques/logiques dans les
champs, et si on pouvait faire quelque opération standard dans les cadre des
boucles (sommes entre champs, multiplication entre champs ou avec une
variable, et/ou, etc ...), alors les possibilitées d'adaptation deviennent
vastes .. a partir d'une seule version spip de référence

s'agit pas de faire un php bis mais de pouvoir manipuler un minimum des
données saisies dans spip en profitant du tronc commun de travail qui peut
representer un certain investissement temps (mise en forme, saisies
rédacteurs/passes, pédagogie aupres des utiilisateurs, maintenance, etc ...)

@+
NicolasR

6

[...]

si en plus on pouvait mettre des valeurs numériques/logiques dans les
champs, et si on pouvait faire quelque opération standard dans les cadre des
boucles (sommes entre champs, multiplication entre champs ou avec une
variable, et/ou, etc ...), alors les possibilitées d'adaptation deviennent
vastes .. a partir d'une seule version spip de référence

Il est clair que de pouvoir adapter les tables et leurs compositions en sous
table c'est la porte ouverte à des usages détournés de spip : du site à
l'application en ligne...
Moi je ne suis pas contre.

s'agit pas de faire un php bis mais de pouvoir manipuler un minimum des
données saisies dans spip en profitant du tronc commun de travail qui peut
representer un certain investissement temps (mise en forme, saisies
rédacteurs/passes, pédagogie aupres des utiilisateurs, maintenance, etc ...)

On en revient à la création de squelettes pour la partie backoffice de spip.
Si spip est entièrement programmé en spip, ça devient un vrai langage.

7

bon
faut peut etre pas perdre de vue la volonté d'etre originelle de spip (qui
fait son succès) = une relative accessibilité au commun des mortels ... et
ne pas chercher à réinventer une sur-couche complète de php, qui est
toujours dispo pour qui veut des fonctions pointues

plis que de nouvelles fonctions c'est l'acces et l'adaptation des données,
sans avoir à toucher aux scripts de base de spip, qui serait utile

si déjà spip permettait de paramétrer certains champs, et de les rendre
"manipulables" par des fonctions php externes au code de base de spip alors
apparait l'efficace notion de plug-in (cf Xpress, 4D, etc ...) :
- un seul tronc commun (spip) tenu à jour dans la ligne du projet
- des bibliothèque de scripts php "compatibles", pour diverses adaptations
spécifiques, à assumer par qui en a besoin, en parallèle et en suivant les
spécifications du tronc commun

@+
nicolas

8

ReBonjour,

(si ça t'embêtes pas de répondre en fin de message ça m'arrange et je ne
suis pas le seul je pense :wink: ).

*******************************

Il est clair que de pouvoir adapter les tables et leurs compositions en sous
table c'est la porte ouverte à des usages détournés de spip : du site à
l'application en ligne...

........

On en revient à la création de squelettes pour la partie backoffice de spip.
Si spip est entièrement programmé en spip, ça devient un vrai langage.

****************************
faut peut etre pas perdre de vue la volonté d'etre originelle de spip (qui
fait son succès) = une relative accessibilité au commun des mortels ... et
ne pas chercher à réinventer une sur-couche complète de php, qui est
toujours dispo pour qui veut des fonctions pointues

Les squelettes de la partie public sont ils si difficiles à mettre en oeuvre
par le commun des mortels?
Le principe serait le même : des squelettes par défaut pour un spip par
défaut mais adaptable à l'utilisation que l'on fait du système.
Je ne me sens pas éloigné du commun des mortels, je ne suis
(malheureusement?) pas développeur.

[...]

si déjà spip permettait de paramétrer certains champs, et de les rendre
"manipulables" par des fonctions php externes au code de base de spip alors
apparait l'efficace notion de plug-in (cf Xpress, 4D, etc ...) :
- un seul tronc commun (spip) tenu à jour dans la ligne du projet

C'est une demande de bibliotheque de fonctions, pour les intégrer de façon
homogène il faut pouvoir adapter le back office et pour adapter le back
office à chaque usage quoi de mieux que des squelettes en spip?
[...]
@+

9

Hello,

Les squelettes de la partie public sont ils si difficiles à mettre
en oeuvre par le commun des mortels?

Apparemment, oui. Il suffit de voir le nombre de sites qui gardent le
look de base alors qu'il a été conçu volontairement "moche" pour
inciter les gens à en changer ... :wink:

Le principe serait le même : des squelettes par défaut pour un spip
par défaut mais adaptable à l'utilisation que l'on fait du système.

Utopique.

Avec les squelettes, côté public, on fait que de la sélection et et de
l'affichage d'infos.

Côté privé, il y a des créations et mises à jour de données, et un
nombre important de règles de gestion à respecter.

-Nicolas

10

oui .... l'intérêt serait pour chacun de pouvoir utiliser le savoir-faire
(et la doc) acquis dans la partie publique

je suppose que la difficulté pour l'équipe de développement, si tous est
adaptable, doit être d'assurer un fonctionnement et un upgrade fiable,
malgré de multiples cas de figures possibles ... faudrait peut être
clairement séparer les éléments fixes et stables du projet (le code et
l'interface de base ... fiables et débuggés collectivement) des éléments
modulables (maintenance à assurer par le seuls intéressés sans surcharger le
projet commun)

@+
Nicolas

11

Hello,

Salut,

Les squelettes de la partie public sont ils si difficiles à mettre
en oeuvre par le commun des mortels?

Apparemment, oui. Il suffit de voir le nombre de sites qui gardent le
look de base alors qu'il a été conçu volontairement "moche" pour
inciter les gens à en changer ... :wink:

Tss tss trop facile ça :slight_smile:
T'as vu le nombre de personnes qui utilisent des spip?
Il y a Spip partout de nos jours donc évidemment dans le lot il y a des gens
qui ne connaissent rien du tout au html ok mais c'est pas une majorité.

Le principe serait le même : des squelettes par défaut pour un spip
par défaut mais adaptable à l'utilisation que l'on fait du système.

Utopique.

J'aime les utopies, ce sont les seules choses qui puissent nous faire
accepter la réalité :wink:

Avec les squelettes, côté public, on fait que de la sélection et et de
l'affichage d'infos.

Ok + formulaires d'inscription + scripts pour modifier article+ ...

Côté privé, il y a des créations et mises à jour de données, et un
nombre important de règles de gestion à respecter.

Il y a des formulaires pour remplir une base dans laquelle il y a des tables
que tu envisages de transformer en conteneurs de sous tables :slight_smile:
Et il y a des objets de navigation.
Chsui pas programmeur moi donc je n'y connais rien et je ne le ferais pas
mais je ne vois pas en quoi ce n'est pas spipable. Tu peux sûrement me
l'expliquer (si besoin en privé si ça doit gaver la liste... ).

12

Idée à débattre : on pourrait ajouter UN champ extension à chaque table
d'objet (articles, auteurs, etc.) ;

<snip>

Commentaires ?

Et ça sert à quoi d'avoir un SGBDR ? Pourquoi ne pas plutot faire un truc du
style (désolé c'est de la syntaxe pgsql) :

CREATE TABLE SPIP_EXTENDEDATTRIBUTES(
/* id technique */
ID INTEGER NOT NULL DEFAULT nextval('sequence_eattr'),

/* Nom de l'objet concerne : article, breve, auteur ... */
OBJET VARCHAR NOT NULL,

/* ID de la ligne concernée (valeur de l'id_article par ex.) */
OBJID INTEGER NOT NULL,

/* nom de la variable ex "nom du site" */
NOMVAR VARCHAR NOT NULL,

/* type de la variable ex "ligne" */
TYPVAR VARCHAR NOT NULL,

/* valeur de la variable "http://www.uzine.net" */
VALEUR TEXT NOT NULL,

/* Ordonnancement nom du site=1, url=2, blahblah=3 ...*/
ORDRE INTEGER NOT NULL
);

Ce qui donne par exemple :
aegir=# select * from SPIP_EXTENDEDATTRIBUTES;
id | objet | objid | nomvar | typvar | valeur | ordre

13

Ultra-bof. Si on veut faire ce genre de choses, il vaut mieux y
réfléchir très profondément et pondre un machin bien conçu, plutôt
que de s'engluer dans la compatibilité avec une bidouille.
...
Sur le principe le champ "ext" est une idée intéressante.

En gros il y a deux possibilités : l'une, plus propre, consisterait à
ajouter les champs extension1, extension2, etc. au fur et à mesure qu'ils
sont demandés, depuis l'espace privé (auth ftp obligatoire) ; l'autre, qui
ne nécessite pas de toucher à la structure de la base de données à chaque
ajout d'un champ, est de faire un serialize() dans un seul champ extension.

Ensuite, se pose la question de la configuration de chaque extension
(pourrait être : un nom, un commentaire, un type dans une liste limitative),
et les bricoles autour (critères, balises, sauvegarde...)

-- Fil

14

Dans le prolongement de cette idée de nouveau champs, voici un petit
draft de ce qui me trotte dans la tête... Notez que j'envoie ce mail
seulement pour vider mon cerveau avant d'oublier l'idée, rien de plus !

C'est une idée un peu fumeuse, mais qui peut donner une piste pour
SPIP 2.0 (ou 3.0 ou 4.0 parce que moi j'en ai pas besoin). Ce que je
cherche c'est une solution pour un SPIP multilingue. Cela impose
plusieurs langue par article/rubrique/etc... et donc une notion de
"version" de ces élements. J'en profite donc pour combiner les deux :
multi-langue et multi-version.

- Pour chaque article avoir deux champs en plus : "langue"
  (int) et "version" (longint).

- Ce qui implique qu'id_article ne peut plus être la clef (unique) de
  la table spip_article. Il faut rajouter à la place une clef
  sid_article (system ID). On pourrait alors avoir plusieurs articles
  avec le même id_article, ce qui permet plusieurs langues et plusieurs
  versions par article.

- Idem avec les autres objets (rubriques, breve, etc).

- Avoir une table spip_langues = id_langue, description, priorite,
  code_locales, charset, drapeau, etc., où "priorite" permettrait
  de gérer l'absence éventuelle de content_negociation (comme
  le fait Apache avec son LanguagePriority).

Idées en vrac :
- Permettre plusieurs versions d'un article = versions passées + version
  actuelle - une seule version par langue pourrait être validée +
  versions futures en cours d'écriture
- Avoir des critères {langue=...}, {langue_preferee} sur les objets
  (avec "languepreferee" issue d'un content-negociation)
- Avoir une boucle (LANGUES){id_article} avec des balises
  du genre #URL_ARTICLE_LANGUE, #URL_ARTICLE_VERSION, #DRAPEAU, etc
- La conversion d'une base SPIP 1.4 vers ce nouveau système se ferait
  en créeant sur la table spip_article les champs "langue" (fixée par
  l'admin lors de la conversion), "version" (=1 ou =200211201008, date
  de la conversion) et sid_article (copie des id_article au moment de
  la conversion).

Attention : pour ceux qui s'écrient "génial !" devant leur clavier en
lisant ce message : cela modifierait TRES lourdement les requetes à
faire sur la base, et donc BEAUCOUP le code de SPIP.

a+

15

- Ce qui implique qu'id_article ne peut plus être la clef (unique) de
  la table spip_article. Il faut rajouter à la place une clef
  sid_article (system ID). On pourrait alors avoir plusieurs articles
  avec le même id_article, ce qui permet plusieurs langues et plusieurs
  versions par article.

Tu peux voir les choses autrement : ajouter un champ "bozo", un "bozo" étant
une collection de différentes versions (langues, dates) d'un même article.
Ensuite, quand tu veux afficher un "bozo", tu affiches l'"article spip" de
ce "bozo" qui correspond le mieux au client ou à l'état de préparation du
papier, etc.

Ah mais tiens ! Ca existe déjà, le "bozo"... ça s'appelle une "rubrique" ou
un "mot-clé" !

-- Fil

16

Je connais ça, mais :
- si je mets des références entre article ou rubrique du genre [->133]
  c'est pas marrant de les changer partout quand l'article change (et
  y'a rien de pire que des 404 sur un site). Je sais que pour éviter le
  validateur peut faire des copier-coller de contenu, mais c'est pas
  marrant (sans parler des documents liés qu'il faut transférer)
- et puis comme dirait Antoine les mot-clés ne sont pas censés gérer ce
  genre de chose (ce ne sont pas des "bozos" :wink:

Donc voilà, fin de mon idée :wink:

a+

17

- si je mets des références entre article ou rubrique du genre [->133]

tu mettrais [->mot24], évidemment.

- et puis comme dirait Antoine les mot-clés ne sont pas censés gérer ce
  genre de chose (ce ne sont pas des "bozos" :wink:

Ce que je voulais dire, c'est qu'il n'est pas nécessaire de changer le
structure profonde de spip pour faire ce que tu dis ; il suffit d'exploiter
un certain type de mots-clés, qu'on peut mettre dans une table spip_bozo si
tu veux... :wink:

-- Fil