[spip-dev] champs extra & EVA

[Fds]

Je me permet de placer également ici ce message car n'ai pas eu
d'informations
sur ce qui me parait important.

Je viens de découvrir les champs extra : merveilleux !

1)
On m'en parlait mais c'était flou, là c'est vraiment le top, dommage qu'il
n'existe pas de fonctionnalité dans l'interface, au lieu de toucher au
fichiers, pour les intégrer !
C'est pas la fin du monde mais je me demandais ...

2) J'utilise le système d'EVA où article.php3 contient des include selon le
mot clé attribué à ces derniers.
Système magnifique qui permet d'avoir plusieurs squelettes différents pour
un article.
J'ai donc essayé d'utiliser la même technique avec la 1.7 en modifiant dans
le bout de code qu'on place dans mes_options.php3, article par album :

$GLOBALS['champs_extra'] = Array (
  'album' => Array (
  "isbn" => "ligne|typo|ISBN"
  )
);

(fait en local avec easyphp)
J'espérait ainsi pouvoir trouver le champs ISBN (dans
l'interface)uniquement dans les articles liés au mot clé "album".
Et miracle, il apparait effectivement que dans les articles liés au mot clé
"album", sauf que le champs n'est pas éditable :-(((
Capture d'écran annexée

Y aurait il une solution ???

En effet, j'utiliserai bien volontier 5-6 types d'articles différents avec
chacun des champs extra différents.
Avoir tous ces champs dans un seul article (dans l'interface), mélangerait
les rédacteurs qui ne sauraient quels champs il faut remplir et lesquels
non....

Si qqn à une idée je suis preneur...

Merci

Fulvio

[Fds]

Bon je relance le sujet... car il me semble quand même important !!
Personne peut m'éclairer la dessus ?

"Fulvio di Stefano" <fulvio@internetdiffusion.com> a écrit dans le message
de news:bor5mm$332$1@sea.gmane.org...

Je me permet de placer également ici ce message car n'ai pas eu
d'informations
sur ce qui me parait important.

Je viens de découvrir les champs extra : merveilleux !

1)
On m'en parlait mais c'était flou, là c'est vraiment le top, dommage qu'il
n'existe pas de fonctionnalité dans l'interface, au lieu de toucher au
fichiers, pour les intégrer !
C'est pas la fin du monde mais je me demandais ...

2) J'utilise le système d'EVA où article.php3 contient des include selon

le

mot clé attribué à ces derniers.
Système magnifique qui permet d'avoir plusieurs squelettes différents pour
un article.
J'ai donc essayé d'utiliser la même technique avec la 1.7 en modifiant

dans

le bout de code qu'on place dans mes_options.php3, article par album :

$GLOBALS['champs_extra'] = Array (
  'album' => Array (
  "isbn" => "ligne|typo|ISBN"
  )
);

(fait en local avec easyphp)
J'espérait ainsi pouvoir trouver le champs ISBN (dans
l'interface)uniquement dans les articles liés au mot clé "album".
Et miracle, il apparait effectivement que dans les articles liés au mot

clé

[615beda9217b323297ed]

Bon, entre les mails en perso et ceux à la liste, je sais plus qui
sais quoi, je résume donc un peu le truc :

  La fonctionnalité permet de spécifier des champs extra par secteurs
pour les articles, point. Pour faire mieux, il faut patcher ou décider
Fil à faire évoluer le machin, mais a priori, c'est pas le moment
(stabilisation de la 1.7 oblige).

  Au départ, j'étais parti sur une autre approche, où on appelait une
fonction qui retournait la liste des champs à définir à partir de l'id
d'article. L'inconvénient, c'est que ça force à aller chercher les infos
nécessaires (les mots clé dans ton cas), ce qui est loin d'être
immédiat. Fil à préféré un tableau à 42 dimensions, mais le résultat est
le même.

  Il faut bien comprendre que les champs extra, c'est une fonctionalité
récente, estampillée comme étant "très tordu à utiliser". Ça va donc être
dur de la rendre encore plus complexe sans veto les 3 gardiens de la
flamme

À+, Pif.

[Yves_Pratter1 (Yves Pratter)]

Il faut bien comprendre que les champs extra, c'est une fonctionalité
récente, estampillée comme étant "très tordu à utiliser".

Je viens d'essayer la chose, c'est bien, propre et facile à utiliser, mais
il y a quelques limitations de taille :
- pas d'indexation pour le moteur de recherche
- pas de tri ou de critère de recherche pour les boucles (ce ne sont pas de
vrais champs, mais un seul champ BLOB contenant un tableau php).
- pas de type particulier (date, "ID" associé à une liste déroulante...)

C'est ingénieux car cela ne consomme pas inutilement de la place pour les
articles qui ne les utilisent pas.
Le fait que ces champs ne sont pas indexable me gêne un peu. ça viendra
peut-être en 1.8

Yves

[Fds]

cela veux dire que, par exemple, si on à des champs pour les données d'une
voiture
(vitesse, accéleration, consommation..)
on ne pourra pas présenter dans une autre page, les différentes vitesses
maximales
de chaque article qui à le champs "vitesse max" remplis ?

Si c'est le cas c'est effectivement dommage....

Merci Christian pour tes spécifications.... c'est dommage de mettre l'eau à
la bouche
avec cette fonctionnalité qui à la fin semble être très limitée, à moins que
je ne sais pas tout...

"Yves Pratter" <yves.pratter@laposte.net> a écrit dans le message de
news:bp0gkn$rjm$1@sea.gmane.org...

> Il faut bien comprendre que les champs extra, c'est une fonctionalité
>récente, estampillée comme étant "très tordu à utiliser".

Je viens d'essayer la chose, c'est bien, propre et facile à utiliser, mais
il y a quelques limitations de taille :
- pas d'indexation pour le moteur de recherche
- pas de tri ou de critère de recherche pour les boucles (ce ne sont pas

de

[The_Anarcat]

cela veux dire que, par exemple, si on à des champs pour les données
d'une voiture (vitesse, accéleration, consommation..) on ne pourra
pas présenter dans une autre page, les différentes vitesses
maximales de chaque article qui à le champs "vitesse max" remplis ?

Si c'est le cas c'est effectivement dommage....

C'est effectivement le cas. Pour les détails techniques, sachez que
l'ensemble des champs "extra" sont stockés sous forme "serializé"
(voir php.net/serialize). Ceci empêche les requêtes SQL sur les champs
eux-mêmes contenu dans cette colonne, d'une certaine façon. On peut
évidemment passer à côté de cette limite en effectuant une requête
inspectant chaque champ et travailler en PHP pour extraire des
statistiques/informations pertinences, mais c'est sous-optimal.

(L'idéal serait évidemment que les champs extras modifient la
structure de la base de données, mais là on s'embarque dans une
horreur de multiplication des colonnes car une seule table peut avoir
plusieurs différents types de champs. Le serialize me paraît donc la
meilleure (et la plus simple) solution.)

Merci Christian pour tes spécifications.... c'est dommage de mettre
l'eau à la bouche avec cette fonctionnalité qui à la fin semble être
très limitée, à moins que je ne sais pas tout...

Je vous trouve pas mal "chiâleux" comme on dit en bon jargon
québécois. Cette fonctionalité n'est pas encore ni terminée, ni
documentée, ni officiellement offerte par SPIP.

Cette fonctionalité n'est pas si limitée. Elle permet d'ajouter un
nombre de champs arbitraire à certains articles, ce qui, je peux vous
dire, est un exploit dans SPIP.

De plus, pour faire ce que tu veux, tu pourrais utiliser les autres
nombreux champs par défaut de SPIP en changeant leur sens (sous-titre
== vitesse, par exemple) et les squelettes appropriés, et tu pourras
alors faire tous les tris et maximums que tu veux.

Autrement, il te faudra créer un nouveau type de document, tout
simplement, et coder ça dans le coeur de SPIP.

Bonne chance,

A.

[Fds]

C'est avec les critiques qu'on s'améliore non ? ;-))
Ok c'est vrai on est un peu "chialeurs" mais si ca fait avancer l'histoire
tant mieux.

Ok les champs ne peuvent pas être récupérés bien que ca reste
très dommage mais s'est vrai qu'on va rien prétendre, par contre
c'est dommage que lorsque j'apelle ces champs avec un include (comme
expliqué avant) ils sont qu'en lecture seule !!!

Si c'est une version beta c'est bien pour la tester et dire ce que l'on
pense
avant de "l'officialiser" non ???

D'autant plus dommage que Christian semblait avoir une solution
à premier abord acceptable....

Merci quand même et malgré ces "chiâlements" je ne peux que
m'incliner devant le travail fait par les spipeurs, qui ont créés
un outil vraiment phénoménal.

"The Anarcat" <anarcat@anarcat.ath.cx> a écrit dans le message de
news:20031113192552.GC8562@xtanbul...

cela veux dire que, par exemple, si on à des champs pour les données
d'une voiture (vitesse, accéleration, consommation..) on ne pourra
pas présenter dans une autre page, les différentes vitesses
maximales de chaque article qui à le champs "vitesse max" remplis ?

Si c'est le cas c'est effectivement dommage....

C'est effectivement le cas. Pour les détails techniques, sachez que
l'ensemble des champs "extra" sont stockés sous forme "serializé"
(voir php.net/serialize). Ceci empêche les requêtes SQL sur les champs
eux-mêmes contenu dans cette colonne, d'une certaine façon. On peut
évidemment passer à côté de cette limite en effectuant une requête
inspectant chaque champ et travailler en PHP pour extraire des
statistiques/informations pertinences, mais c'est sous-optimal.

(L'idéal serait évidemment que les champs extras modifient la
structure de la base de données, mais là on s'embarque dans une
horreur de multiplication des colonnes car une seule table peut avoir
plusieurs différents types de champs. Le serialize me paraît donc la
meilleure (et la plus simple) solution.)

Merci Christian pour tes spécifications.... c'est dommage de mettre
l'eau à la bouche avec cette fonctionnalité qui à la fin semble être
très limitée, à moins que je ne sais pas tout...

Je vous trouve pas mal "chiâleux" comme on dit en bon jargon
québécois. Cette fonctionalité n'est pas encore ni terminée, ni
documentée, ni officiellement offerte par SPIP.

Cette fonctionalité n'est pas si limitée. Elle permet d'ajouter un
nombre de champs arbitraire à certains articles, ce qui, je peux vous
dire, est un exploit dans SPIP.

De plus, pour faire ce que tu veux, tu pourrais utiliser les autres
nombreux champs par défaut de SPIP en changeant leur sens (sous-titre
== vitesse, par exemple) et les squelettes appropriés, et tu pourras
alors faire tous les tris et maximums que tu veux.

Autrement, il te faudra créer un nouveau type de document, tout
simplement, et coder ça dans le coeur de SPIP.

Bonne chance,

A.

[The_Anarcat]

C'est avec les critiques qu'on s'améliore non ? ;-))
Ok c'est vrai on est un peu "chialeurs" mais si ca fait avancer l'histoire
tant mieux.

Je suis pas sûr que ça fait avancer l'histoire, mais au moins, on a du
feedback, c'est bon.

Ok les champs ne peuvent pas être récupérés bien que ca reste
très dommage mais s'est vrai qu'on va rien prétendre, par contre
c'est dommage que lorsque j'apelle ces champs avec un include (comme
expliqué avant) ils sont qu'en lecture seule !!!

Hmm.. je ne suis pas sûr de comprendre, mais il est certain que l'on
peut récupérer les champs extra dans les squelettes, c'est d'ailleurs
documenté sur SPIP-Québec:

http://spipquebec.org/article.php3?id_article=28

Si c'est une version beta c'est bien pour la tester et dire ce que
l'on pense avant de "l'officialiser" non ???

Le problème est que l'on en est même pas encore là. les champs extra
ne sont pas encore à l'étape du "beta" car il ne seront pas améliorés,
seulement "bugfixés" pour 1.7, à ce que j'ai compris.

C'est une fonctionalité "alpha", pas beta.

D'autant plus dommage que Christian semblait avoir une solution
à premier abord acceptable....

Merci quand même et malgré ces "chiâlements" je ne peux que
m'incliner devant le travail fait par les spipeurs, qui ont créés
un outil vraiment phénoménal.

Si je peux parler au nom de tous: Merci beaucoup,

A.

[Nicolas_Hoizey2 (Nicolas Hoizey)]

l'ensemble des champs "extra" sont stockés sous forme "serializé".
Ceci empêche les requêtes SQL sur les champs eux-mêmes contenu dans
cette colonne, d'une certaine façon.
[...]
(L'idéal serait évidemment que les champs extras modifient la
structure de la base de données, mais là on s'embarque dans une
horreur de multiplication des colonnes car une seule table peut
avoir plusieurs différents types de champs.

Une solution intermédiaire, d'ailleurs naturelle dans d'autres outils
de gestion de contenus qui proposent la modification des formats
d'"objets" de contenus, serait d'avoir une table articles_extra dans
laquelle trois colonnes suffiraient à gérer autant d'extra que
nécessaires qui seraient utilisables dans les critères de boucles.

id_article
nom_extra
valeur_extra

Je ne dis pas que c'est mieux dans l'absolu, car c'est plus difficile
à mettre en oeuvre, mais ça répond sans doute à plus de besoins.

-Nicolas

[615beda9217b323297ed]

Ça implique surtout des jointures pas possibles coté sql

À+, Pif.

[Fds]

Je relance à nouveau ce sujet pour savoir si entretemps ( je suis à la
1.7b2)
les choses ont évolué et s'il y avait une solution afin que les champs extra
puissent
être éditables lorsqu'ils sont appelés avec la méthode du type eva...

Ca serait super cool....

Merci

"Fulvio di Stefano" <fulvio@internetdiffusion.com> a écrit dans le message
de news:bor5mm$332$1@sea.gmane.org...
> Je me permet de placer également ici ce message car n'ai pas eu
> d'informations
> sur ce qui me parait important.
>
> Je viens de découvrir les champs extra : merveilleux !
>
> 1)
> On m'en parlait mais c'était flou, là c'est vraiment le top, dommage

qu'il

> n'existe pas de fonctionnalité dans l'interface, au lieu de toucher au
> fichiers, pour les intégrer !
> C'est pas la fin du monde mais je me demandais ...
>
> 2) J'utilise le système d'EVA où article.php3 contient des include selon
le
> mot clé attribué à ces derniers.
> Système magnifique qui permet d'avoir plusieurs squelettes différents

pour

> un article.
> J'ai donc essayé d'utiliser la même technique avec la 1.7 en modifiant
dans
> le bout de code qu'on place dans mes_options.php3, article par album :
>
> $GLOBALS['champs_extra'] = Array (
> 'album' => Array (
> "isbn" => "ligne|typo|ISBN"
> )
> );
>
> (fait en local avec easyphp)
> J'espérait ainsi pouvoir trouver le champs ISBN (dans
> l'interface)uniquement dans les articles liés au mot clé "album".
> Et miracle, il apparait effectivement que dans les articles liés au mot
clé
> "album", sauf que le champs n'est pas éditable :-(((
> Capture d'écran annexée
>
> Y aurait il une solution ???
>
> En effet, j'utiliserai bien volontier 5-6 types d'articles différents

avec

> chacun des champs extra différents.
> Avoir tous ces champs dans un seul article (dans l'interface),

mélangerait