meilleure pratique pour gestion de données externes ?

Hello la liste,
voilà maintenant plusieurs années que j’utilise SPIP sur un (gros) site, mais sans plugins ni hacks.
Du coup, je découvre un peu les fonctionnalités avancées apportées par le système de plugins, et j’aurais 2 ou 3 petites questions. J’ai RTFMé, cherché dans les archives (user et zone), mais c’est encore un peu confus.

Merci à tou(te)s pour ce formidable outil qui fonctionne si bien que je n’avais jusqu’ici pas eu a venir demander conseil à la liste.

Dans le cadre d’un nouveau projet de site, j’aurais besoin d’utiliser de nouveaux champs de saisie dans l’interface de saisie des articles.
En effet, c’est un cas assez classique, j’ai besoin d’identifier certains champs particulier puisqu’il s’agit de fiches descriptives et non d’articles au sens classique du terme. Ces champs peuvent être de type text, textarea, select, etc. Ici, il s’agit de fiches décrivant des logiciels (sur lesquelles nous souhaitons ajouter des champs comme « contexte d’utilisation », « interopérabilité »,etc)

Bon, je me dis que je vais utiliser les champs extras.
Ah oui mais non : on me susurre à l’oreille que les champs extras :

  • pourraient ne plus être supportés par la V2 au profit d’une interface permettant de définir ces propres champs (qq1 peut confirmer ?)
  • sont en fait des données serialisées, et donc non indéxées/cherchables

Donc, je cherche du côté des contribs et des plugins. J’en profite pour découvrir que (youpimerci !) on peut directement attaquer des tables « non spip » directement dans les squelettes. C’est top, mais ça ne résoud que la motiée de mon probleme : comment donner à mes utilisateurs la possibilité de peupler ces tables ?
Je trouve donc assez rapidement le plugin Form&Tables, j’installe et je teste : ça semble assez bien correspondre à mon besoin, mais il me semble « déconnecté » de la table auteurs. Ainsi, contrairement aux articles, si je crée un formulaire qui va bien avec forms&tables et qu’un de mes auteurs authentifiés le remplit, il sera bien stocké dans les tables spip_forms* mais je perds alors la possibilité pour mes autres rédacteurs d’accéder au contenu via l’admin (et par exemple d’utiliser le forum interne, ou les notions de statuts de publications réservées aux articles).
Pourtant, bravo à l’auteur, c’est un plugin qui roxx bien :slight_smile:

Une autre solution, c’est de faire un plugin qui me rajoute ces champs dans l’interface de saisie admin (j’aurais donc le corps de la fiche composée de la description des softs, et le plugin me permettrait d’ajouter des les champs de formulaires d’une table « extension_articles », par exemple, et d’y manipuler « mes » champs)…
Ca me parait faisable (même s’il va me falloir apprendre à créer des plugins), mais évidemment, c’est pas super propre.

J’ai bien repéré plusieurs threads dans les archives, mais certains se contredisent (j’ai peut être mal cherché) et je voudrais tant qu’à faire partir du bon pied.
Donc (et oui, tout ça pour ça !) : quel est selon vous la meilleure solution, en terme de perennité et d’interopérabilité, pour gérer l’ajout de champs ? (que l’on souhaite indexables, modifiables, voir avec les possibilités de révisions)

merci
pyg

On Fri, 2007-05-25 at 15:12 +0200, framalistes wrote:

Bon, je me dis que je vais utiliser les champs extras.
Ah oui mais non : on me susurre à l'oreille que les champs extras :
- pourraient ne plus être supportés par la V2 au profit d'une
interface permettant de définir ces propres champs (qq1 peut
confirmer ?)
- sont en fait des données serialisées, et donc non
indéxées/cherchables

tout à fait

Donc, je cherche du côté des contribs et des plugins. J'en profite
pour découvrir que (youpimerci !) on peut directement attaquer des
tables "non spip" directement dans les squelettes. C'est top, mais ça
ne résoud que la motiée de mon probleme : comment donner à mes
utilisateurs la possibilité de peupler ces tables ?

En modifiant l'interface privée pour faire apparaitre ces champs.
Pour ça, il "suffit" de spécifier un "pipeline" qui va s'insérer "ou il
faut" dans le formulaire pour ajouter les zones de saisie.
Pour la partie écriture, il faudra surcharger le code php par défaut
pour faire tes écritures, puis repasser la main à l'original.

Je l'ai fait pour les auteurs dans un cas donné, et ça marche pas mal.

Sinon, il existe aussi une contrib qui permet de préciser des colonnes
supplémentaires dans une table spip et de les configurer comme des
champs extra, donc de les faire apparaitre dans l'interface privée.
Je ne l'ai jamais essayé, donc je ne sais pas s'il est parfait, ni s'il
marche encore avec les dernières versions de spip, mais ça peu valoir le
coup d'essayer avant de se lancer dans son propre plugin.

--
À+, Pif.

En modifiant l'interface privée pour faire apparaitre ces champs.
Pour ça, il "suffit" de spécifier un "pipeline" qui va s'insérer "ou il
faut" dans le formulaire pour ajouter les zones de saisie.
Pour la partie écriture, il faudra surcharger le code php par défaut
pour faire tes écritures, puis repasser la main à l'original.

Je l'ai fait pour les auteurs dans un cas donné, et ça marche pas mal.

Là-dessus clairement le core est encore insuffisant ; il y a une API
inc/modifier qui permet de tout gérer, sauf l'extension à d'autres
champs ; les formulaires d'édition vivent aussi avec une liste fixée
de champs (au lieu de se référer à une grosse variable) ; enfin
inc/revisions a aussi une liste de champs "en dur".

Bref, "ya ka"

-- Fil

framalistes a écrit :

Hello la liste,

Hello

Bon, je me dis que je vais utiliser les champs extras.
Ah oui mais non : on me susurre à l'oreille que les champs extras :
- pourraient ne plus être supportés par la V2 au profit d'une interface permettant de définir ces propres champs (qq1 peut confirmer ?)
- sont en fait des données serialisées, et donc non indéxées/cherchables
Donc, je cherche du côté des contribs et des plugins. J'en profite pour découvrir que (youpimerci !) on peut directement attaquer des tables "non spip" directement dans les squelettes. C'est top, mais ça ne résoud que la motiée de mon probleme : comment donner à mes utilisateurs la possibilité de peupler ces tables ?
Je trouve donc assez rapidement le plugin Form&Tables, j'installe et je teste : ça semble assez bien correspondre à mon besoin, mais il me semble "déconnecté" de la table auteurs. Ainsi, contrairement aux articles, si je crée un formulaire qui va bien avec forms&tables et qu'un de mes auteurs authentifiés le remplit, il sera bien stocké dans les tables spip_forms* mais je perds alors la possibilité pour mes autres rédacteurs d'accéder au contenu via l'admin (et par exemple d'utiliser le forum interne, ou les notions de statuts de publications réservées aux articles).
Pourtant, bravo à l'auteur, c'est un plugin qui roxx bien :slight_smile:
Une autre solution, c'est de faire un plugin qui me rajoute ces champs dans l'interface de saisie admin (j'aurais donc le corps de la fiche composée de la description des softs, et le plugin me permettrait d'ajouter des les champs de formulaires d'une table "extension_articles", par exemple, et d'y manipuler "mes" champs)...
Ca me parait faisable (même s'il va me falloir apprendre à créer des plugins), mais évidemment, c'est pas super propre.

As tu pensé à faire tes fiches logiciels avec forms&tables ...
Je pense que c'est une solution plus que viable...

J'ai bien repéré plusieurs threads dans les archives, mais certains se contredisent (j'ai peut être mal cherché) et je voudrais tant qu'à faire partir du bon pied.
Donc (et oui, tout ça pour ça !) : quel est selon vous la meilleure solution, en terme de perennité et d'interopérabilité, pour gérer l'ajout de champs ? (que l'on souhaite indexables, modifiables, voir avec les possibilités de révisions)
merci
pyg

Quentin

Le 25/05/07, Fil<fil@rezo.net> a écrit :

> En modifiant l'interface privée pour faire apparaitre ces champs.
> Pour ça, il "suffit" de spécifier un "pipeline" qui va s'insérer "ou il
> faut" dans le formulaire pour ajouter les zones de saisie.
> Pour la partie écriture, il faudra surcharger le code php par défaut
> pour faire tes écritures, puis repasser la main à l'original.
>
> Je l'ai fait pour les auteurs dans un cas donné, et ça marche pas mal.

Là-dessus clairement le core est encore insuffisant ; il y a une API
inc/modifier qui permet de tout gérer, sauf l'extension à d'autres
champs ; les formulaires d'édition vivent aussi avec une liste fixée
de champs (au lieu de se référer à une grosse variable) ; enfin
inc/revisions a aussi une liste de champs "en dur".

Bref, "ya ka"

-- Fil

Merci pour vos réponses rapides et pertinentes.

@quentin (qui m'a répondu en privé, mais je pense que c'etait par erreur) :

As tu pensé à faire tes fiches logiciels avec forms&tables ...
Je pense que c'est une solution plus que viable...

Oui, j'ai bien testé. Mais comme je le disais dans mon message
initial, Forms et table, c'est génial pour gérer des données
"déconnectées" du processus de publication (un questionnaire, une
mailing liste, etc). Je ne saurai encore trop remercier le(s)
auteur(s). Mais mon souci, c'est que je suis à mi-chemin entre
l'éditorial et la gestion de données : je souhaite gérer de la
documentation technique, *en conservant les fonctionnalités de
publication de spip* (comme par exemple le workflow "en cours de
rédaction" => "proposé à la publication" => "publié" etc)

@Pif : merci pour ta réponse

Sinon, il existe aussi une contrib qui permet de préciser des colonnes
supplémentaires dans une table spip et de les configurer comme des
champs extra

Si quelqu'un retrouve le nom de la contrib, je suis preneur... :wink:

@Fil :

Bref, "ya ka"

Comme tu dis :slight_smile:
C'est un énorme chantier, et je crains que ça ne soit pas compatible
avec les contraintes de temps fixées par mon employeur :frowning: Mais si au
final on retient SPIP (<no troll inside>j'ai découvert les module CCK
et Views de Drupal qui correspondent tout à fait à la demande</no
troll inside>), j'essaierai de faire pression pour faire un code
générique qui puisse être partagé.

J'ai presque honte de ne pouvoir faire plus pour SPIP, ses
développeurs et sa communauté, qui sont vraiment parties prenantes
dans le succès de Framasoft (10 millions de pages SPIP servies par
mois, c'est pas un mauvais score...)

pyg

@Fil :
> Bref, "ya ka"
Comme tu dis :slight_smile:
C'est un énorme chantier, et je crains que ça ne soit pas compatible
avec les contraintes de temps fixées par mon employeur :frowning:

Ben non ce qui était énorme c'était tous les nettoyages qui
permettaient de créer les API. Maintenant il ne reste "plus que" la
dernière ligne droite. C'est-à-dire sans doute pas grand-chose, si on
se motive bien.

dans le succès de Framasoft (10 millions de pages SPIP servies par
mois, c'est pas un mauvais score...)

Ah je sens que tu vas faire un article pour le spip zine :slight_smile:

-- Fil

framalistes a écrit :

Si quelqu'un retrouve le nom de la contrib, je suis preneur... :wink:

C'est "champs homonymes".

Il a fait un tabac un temps
puis est passé de mode avec la plus récente facilité d'extension de spip.

http://www.spip-contrib.net/?Plugin-Champs-homonymes
ou http://www.spip-contrib.net/Plugin-Champs-homonymes
selon l'avancement des travaux sur contrib.

JLuc

JLuc a écrit :

framalistes a écrit :

Si quelqu'un retrouve le nom de la contrib, je suis preneur... :wink:

C'est "champs homonymes".

Il a fait un tabac un temps
puis est passé de mode avec la plus récente facilité d'extension de spip.

http://www.spip-contrib.net/?Plugin-Champs-homonymes
ou http://www.spip-contrib.net/Plugin-Champs-homonymes
selon l'avancement des travaux sur contrib.

j'ai l'impression que c'est très bien.
JL

Bonsoir,
framalistes wrote:
> ...
> Dans le cadre d'un nouveau projet de site, j'aurais besoin d'utiliser de
> nouveaux champs de saisie dans l'interface de saisie des articles.
> En effet, c'est un cas assez classique, j'ai besoin d'identifier certains
> champs particulier puisqu'il s'agit de fiches descriptives et non
> d'articles
> au sens classique du terme. Ces champs peuvent être de type text, textarea,
> select, etc. Ici, il s'agit de fiches décrivant des logiciels (sur
> lesquelles nous souhaitons ajouter des champs comme "contexte
> d'utilisation", "interopérabilité",etc)
> ...

On en est aux balbutiements, mais cfg avec le storage "table" permet de gérer de telles colonnes supplémentaires.

Comme je l'indiquais récemment, on a toute la mécanique, reste à peaufiner l'intégration comme par exemple insérer le formulaire (qui est isolé coté code) dans n'importe quelle page privée ou publique.
En passant par un pipeline pour ecrire/ et par une balise ad hoc pour le publique, ça ne devrait pas être trop difficile.

Pour l'instant c'est accessible par ecrire/?exec=cfg&cfg=formulaire

où fonds/cfg_formulaire.html est l'unique squelette que tu as à fournir
(le peu de parametrage se faisant par affectations dans des remarques)
Par exemple, l'interface avec le nouvel autoriser() se fait en une seule définition come:
[(#REM) autoriser=webmestre]

Très peu de doc encore:
http://www.spip-contrib.net/?Config-cfg
et une introduction au storages:
http://article.gmane.org/gmane.comp.web.spip.user/109117
des exemples:
http://trac.rezo.net/trac/spip-zone/browser/plugins/test/cfg/fonds

C'est encore très frais ... ou chaud, comme tu veux :slight_smile:
--
toggg

JLuc <jluc@no-log.org> a écrit :

JLuc a écrit :

framalistes a écrit :

Si quelqu'un retrouve le nom de la contrib, je suis preneur... :wink:

C'est "champs homonymes".

Il a fait un tabac un temps
puis est passé de mode avec la plus récente facilité d'extension de spip.

http://www.spip-contrib.net/?Plugin-Champs-homonymes
ou http://www.spip-contrib.net/Plugin-Champs-homonymes
selon l'avancement des travaux sur contrib.

j'ai l'impression que c'est très bien.
JL

Je poursuis le suivi du plugin ici: http://monsitespip.com/spip.php?article7

François
www.monsitespip.com

_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : http://www.spip-contrib.net/spikini/FaQ