[spip-dev] A propos des champs EXTRA

Bonsoir,

Une question de fond par rapport à l'avenir de SPIP. Je suis pas certain d'être au courant de tout, mais je pose quand même la question, au risque de jouer la mouche du coche.

Je crois qu'il serait bon d'avoir ce débat (s'il n'a pas déjà eu lieu ailleurs) avant la sortie de la 1.8.

Que va-t-il advenir à court et moyen terme des champs extra?

A long terme, tout le monde est d'accord (me semble-t-il), les champs extra sont destinés à disparaître, avalés par la possibilité - ouverte par le nouveau compilo et qui sera réalisée un jour ou l'autre - de gérer dans spip de façon générique des données dont la structure sera déterminée par l'utilisateur et plus par la structure préexistante et forcément arbitraire des objets de spip (bref: la raison d'être des champs extra disparaîtra).

Néanmoins, plusieurs arguments me semblent plaider en faveur d'une conservation des champs extra dans la prochaine version de spip, autrement que comme simple survivance d'un système abandonné mais pour lequel on conserve une compatibilité:

- Il semble l'évidence de constater que la gestion générique des données
   n'est pas pour tout de suite (ne serait-ce que parce que la très
   simple question de savoir qui est celui qui a les compétences et le
   temps pour coder ça n'a pas pas à l'heure actuelle trouvé de réponse
   claire - j'imagine qu'Emmanuel, qui est sans doute le plus apte à le
   faire, va se reposer un peu dans les temps qui viennent après les
   importants efforts fournis cet été). Même si tout le monde sent
   confusément que spip 2.0. (?) sera décoiffant, on y est pas encore.

- Les champs extra offrent au moins une fonctionnalité qui n'est pas
   offerte a priori par le nouveau compilo: être facilement limitables
   (à un secteur, à un type d'auteur, à un groupe de mot-clé,...),
   fonctionnalité que je trouve personnellement fort appréciable.

- A cela on peut ajouter le fait que la simplicité de mise en oeuvre des
   champs extra (même s'il faut éditer un petit fichier php) restera très
   probablement supérieure à la définition inévitablement complexe de la
   structure des tables et autres données y afférentes quand il s'agira
   de créer de nouvelles tables objets dans spip. Par conséquent, les
   champs extra sont et risquent de rester un moyen plus facile pour
   l'utilisateur moyennement averti de modifier la structure des données
   de son site.

Bref, si l'on ajoute qu'une librairie vachement meilleure (permettant de gérer de nouveaux types de données,...) que celle actuellement présente (l'actuel inc_extra.php3 sur la cvs date de 10 mois) dans la distribution a été développée et est aujourd'hui inutilisée (enfin, je pense?), je me dis qu'il vaut peut-être la peine de considérer sérieusement une (semi-)officialisation des champs extra et d'intégrer la nouvelle librairie.

Ca permettra de maturer le nouveau compilo, d'avoir un peu de pratique avec lui, que quelques grosses contribs l'utilisant aient été pondues,... avant d'implémenter l'étape suivante qui sera sans doute très délicate. Tout en ayant un outil correct répondant aux besoins en attendant.

Au plaisir de vous lire,

François

Je ne suis pas sûr de comprendre ce que ça veut dire,
car pour ma part je ne vois pas ce que les champs EXTRAS apportent de plus
(mais je les connais mal).

J'ai l'impression qu'il y a un aspect du compilateur qui n'a pas été vu:
si on modifie inc_serialbase en ajoutant des tables à $tables_principales,
puis qu'on réinstalle Spip (c'est à dire en détruisant inc_connect.php3)
on déclare ces nouvelles tables à Mysql (en plus des standards qui sont
laissées intactes). Si on veut que ces tables soient interrogeables en fonction
des secteurs, auteurs, mot-clé etc, il suffit de leur adjoindre un tel champ.

Formellement, il y a 5 tables avec des champs extras: articles, breves, rubriques, auteurs messages. Si je déclare 5 tables supplémentaires à 2 champs (id_article & extra; id_breve & extra
etc) ou si on préfère 1 table à 6 champs (extra, id_article, id_breve....)
alors je peux écrire

<BOUCLE0(ARTICLES)>
  <BOUCLE1(tablesup){id_article}>....</BOUCLE1>
</BOUCLE0>

dans boucle1, je pourrais accéder au champ #EXTRA d'une part, mais aussi #ID_SECTEUR etc
(et même, avec la notation #0:EXTRA, au champ extra de la table article).

Quid ?

      Emmanuel

Déesse A. a écrit :

Je ne suis pas sûr de comprendre ce que ça veut dire,
car pour ma part je ne vois pas ce que les champs EXTRAS apportent de plus

Et bien, simplement (enfin, on se comprend ;-)), il "reste" l'interface à faire: faire en sorte qu'il soit possible de gérer facilement des données avec des formulaires à remplir et tout et tout. Concrètement, c'est ça que les champs EXTRA apportent aujourd'hui et qui n'existe pas (encore) dans le système "nouveau compilo".

Si aujourd'hui on peut exploiter très facilement dans les squelettes des données hors structure type de spip, il n'existe pas de moyen simple et convivial d'entrer ces données dans la base.

Amicalement,

François

Tu veux dire avoir une espèce de clone du script inc_extra.php3 ?

La contrib que j'ai posté il y a un mois me semble répondre à ton problème:

http://www.spip-contrib.net/ecrire/articles.php3?id_article=709

      Emmanuel

Déesse A. a écrit :

Tu veux dire avoir une espèce de clone du script inc_extra.php3 ?

La contrib que j'ai posté il y a un mois me semble répondre à ton problème:

http://www.spip-contrib.net/ecrire/articles.php3?id_article=709

Salut Emmanuel,

Oui, c'est exactement ça. Mais bon, sans du tout du négliger la valeur de ce script qui sera très pratique, il me semble que ce n'est qu'un tout premier début et que le champ des possibles qui est ouvert par ce script reste très largement à explorer.

A mon avis, ce que nous devons viser, c'est qu'un script de ce type remplace les actuels scripts de gestion des articles et des brèves et devienne le seul outil de gestion des objets spip actuels (en tout cas, des articles et des brèves) et puisse être utilisé pour tout nouveau type. En mettant sur un même pied dans l'interface les anciens et les nouveaux types, cette évolution permettra non seulement une gestion parfaite des nouveaux objets mais aussi la modification de la structure des tables actuelles). Ce qui implique d'y intégrer toute une série de choses (de "briques", qui seront utilisées ou non selon le type d'objet utilisé):

- la gestion des dates, de façon pratique, à l'image de ce qui est proposé dans la gestion des articles, avec date de publication, date de publication antérieure,... (et l'indication dans le modèle de données de ceux des éléments qui sont utilisés par l'objet; par exemple, l'utilisation ou non de la date de publication antérieure pour les articles ne serait plus définie par une option stockée dans une variable globale mais par une ligne dans la définition de la table articles);

- la gestion de la liaison aux auteurs (et la définition dans le modèle des données de l'utilisation ou non de cette liaison par le type). Selon cette optique, il serait pas exemple possible de décider que les brèves ont la possibilité d'être liées à des auteurs,...

- la définition du workflow (quels sont les statuts utilisés par cet objet?) et la gestion des droits.

- la gestion de la liaison aux mots-clés (en définissant, une fois encore, l'activation de cette option - éventuellement partiellement, groupe par groupe - dans la définition des données,..

- etc, etc... les documents joints, les logos, le menu de langue, les images, les pétitions, les forums,...

- et même des petits brolls (quel champ utilise la barre d'outil, hauteur des champs textarea, possibilité de définir une icône pour chaque nouveau type...).

Bien sûr, tout cela est gigantesque comme chantier, ça implique de revoir en profondeur pas mal de choses. Ca demande d'enrichir diablement le modèle de données, ça pose tout plein de problèmes (il faudra une numérotation unique pour tous les objets si on veut pouvoir les lier aux auteurs, mots-clés, forums,... sans multiplier les table de liaisons au delà du raisonnable,...), mais ça me semble être la suite logique (au moins à long terme) des développements entrepris cet été.

Bref, ce truc c'est le rêve, mais ce n'est pas pour toute de suite; d'où l'idée de conserver encore quelque temps les champs extra.

J'imagine que le vais me faire traiter de fou, mais il me semble que ce concept (qui était d'ailleurs ébauché par Fil récemment, me semble-t-il, mais je ne retrouve pas le message) mérite d'être sérieusement examiné.

A vous lire,

François

Les champs extra ne seront pas supprimés mais aucun support ne sera fourni.
Et il me semble que le script mentionné remplit déjà le même niveau de service qu'eux.
Partant, il serait plus utile d'enrichir les possibilités de ce script pour éprouver la technique d'avenir que de maintenir à bout de bras qqch d'obsolète.

      Emmanuel

En gros, ce que tu évoque, c'est ça :
http://lab.spip.net/spikini/SquelettesEtendus

  C'est donc ce débat là qu'il faudrait alimenter pour voir si un
premier jet est possible à court terme, ce qui permettra de décider
si les extras passent à la trappe ou pas.

  Pour l'instant, les extras, c'est du "unsupported". Ce qu'il faut
absolument éviter, c'est officialiser leur existance pour les dégager
dans 6 mois.
  Si demain on décide de dégager les extras, ceux qui les ont utilisé
ont été prévenus, qu'ils se débrouillent (moi le premier, ce n'est donc
pas du mépris envers les utilisateurs)
  Par contre, si on officialise leur existence, il va falloir les
trainer, même le jour où ils seront complètement redondants.

  Je pense qu'il faut donc commencer par réfléchir à ce qu'on peut faire
pour rendre les "tables externes" (faudrait trouver un nom meilleur mais
pas confusant avec extra) accessibles depuis l'admin.
  De là, on pourra voir si une migration de extra vers champs externe
est possible après coup, histoire d'avoir quelque chose en attendant
mieux. Sinon, faudra garder les extras en "officieux" et surtout en
"solution non pérenne, on vous aura prévenu".

  Je le répète, ce n'est pas du mépris des utilisateurs ou du code
actuel (c'est quand même moi qu'avais lancé le chantier des extras :wink:
mais les extras, c'était un truc parce que je n'osais pas réver du
nouveau compilo. Maintenant qu'il existe, et qu'on commence à réver
d'un moyen d'avoir une interface admin pour y accéder, pour moi les
extras sont obsolètes, point.

  L'idéal serait d'en faire une contrib externe, histoire que ceux qui
les utilisent puissent les garder, mais ça n'a rien à faire dans le
core (ça me fait tout drôle de dire ça alors que je me suis bagarré
avec Fil pour les intégrer dans le code il y a quelques mois :slight_smile:

À+, Pif.

Bon, un long blabla sur ce qui serait faisable, mais c'est parce que je me
suis déjà pas mal battu avec les extra et que je gère des besoins
suffisamment tordus pour pouvoir ratisser large en terme de fonctionnalités
couvertes.

Perso, j'utilise une version modifiée des extras car mon besoin était assez
particulier.

J'envisage évidemment de basculer sur des "champs supplémentaires" (et peut
être des tables externes).

Fonctionnellement, quelles sont les différences entre extra et modification
des structures de données :

On stocke de l'information structurée en plus de l'info native de spip =>
pareil

On peut y accéder dans les squelettes => idem mais un mieux géré avec le
nouveau compilo (déserialisation en moins et possibilité de les utiliser en
critère)

On peut y accéder dans l'espace privé => idem (d'après ce que j'ai compris
de la contrib d'Emmanuel, pas encore testé)

On peut limiter leur portée => La, on y est pas encore, mais comme le
suggérait Emmanuel, il "suffit" de mettre en place les champs
correspondants.

MAIS :

pour ce dernier point, ca n'est valable que pour les boucles, pas pour la
saisie dans l'espace privé.

On en revient donc à l'intérêt de construire l'espace privé avec des boucles
et des formulaires.

Le travail de "mise à niveau fonctionnel" est donc, amha, un travail sur la
génération de formulaires à partir de la définition de la structure des
données (=> la fameuse contrib qu'il faut absolument que je regarde).

Aujourd'hui, on peut travailler en lecture sur une structure complexe
(plusieurs tables avec jointure) mais pas en ecriture (enfin, je ne crois
pas ... on peut ? pour des relation 1-1 ? 1-n ? n-n ?)

C'est donc le premier casse tête du traitement par formulaire "générique".

Deuxième casse tête : les limitations (à un secteur par exemple).

La, ca se corse.

Il faut pouvoir travailler sur les relation n-n (heureusement pas sur le
contenu de la table de référence, uniquement sur l'association).

C'est donc quelque chose d'assez proche des mots clés, mais s'appuyant sur
d'autres tables, pas toujours les mêmes, et sans doute en permettant
plusieurs critères.

Si je l'applique à un besoin concret, ca pourrait répondre à un besoin du
type "je veux un champs choix du squelette sur le secteur 12 mais uniquement
pour les admins".

C'est actuellement ce que je fais sur ma version modifiée des champs extra,
avec en fait deux notions distinctes :

- visible/invisible

- modifiable / non modifiable (modifiable/invisible étant évidemment à
éviter ...)

mais ca pose un problème :

Lorsqu'un champs extra n'est pas "voulu", il n'apparait pas du tout => pas
de valeur par defaut

Pour avoir un système complet, il manque donc la notion de base des champs
extra (que j'ai détourné) :

- Existant ou non

La, on pourrait avoir

- champs inexistant pour le contexte => rien

- champs existant mais non visible => input hidden

- champs existant visible et modifiable => input, radio ... selon config

- champs existant visible mais non modifiable => idem mais readonly

Ca fait beaucoup de gadgets pour une gestion generique des formulaires à
peine envisagée ...

Ca risque de rapidement tourner à l'usine à gaz, sauf à stocker le
formulaire generé en cache (avec un passage de contexte "automatique")

Pas très réaliste pour la 1.8 ...

Mais soyons un brin visionnaires : ne serait-ce pas "magique" de pouvoir
utiliser l'interface privée, les boucles, les balises et le cache sur
n'importe quelle structure de données, en prenant en compte les besoins
"metier" de chacun ?

Spip serait alors un framework livré avec un exemple d'utilisation : le Spip
qu'on connait.

Se pose alors la question : Est-ce le but ?

ou du moins : Est ce que ca ne va pas à contre sens ?

En tous cas, si Spip pouvait faire tout ca, je pourrais arreter de faire du
OJB/Struts/JSTL et autres hybernate et custom tags !

C'etait mes 2 cents le temps d'un pause ...

@++

Salut,

<citation de="Christian Lefebvre">

En gros, ce que tu évoque, c'est ça :
http://lab.spip.net/spikini/SquelettesEtendus

Euh oui (quoique, il y a beaucoup de choses sur cette page). Disons que je
me rallie complètement à l'avis exprimé par Fil, auquel je faisais
d'ailleurs allusion (et qui n'est pas vraiment celui des squelettes
étendus si je comprends bien):

   "Mon approche est un peu différente : l’idée serait de remplacer
l’ensemble des pages articles.php3, articles_edit.php3,
breves_voir.php3 etc. par un seul script qui affiche/édite un objet
générique. Il faut donc une description de l’objet qui contienne
suffisamment d’infos pour que le script en question sache qu’il doit
mettre les champs dans tel ordre, les afficher comme ci ou ça, les
éditer sous telle ou telle forme."

J'ai l'impression que la modularité de l'interface privée (très
intéressante également) et l'approche générique décrite ci-dessous ne sont
que partiellement liées.

Pour l'instant, les extras, c'est du "unsupported". Ce qu'il faut
absolument éviter, c'est officialiser leur existance pour les dégager
dans 6 mois.

[...]

L'idéal serait d'en faire une contrib externe, histoire que ceux qui
les utilisent puissent les garder

Bon, est-ce que c'est si compliqué que ça d'assurer le passage des données
contenues dans les champs extra vers les bases de données.

Mettons que l'on dit que jusqu'à la version 2.0 (ou un autre numéro), les
champs EXTRA sont supportés, mais qu'à la publication de la version 2.0,
disposant de la gestion générique des nouveaux types d'objets dans
l'interface, elle sera abandonnée. Pour peu qu'on sache d'où viennent les
données et où elles vont, ce n'est quand même pas la mer à boire que
d'écrire un petit outil qui transforme les données contenues dans les
champs extra en données compatibles avec le nouveau compilateur.

Ca permet de ne pas se précipiter pour mettre en place l'interface
générique et/ou une modularité de l'interface via des "squelettes étendus"
tout en disposant dans l'intervalle d'un bon outil permettant de remplir
la fonction digressive par rapport à la structure de la base de données,
dont tellement de gens ont besoin.

Et donc, je plaidais et je plaide pour que l'on intègre la nouvelle
librairie de gestion des champs extra (qui, sauf erreur de ma part, permet
de gérer de nouveaux types de données et améliore pas mal le
fonctionnement des champs extra) dans la distribution officielle (en
précisant bien avec quel statut) pour remplacer l'actuelle.

François

On en revient donc à l'intérêt de construire l'espace privé avec des boucles
et des formulaires.

Wouais :slight_smile:

Le travail de "mise à niveau fonctionnel" est donc, amha, un travail sur la
génération de formulaires à partir de la définition de la structure des
données (=> la fameuse contrib qu'il faut absolument que je regarde).

Heu laquelle ? j'm'y paume à force ...

- champs existant mais non visible => input hidden

  non, car ça n'empèche pas de le poster "de force". Il faut en plus,
qu'il y ait un test lors du traitement du formulaire.
  c'est un point que j'évoque sur le spikini du lab

Mais soyons un brin visionnaires : ne serait-ce pas "magique" de pouvoir
utiliser l'interface privée, les boucles, les balises et le cache sur
n'importe quelle structure de données, en prenant en compte les besoins
"metier" de chacun ?
Spip serait alors un framework livré avec un exemple d'utilisation : le Spip
qu'on connait.

Wah .... cooooool :wink:

Se pose alors la question : Est-ce le but ?
ou du moins : Est ce que ca ne va pas à contre sens ?

  Faut voir : si l'"exemple d'utilisation" reste abordable, et que le
résultat est techniquement pas plus difficile que l'existant, ça me
parait la bonne approche.

À+, Pif.

SCHREUER François a écrit :

Salut,

[snip]

Et donc, je plaidais et je plaide pour que l'on intègre la nouvelle
librairie de gestion des champs extra (qui, sauf erreur de ma part, permet
de gérer de nouveaux types de données et améliore pas mal le
fonctionnement des champs extra) dans la distribution officielle (en
précisant bien avec quel statut) pour remplacer l'actuelle.

Moi j'ai fait ma petite tambouille en rajoutant ce que je voulais dans mes_options, et ca marche bien pour les squelettes, évidement pas dans la partie privée.

En gros il me manquait les boutons radio, les selects et une fonction d'afichage des formulaires dans la partie publique.

Mais ce qui serait top, c'est que l'un d'entre vous qui utilise les extra fasse le point sur ce qu'il faudrait rajouter à la version actuelle, parmi ce qui est proposé en contrib et sur le fichier de travail des inc-extra modifié du wikki (qui en fait trop amha).

Et ce, sur le wiki et sous l'article de spip-contrib, que Ben. menace de faire disparaitre dans le spip à brac si plus personne n'y touche.

http://spip-contrib.net/spikini/ToDoChampsExtra

C'est juste de la remise en forme, pas besoin d'être un dev de ouf pour réussir cela.

à+
BoOz

> Le travail de "mise à niveau fonctionnel" est donc, amha, un travail sur

la

> génération de formulaires à partir de la définition de la structure des
> données (=> la fameuse contrib qu'il faut absolument que je regarde).
Heu laquelle ? j'm'y paume à force ...

le insere_en_table d'Emmanuel.

> - champs existant mais non visible => input hidden
  non, car ça n'empèche pas de le poster "de force". Il faut en plus,
qu'il y ait un test lors du traitement du formulaire.
  c'est un point que j'évoque sur le spikini du lab

??? tu as un lien.
Je croyais qu'on ne pouvait pas surcharger un POST par un GET ...
Mais bon, c'etait juste l'idée, que ca soit traité coté serveur à reception
des données, ca me parait bien aussi, du moment que ca rend le service et
qu'on peut affecter la valeur par defaut meme si le champ n'est pas
affiché..
C'etait surtout pour parler d'un besoin, partiellement couvert par les
extras qu'il ne faudrait pas occulter en rendant l'interface privée de Spip
"générique".
Mais c'est clair que ca a des implications lourdes à la fois sur le volume
de developpement et sur la philosophie qu'on peut implanter dans l'outil (en
gros, ca veut dire que par parametrage, on pourrait aire faire à Spip toutes
les horreurs de fliquage, données cachée ... qu'il n'est meme pas la peine
d'aborder ici)

> Se pose alors la question : Est-ce le but ?
> ou du moins : Est ce que ca ne va pas à contre sens ?
  Faut voir : si l'"exemple d'utilisation" reste abordable, et que le
résultat est techniquement pas plus difficile que l'existant, ça me
parait la bonne approche.

Ben, l'idée, c'est de fournir exactement la meme chose mais par parametrage
(je parle bien sur de l'interface privée, coté public on y est quasiment).

Bon, honnêtement, le champs EXTRA, c'était un pis-aller.

Aujourd'hui, le nouveau moteur va permettre de faire la même chose avec beaucoup plus de souplesse. Donc, sans pour autant abandonner le champ EXTRA, je ne vois pas qu'on se lance dans son développement. Le but, c'est plutôt de travailler à des outils beaucoup plus souples qui accompagneront le nouveau moteur.

ARNO*

http://lab.spip.net/spikini/SquelettesEtendus

À+, Pif.