[SPIP Zone] Création de tables , plugin , pipelines...

Archives Zone
1

Bonjour,

Souhaitant améliorer, optimiser et être bien dans les "conventions" et surtout nettoyer le code "quick and dirty" :

Y a t il quelque part (je n'ai point trouvé) des infos/documentations/wiki sur les différences entre (et les fonctionnalités de) :

- tables_auxiliaires
- tables_interfaces
- tables_principales
- tables_des_tables
- tables_jointures
- exceptions_des_tables
- tables_date
- ... j'en ai oublié ?

Les modalités pour utiliser les pipelines associés :
- declarer_tables_auxiliaires
- declarer_tables_interfaces
- declarer_tables_principales

--chryjs

2

Bonjour

Tu trouveras une (petite) partie de ton bonheur ici
http://doc.spip.org/@La-base-de-donnees,4391 et ici
http://doc.spip.org/@Les-points-d-entree-pipelines

Km

3

cam.lafit@azerttyu.net a écrit :

Bonjour

Tu trouveras une (petite) partie de ton bonheur ici
http://doc.spip.org/@La-base-de-donnees,4391 et ici
http://doc.spip.org/@Les-points-d-entree-pipelines

Km

Merci !

Oui c'est ce que j'avais trouvé, d'où mon message. (mea culpa j'aurai du le préciser). Rien sur
- tables_auxiliaires
- tables_interfaces (non mentionné)
[tables_principales]
- tables_sequences (que je découvre)
- tables_mime (idem)
[tables_des_tables]
[tables_des_jointures]
[exceptions_des_tables]
- exceptions_des_jointures (diff avec la précédente ?)
- tables_date....

Quant à la seconde...
Ca n'éclaire guère sur ce qui doit ou ne doit pas être fait dans les pipelines en question :((

Aïe

4

Oui c'est ce que j'avais trouvé, d'où mon message. (mea culpa j'aurai du le
préciser). Rien sur [..]

Dans ce cas n'hésite pas à compléter le wiki dès que tu auras réussi à
soutirer les informations.
:slight_smile:

5

Accés SPIP aux tables non-SPIP et jointures - SPIP-Contrib est pas trop mal.

Pierre

chryjs wrote:

Bonjour,

Souhaitant améliorer, optimiser et être bien dans les "conventions" et
surtout nettoyer le code "quick and dirty" :

Y a t il quelque part (je n'ai point trouvé) des
infos/documentations/wiki sur les différences entre (et les
fonctionnalités de) :

- tables_auxiliaires
- tables_interfaces
- tables_principales
- tables_des_tables
- tables_jointures
- exceptions_des_tables
- tables_date
- ... j'en ai oublié ?

Les modalités pour utiliser les pipelines associés :
- declarer_tables_auxiliaires
- declarer_tables_interfaces
- declarer_tables_principales

--chryjs

6

voir aussi:
http://news.gmane.org/gmane.comp.web.spip.english

chryjs wrote:

Bonjour,

Souhaitant améliorer, optimiser et être bien dans les "conventions" et
surtout nettoyer le code "quick and dirty" :

Y a t il quelque part (je n'ai point trouvé) des
infos/documentations/wiki sur les différences entre (et les
fonctionnalités de) :

- tables_auxiliaires
- tables_interfaces
- tables_principales
- tables_des_tables
- tables_jointures
- exceptions_des_tables
- tables_date
- ... j'en ai oublié ?

Les modalités pour utiliser les pipelines associés :
- declarer_tables_auxiliaires
- declarer_tables_interfaces
- declarer_tables_principales

--chryjs

7

oups, je voulais dire:
http://article.gmane.org/gmane.comp.web.spip.english/1855

Pierre

chryjs wrote:

Bonjour,

Souhaitant améliorer, optimiser et être bien dans les "conventions" et
surtout nettoyer le code "quick and dirty" :

Y a t il quelque part (je n'ai point trouvé) des
infos/documentations/wiki sur les différences entre (et les
fonctionnalités de) :

- tables_auxiliaires
- tables_interfaces
- tables_principales
- tables_des_tables
- tables_jointures
- exceptions_des_tables
- tables_date
- ... j'en ai oublié ?

Les modalités pour utiliser les pipelines associés :
- declarer_tables_auxiliaires
- declarer_tables_interfaces
- declarer_tables_principales

--chryjs

8

chryjs a écrit :

cam.lafit@azerttyu.net a écrit :

Bonjour

Tu trouveras une (petite) partie de ton bonheur ici
http://doc.spip.org/@La-base-de-donnees,4391 et ici
http://doc.spip.org/@Les-points-d-entree-pipelines

Ca n'éclaire guère sur ce qui doit ou ne doit pas être fait dans les pipelines en question :((

Ben oui. C'est deux pages sont les *endroits* où les informations que tu cherches DOIVENT se trouver. Mais comme on le voit, ça ne signifie pas qu'elles y sont déjà... malheureusement.

C'est un wiki. Chaque personne connaissant une infime part d'information peut la rajouter à ces pages si elle en a le temps (et oui ça prend du temps la doc).

Je pense notamment à la page sur les pipelines, que j'ai remis à jour il n'y a pas longtemps, mais qu'il faut maintenant remplir. Le problème c'est que les pipelines ne sont pas connus par tant de monde que ça. Et dans un pipeline il ne faut pas juste dire brièvement où il se trouve, il faut surtout indiquer les paramètres !!

Déjà, dans un premier temps, ça serait bien que les *nouveaux* pipelines créés soient documentés immédiatement par celui qui les a créé.
Sur SPIP.net, il y a un article dans une rubrique sur la contribution au développement, qui explique des recommandations de codage. Et dedans il est bien expliqué qu'il faut COMMENTER le code. Alors c'est très bien fait pour les fonctions et doc.spip.org le récupère. Mais ce n'est pas fait pour les pipelines, puisque ce ne sont PAS des fonctions.
Il faut donc que le codeur qui en crée un aille le documenter sur le site lorsqu'il le crée.

Oui, c'est un peu chiant pour l'instant.

On pourrait imaginer qu'entre chaque ligne déclarant un pipeline dans le fichier inc_version.php, il y ait une description dans le même style que pour les fonctions. Du coup, doc.spip.org pourrait récupérer la doc des pipelines automagiquement aussi.

En attendant, wiki...

--
RastaPopoulos

9

chryjs a écrit :

cam.lafit@azerttyu.net a écrit :

Bonjour

Tu trouveras une (petite) partie de ton bonheur ici
http://doc.spip.org/@La-base-de-donnees,4391 et ici
http://doc.spip.org/@Les-points-d-entree-pipelines

Et regardes ici :

pour savoir utiliser les nouveaux pipelines de déclaration.

--
RastaPopoulos

10

Pierre Andrews a écrit :

oups, je voulais dire:
http://article.gmane.org/gmane.comp.web.spip.english/1855

Pierre

Merci de ton aide ! Je ne les avais pas trouvé ceux là :frowning:

Mais il est dépassé (outdated) car ne respecte pas la nouvelle procédure avec les pipelines.

La question reste ouverte.

Pour SPIP 2.0 il y a une nouvelle interface définie depuis juillet je crois , cf :

http://trac.rezo.net/trac/spip/changeset/11997

Malheureusement absolument pas documenté ni sur les contraintes ni sur les éventuelles recommandations pour faire un beau plugin "certifié" SPIP tout neuf qui va bien appelé 2.0 .

Donc le sujet reste entier...

--chryjs

11

Regarde les plugin agenda et acces restreint qui utilisent l'interface certifiée 2.0 :stuck_out_tongue:

En 2.0 mots :
avant
chaque plugin definissait ses tables dans la globale en prenant soin d'inclure avant le base/serial pour avoir la definition de base et passer après. Résultat tout le monde incluait base/serial, et les tables etaient definies bien souvent inutilement.
apres
le core appelle base/serial, base/aux, et public/interfaces quand il en a besoin. A ce moment, les pipelines respectifs declarer_tables_principales, declarer_tables_auxiliaires et declarer_tables_interfaces sont appelés, ce qui permet a chaque plugin de faire ses definitions.

On peut ainsi optimiser la perfo de l'ensemble en ne chargeant que ce qui est necessaire (souvent les interfaces suffisent)

L'ancienne méthode fonctionne encore, mais est maintenant déconseillée.
Cédric

Le 9 oct. 08 à 19:41, chryjs a écrit :

Pierre Andrews a écrit :

oups, je voulais dire:
http://article.gmane.org/gmane.comp.web.spip.english/1855
Pierre

Merci de ton aide ! Je ne les avais pas trouvé ceux là :frowning:

Mais il est dépassé (outdated) car ne respecte pas la nouvelle procédure avec les pipelines.

La question reste ouverte.

Pour SPIP 2.0 il y a une nouvelle interface définie depuis juillet je crois , cf :

http://trac.rezo.net/trac/spip/changeset/11997

Malheureusement absolument pas documenté ni sur les contraintes ni sur les éventuelles recommandations pour faire un beau plugin "certifié" SPIP tout neuf qui va bien appelé 2.0 .

Donc le sujet reste entier...

--chryjs
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

12

cedric.morin@yterium.com a écrit :

Regarde les plugin agenda et acces restreint qui utilisent l'interface certifiée 2.0 :stuck_out_tongue:

Super ! c'est ce que j'avais commencé à faire et avec ces deux là en plus. :-)) Etrange non ? :slight_smile:

En reprenant l'exemple avec Agenda, lors de l'installation (du plugin). A quel moment sont effectivement créées par SPIP les tables annoncées dans les pipelines ? Lors de l'appel à la fonction d'installation déclarée dans plugin.xml ? Si oui avant ou après l'appel de test ? Sinon heu à partir de quel moment peut on les utiliser (dans le code) ?

Quelle différence/ nécessité y a til entre :
* dans _declarer_tables_interfaces
  $interface['table_date']['evenements'] = 'date_debut';
* dans _declarer_tables_auxiliaires
  global $table_date;
  $table_date['evenements'] = 'date_debut';

La déclaration dans interfaces ne suffit pas ?

En 2.0 mots :
avant
chaque plugin definissait ses tables dans la globale en prenant soin d'inclure avant le base/serial pour avoir la definition de base et passer après. Résultat tout le monde incluait base/serial, et les tables etaient definies bien souvent inutilement.

hummm le passé c'est dépassé...

apres
le core appelle base/serial, base/aux, et public/interfaces quand il en a besoin. A ce moment, les pipelines respectifs declarer_tables_principales, declarer_tables_auxiliaires et declarer_tables_interfaces sont appelés, ce qui permet a chaque plugin de faire ses definitions.

Certes mais avec quelles contraintes ? les exemples ne suffisent pas pour en déduire une recommandation ou des règles éventuelles. :frowning:

On peut ainsi optimiser la perfo de l'ensemble en ne chargeant que ce qui est necessaire (souvent les interfaces suffisent)

J'avoue que j'ai par exemple encore bien du mal à distinguer auxiliaires de principales. Surement parce que je suis un peu "bouché" :-]

Peut être que la réponse ci-dessus résoud la question :
quel est le meilleur endroit pour déclarer une table qui répond aux contraintes :
- ne sert jamais dans une BOUCLE
- contient des données qui servent de jointures pour l'interface privée ou pour calculer une balise dynamique
- doit être sauvegardée avec les autres tables (rapport aux données)

L'ancienne méthode fonctionne encore, mais est maintenant déconseillée.

justement d'où ma demande pour écrire/ corriger plugins concernés pour SPIP 2.0. Je vais éviter d'écrire du code déjà obsolète :slight_smile:

Cédric

Autres petits points qui restent à éclaircir
* quelles différences entre :
- exceptions_des_tables
- exceptions_des_jointures

* Peux tu confirmer que tables_interfaces (que l'on récupère en paramètre dans le pipeline _declarer_tables_interfaces) est un tableau qui contient entre autres :
  - tables_des_tables
  - table_des_traitements
  - tables_xxxx (toutes ?)

Merci !!!!

--Chryjs

13

Le 9 oct. 08 à 22:23, chryjs a écrit :

cedric.morin@yterium.com a écrit :

Regarde les plugin agenda et acces restreint qui utilisent l'interface certifiée 2.0 :stuck_out_tongue:

Super ! c'est ce que j'avais commencé à faire et avec ces deux là en plus. :-)) Etrange non ? :slight_smile:

En reprenant l'exemple avec Agenda, lors de l'installation (du plugin). A quel moment sont effectivement créées par SPIP les tables annoncées dans les pipelines ? Lors de l'appel à la fonction d'installation déclarée dans plugin.xml ? Si oui avant ou après l'appel de test ? Sinon heu à partir de quel moment peut on les utiliser (dans le code) ?

il faut implementer <install>..</install>
et les fonctions upgrade/vider qui vont dedans.

Quelle différence/ nécessité y a til entre :
* dans _declarer_tables_interfaces
  $interface['table_date']['evenements'] = 'date_debut';

ca c'est bien

* dans _declarer_tables_auxiliaires
  global $table_date;
  $table_date['evenements'] = 'date_debut';

ca c'est du vieux code que j'ai oublié d'enlever !

La déclaration dans interfaces ne suffit pas ?

En 2.0 mots :
avant
chaque plugin definissait ses tables dans la globale en prenant soin d'inclure avant le base/serial pour avoir la definition de base et passer après. Résultat tout le monde incluait base/serial, et les tables etaient definies bien souvent inutilement.

hummm le passé c'est dépassé...

apres
le core appelle base/serial, base/aux, et public/interfaces quand il en a besoin. A ce moment, les pipelines respectifs declarer_tables_principales, declarer_tables_auxiliaires et declarer_tables_interfaces sont appelés, ce qui permet a chaque plugin de faire ses definitions.

Certes mais avec quelles contraintes ? les exemples ne suffisent pas pour en déduire une recommandation ou des règles éventuelles. :frowning:

On peut ainsi optimiser la perfo de l'ensemble en ne chargeant que ce qui est necessaire (souvent les interfaces suffisent)

J'avoue que j'ai par exemple encore bien du mal à distinguer auxiliaires de principales. Surement parce que je suis un peu "bouché" :-]

Peut être que la réponse ci-dessus résoud la question :
quel est le meilleur endroit pour déclarer une table qui répond aux contraintes :
- ne sert jamais dans une BOUCLE
- contient des données qui servent de jointures pour l'interface privée ou pour calculer une balise dynamique
- doit être sauvegardée avec les autres tables (rapport aux données)

La regle generale c'est :
donnees editoriales utilisee dans les boucles : tables principales
donnees techniques de jointure ou autre : tables_auxiliaires

L'ancienne méthode fonctionne encore, mais est maintenant déconseillée.

justement d'où ma demande pour écrire/ corriger plugins concernés pour SPIP 2.0. Je vais éviter d'écrire du code déjà obsolète :slight_smile:

Cédric

Autres petits points qui restent à éclaircir
* quelles différences entre :
- exceptions_des_tables
- exceptions_des_jointures

heu...

* Peux tu confirmer que tables_interfaces (que l'on récupère en paramètre dans le pipeline _declarer_tables_interfaces) est un tableau qui contient entre autres :
  - tables_des_tables
  - table_des_traitements
  - tables_xxxx (toutes ?)

oui

Merci !!!!

--Chryjs
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

14

A partir des récentes et précieuses contributions
de Pierre Andrew et Cedric je commence à faire le point :
http://www.spip-contrib.net/Complements-techniques-pour-l

JLuc

15

cam.lafit@azerttyu.net a écrit :

Oui c'est ce que j'avais trouvé, d'où mon message. (mea culpa j'aurai du le
préciser). Rien sur [..]

Dans ce cas n'hésite pas à compléter le wiki dès que tu auras réussi à
soutirer les informations.
:slight_smile:

Je vais tenter dès que j'aurai validé que ce que j'ai codé tiens la route. Pour le moment ça semble passer les premiers tests... mais... on n'est à l'abri de rien encore :slight_smile:

16

S'lt

A partir des récentes et précieuses contributions
de Pierre Andrew et Cedric je commence à faire le point :
Compléments techniques pour l’ajout de tables dans SPIP

Bonne nouvelle tout ça

ça serait genial de mettre en forme pour l'intégrer dans le wiki technique
doc.spip.org (bien sur :slight_smile:

17

cam.lafit@azerttyu.net a écrit :

S'lt

A partir des récentes et précieuses contributions
de Pierre Andrew et Cedric je commence à faire le point :
Compléments techniques pour l’ajout de tables dans SPIP

Bonne nouvelle tout ça

ça serait genial de mettre en forme pour l'intégrer dans le wiki technique
doc.spip.org (bien sur :slight_smile:

oui

faut créer une nouvelle page pour ça ?
(j'hésitais)
JL

18

JLuc a écrit :

faut créer une nouvelle page pour ça ?
(j'hésitais)
JL

Normalement non, il y a une page dédié à l'API de la base de donnée.

http://doc.spip.org/@La-base-de-donnees,4391

--
RastaPopoulos

19

En résumé
---------------

1) Déclaration des tables

- La déclaration des tables passent via ces trois fonctions :
"prefixplugin_declarer_tables_interfaces($interface)",
"prefixplugin_declarer_tables_principales($tables_principales)",
"prefixplugin_declarer_tables_auxiliaires($tables_auxiliaires)"
UNIQUEMENT. Correct ?

- "prefixplugin_declarer_tables_interfaces($interface)" Sert à donner
le nom des boucles aux tables et à déclarer les jointures et les
traitements par défaut sur les champs des tables. Correct ?

- Dans cette fonction, la ligne
"$interface['table_des_tables']['truc_machin']='trumachin';" donnera
une boucle <...(TRUCMACHIN)...>.Correct ?

-Toujours dans cette fonction, la ligne
"$interface['tables_jointures']['spip_bazar'][] = 'bazar_cathedral';"
lie la table de jointure 'bazar_cathedral' à la table 'spip_bazar'.
Correct ?

- Toujours dans cette fonction, la ligne
"$interface['exceptions_des_tables']['blizzar']['nuage']=array('mouton','poil');"
déclare que dans la table 'blizzar', le champ 'nuage' fait référence
au champ 'poil' de la table 'mouton'. Correct ?

- Dans le cas ci dessus, la table 'mouton' DOIT être déclarer en table
de jointure avant / après cette ligne, dans cette fonction. Correct ?

- Toujours dans cette fonction, la ligne
"$interface['table_des_traitements']['PLUIE'][]= 'mouille(%s)';"
Appliquera la fonction php "mouille" à toutes les balises "#PLUIE".
Correct ?

- Est-ce que cette notation fonctionnera :
"$interface['table_des_traitements']['PLUIE'][]=
'rafraichir(tombe(mouille(%s)))';" ?

- Dans le cas ci-dessus, sur n'importe quel table ?

- Toujours dans cette fonction, que ferais
"$interface['table_date']['concert'] = 'date_ouverture';" ?

- "prefixplugin_declarer_tables_principales($tables_principales)" sert
pour déclarer les tables principales, celles qui contiendront
l'information à afficher, et notamment celles sur lesquelles on fera
les boucles. Correcte ?

- "prefixplugin_declarer_tables_auxiliaires($tables_auxiliaires)" sert
à déclarer les tables de jointure. Correct ?

2) Installation des bases

- Est-ce que "prefixplugin_install()" est encore nécessaire /
d'actualité dans SPIP 2.0 ?

- Sinon, est-ce que "prefixplugin_vider_tables()" et "prefixplugin
_upgrade()" du fichier php renseigné dans le "<install>" suffisent à
installer/désinstaller les tables ?

- La fonction "prefixplugin_vider_tables()" contient le code php de
suppression des tables du plugin. Correct ?

- La fonction "prefixplugin _upgrade()" contient le code de mise à
jour ET d'installation des tables du plugin. Correct ?

3) Autre choses ?

Merci bien

Seb
--
Denooz Sébastien. Crowfoot pour les intimes...
Jabber : crowfoot@jabber.fr
Web : http://www.lattirail.org

Hacking For Freedom
Fellowship of F.S.F.E.
http://www.fsfe.org

20

Denooz Sébastien a écrit :

En résumé
---------------

1) Déclaration des tables

- La déclaration des tables passent via ces trois fonctions :
"prefixplugin_declarer_tables_interfaces($interface)",
"prefixplugin_declarer_tables_principales($tables_principales)",
"prefixplugin_declarer_tables_auxiliaires($tables_auxiliaires)"
UNIQUEMENT. Correct ?

Non les pipelines (qui n'ont pas forcément ces noms de fonctions, on donne le nom qu'on veut) ne sont pas la seule manière de déclarer
on peut toujours faire comme avant, c'est juste que c'est plus facile et plus standard.

Il vaudrait mieux dire "s'insérer dans le pipeline machin_truc" plutôt que donner des noms de fonctions comme tu l'as fait, qui donne à penser qu'on doit forcément nommer comme ça et que ça suffit. En effet, si tu crées ces fonctions avec le nom que tu as donné, mais que tu ne te déclares pas dans plugin.xml, ça sert à rien non plus.
Donc il vaut mieux être plus général.

Sinon le reste, c'est cool, ça va en éclaircir plus d'un !