[spip-dev] Balises appliquées à un objet déjà connu

[davux]

Je préviens, c'est une idée pas aboutie du tout, mais plutôt que de la
garder dans un coin de ma tête je voulais partager les premières
palpitations d'idées ici pour voir si ça inspire des gens.

Il semble apparaître un besoin pour raccourcir l'écriture suivante :

<BOUCLE_x(ARTICLES){id_article=42}>#TRUC</BOUCLE>

C'est l'écriture sous une forme #TRUC{article,42}.

Bon je préfère prévenir que personnellement je trouve qu'on ne devrait
pas faire de dérogation à la logique des boucles, sinon on va se mettre
à faire plein d'exceptions. Mais bon visiblement c'est quand même un
besoin que les gens expriment, alors je crois qu'il faut y faire face...
déjà parce que SPIP on le fait quand même pour les gens, et aussi parce
si on fournit rien, les gens vont quand même le faire mais n'importe
comment.

Ce qui m'amène à la façon actuelle dont le besoin est résolu
(#TRUC{article,42}). J'y vois deux problèmes majeurs :

1. Tout le monde doit réinventer la roue, pour chaque balise,
    patiemment. Bonjour l'angoisse, les copiers-collers, et les
    devinettes pour savoir si pour cette balise ça marche, et pour
    celle-là non.
2. La syntaxe entre en conflit avec les potentiels arguments "réels" de
    la balise. Tant que c'est #TITRE ou ce genre de trucs, ça va, mais
    quand c'est une balise qui prend déjà des arguments, ça devient
    compliqué. Est-ce que l'objet et l'id viennent au début ? à la
    fin ? Bref, c'est la porte ouverte à la bidouille, floue.

Du coup je me disais qu'il faudrait trouver une autre syntaxe pour ces
arguments-là, qui sont en fait des "méta-arguments". Un truc du genre
[article,42] ou encore %article%42. Évidemment, la syntaxe actuelle est
peut-être difficile à faire évoluer, mais en gros il faudrait essayer
une approche comme ça. Et dans tous les cas, prévoir ce besoin pour la
future syntaxe.

J'avais prévenu, c'est pas du tout abouti. Bref. Des avis ? D'autres
suggestions pour faire face à ce besoin ?

[RealET]

* davux tapuscrivait, le 02/12/2010 23:55:

Je préviens, c'est une idée pas aboutie du tout, mais plutôt que de la
garder dans un coin de ma tête je voulais partager les premières
palpitations d'idées ici pour voir si ça inspire des gens.

Il semble apparaître un besoin pour raccourcir l'écriture suivante :

<BOUCLE_x(ARTICLES){id_article=42}>#TRUC</BOUCLE>

C'est l'écriture sous une forme #TRUC{article,42}.

Bon je préfère prévenir que personnellement je trouve qu'on ne devrait
pas faire de dérogation à la logique des boucles, sinon on va se mettre
à faire plein d'exceptions. Mais bon visiblement c'est quand même un
besoin que les gens expriment, alors je crois qu'il faut y faire face...
déjà parce que SPIP on le fait quand même pour les gens, et aussi parce
si on fournit rien, les gens vont quand même le faire mais n'importe
comment.

Ce qui m'amène à la façon actuelle dont le besoin est résolu
(#TRUC{article,42}). J'y vois deux problèmes majeurs :

  1. Tout le monde doit réinventer la roue, pour chaque balise,
     patiemment. Bonjour l'angoisse, les copiers-collers, et les
     devinettes pour savoir si pour cette balise ça marche, et pour
     celle-là non.
  2. La syntaxe entre en conflit avec les potentiels arguments "réels" de
     la balise. Tant que c'est #TITRE ou ce genre de trucs, ça va, mais
     quand c'est une balise qui prend déjà des arguments, ça devient
     compliqué. Est-ce que l'objet et l'id viennent au début ? à la
     fin ? Bref, c'est la porte ouverte à la bidouille, floue.

Du coup je me disais qu'il faudrait trouver une autre syntaxe pour ces
arguments-là, qui sont en fait des "méta-arguments". Un truc du genre
[article,42] ou encore %article%42. Évidemment, la syntaxe actuelle est
peut-être difficile à faire évoluer, mais en gros il faudrait essayer
une approche comme ça. Et dans tous les cas, prévoir ce besoin pour la
future syntaxe.

J'avais prévenu, c'est pas du tout abouti. Bref. Des avis ? D'autres
suggestions pour faire face à ce besoin ?

Dans Bonux, il y a déjà :
#INFO_TITRE{rubrique,#ID_RUBRIQUE}

où rubrique peut être n'importe quel objet de SPIP, et l'#ID ce qui va avec.

Là, il manquerait juste de pouvoir faire :
#INFO_CHAMP{table, champ, id}

-- RealET

[denisb1 (denisb)]

ça y est déjà (depuis un peu plus d'un an...) !
   http://zone.spip.org/trac/spip-zone/changeset/31574

#INFO_BLABLA(objet, id_objet) retourne bien la valeur du champ
objet.blabla de la ligne id_objet

[davux]

03/12/10, RealET:

Là, il manquerait juste de pouvoir faire :
#INFO_CHAMP{table, champ, id}

Ce n'est pas suffisant, même si ça va en effet dans ce sens.

Si j'en crois le commit suivant, ça me semble être un besoin plus
générique que l'accès aux champs d'une table :

Connexion · GitLab

Du coup il faudrait un mécanisme plus générique que
#INFO_BLABLA{objet,id}.

Mais peut-être que ce cas d'utilisation (appel hors-boucle d'une balise
qui ne soit pas un champ) est très très minoritaire, et que du coup le
coup du #INFO_CHAMP est suffisant.

[RealET]

* denisb tapuscrivait, le 03/12/2010 00:14:

[rastapopoulos]

Ben d'après ce que je vois du code ci-dessus, c'est quasiment la même chose que celui de #INFO_, enfin que celui de generer_info_entite().

Ya une fonction "notation_generer_info" qui prend objet/id_objet, et dedans ya une variable statique $info[$objet][$id] pour pas refaire plusieurs fois la requête dans un même hit. C'est quasiment pareil.

Donc c'est pas "plus générique", et c'est pas tellement éloigné. Ya peut-être moyen de mutualiser des choses. Peut-être que ces balises #NOTATION pourraient ne pas utiliser #INFO_ mais par contre par derrière utiliser generer_info_entite().

[davux]

03/12/10, RastaPopoulos:

Donc c'est pas "plus générique", et c'est pas tellement éloigné. Ya
peut-être moyen de mutualiser des choses. Peut-être que ces balises
#NOTATION pourraient ne pas utiliser #INFO_ mais par contre par
derrière utiliser generer_info_entite().

Oui, la solution que tu proposes serait une manière de généraliser
cette pratique sans trop réinventer la roue, en effet, Ça résoudrait
donc un des deux problèmes évoqués au début.

Par contre, le second, très gênant, resterait : on mélange ces
arguments (objet et id_objet) avec les autres arguments potentiels, et
se pose donc la question de leur place quand on veut mettre les deux.

Prenons l'exemple de #TRUC qui prend un argument optionnel #TRUC{arg1}
(ou plusieurs) :

- #TRUC accepte objet/id_objet, ça donne #TRUC{article,42}.
- Comment se combinent arg1 et article,42 ? #TRUC{arg1,article,42} ?
   #TRUC{article,42,arg1} ? C'est un enfer, autant à parser en tant
   que dev, qu'à comprendre en tant qu'utilisateur, surtout si on prend
   en compte que arg1 ça peut être en fait plusieurs arguments,
   optionnels.

Le problème corollaire existerait également : comment savoir si une
balise donnée accepte ce mécanisme objet,id_objet ? C'est aléatoire si
on laisse chaque balise effectuer le traitement, donc SPIP en prendrait
un coup dans la fameuse courbe d'apprentissage.

Pour ces deux raisons je propose de les séparer syntaxiquement de la
liste des arguments réels. Une approche est d'introduire un nouveau
caractère (beurk), à base de : #TRUC%article,42{arg1}. On peut aussi
réutiliser #article,42:TRUC{arg1}, car c'est une info de contexte tout
comme un nom de boucle.

On peut également se dire qu'on utilise toujours le préfixe #INFO_ et
que objet,id_objet vient au début. Par contre réciproquement il faut
que la balise #INFO_ gère ça systématiquement pour toutes les balises,
je sais pas si c'est facile/faisable.

[cerdic]

moi je comprends pas vraiment le débat, car le générique est déjà pris en charge par la balise #INFO et son filtre generer_info_entite, l'un comme l'autre étant utilisable.
Apres, en ce qui concerne les balises que j'ai commit a la main hier, on ne peut pas les traiter en générique car ce sont potentiellement des infos calculées par une requête sql spécifique.

Cédric

[davux]

03/12/10, cedric.morin@yterium.com:

moi je comprends pas vraiment le débat, car le générique est déjà
pris en charge par la balise #INFO et son filtre generer_info_entite,

Ah je pensais que #INFO marchait juste pour les balises représentant
des champs d'une table (#INFO_TITRE, #INFO_TEXTE, etc.). Si c'est plus
générique que ça, super !

[cerdic]

03/12/10, cedric.morin@yterium.com:

moi je comprends pas vraiment le débat, car le générique est déjà
pris en charge par la balise #INFO et son filtre generer_info_entite,

Ah je pensais que #INFO marchait juste pour les balises représentant
des champs d'une table (#INFO_TITRE, #INFO_TEXTE, etc.).

oui c'est ça

Si c'est plus
générique que ça, super !

heu je sais pas ce que "plus generique" peut vouloir dire là.
en dehors des champs d'une table, une balise est une macro ou un formulaire dynamique.
il n'y a pas de règle qui permette de déterminer quelle balise serait éligible à etre utiliser sur un objet ou non.
#POINTS{objet,id_objet} n'a aucun sens
pas plus que
#FORMULAIRE_LOGIN{objet,id_objet}
ni que
#GET{objet,id_objet}
....

Donc le générique c'est bien ce qui concerne les champs d'une table.
Le reste c'est du cas particulier à traiter au cas par cas.

Cédric

[rastapopoulos]

Non c'est pas ça.

*Par défaut* ça marche juste pour les champs.

Mais on peut ajouter une fonction generer_TRUC_entite() et alors c'est elle qui sera utilisée à la place du champ SQL. Ce champ peut donc très bien ne pas exister, si la fonction existe ça marchera.

Donc oui c'est "générique" au sens où davux l'entend.