[spip-dev] imbriquer les champs étendus

Salut la liste,
  ce week end, j'ai continué à bosser sur une version personnalisable
de #formulaire_forum et je me suis trouvé confronté à un cas où il
faudrait écrire ça :
  [avant [re-avant(#une_autre_balise)re-apres] (#une_balise) apres]

  Sauf que ça marche pas.
  Du coup, j'ai commencé à réécrire la fonction parser_champs_etendus
pour qu'elle accepte ça. C'est assez chaud à faire et ça nécessiterait
donc des tests intensifs, notamment pour les cas ou il y a des crochets
qui trainent au milieu du html sans être en rapports avec des champs.

  Je mettrai ça dans un recoin de web dès que j'ai un moment, mais
avant toute chose, est-ce que l'idée vous parait sympa ? utile ?

  Elle a l'avantage de ne rien compliquer dans la syntaxe spip,
elle devient plus permissive, c'est tout. Coté php, ma version
ne m'a pas l'air beaucoup plus tordue que le tas de regexp original.
  D'ailleurs, ça m'a amener à penser qu'il serait peut-être utile à
l'occas de revoir le code de inc-calcul-squelette dans un sens plus
grammaire -> parsing -> génération de l'arbre de Texte+Boucle+Champ
  Ça rendrait surement le truc plus souple à maintenir, voire plus
performant.
  Faut juste se coltiner la grammaire et trouver un équivalent php
de lex et yacc :wink:

À+, Pif.

Je ne suis pas sûr que ça soit une bonne idée de compliquer les choses à
loisir.

Optimiser, comme tu le décris dans la seconde partie de ton mail, oui, mais
prévoir des structures aussi complexes que ce que tu décris, pour des cas
ulktra-particuliers, bof (penser à la maintenance du code qui nous oblige à
toujours garder toutes les fonctionnalités des squelettes d'une version à
l'autre... si quelqu'un écrit un "moteur spip" en python, il va s'amuser...)

@ Christian Lefebvre <christian.lefebvre@atosorigin.com> :

  [avant [re-avant(#une_autre_balise)re-apres] (#une_balise) apres]

.../...

  D'ailleurs, ça m'a amener à penser qu'il serait peut-être utile à
l'occas de revoir le code de inc-calcul-squelette dans un sens plus
grammaire -> parsing -> génération de l'arbre de Texte+Boucle+Champ
  Ça rendrait surement le truc plus souple à maintenir, voire plus
performant.

-- Fil

Salut,

  Salut la liste,
  ce week end, j'ai continué à bosser sur une version personnalisable
de #formulaire_forum et je me suis trouvé confronté à un cas où il
faudrait écrire ça :
  [avant [re-avant(#une_autre_balise)re-apres] (#une_balise) apres]
  Sauf que ça marche pas.

Oui, c'est parfois gênant.
Dans le même genre, on ne peut pas mettre une boucle dans le code
conditionnel avant d'une autre boucle
(i.e.: <B_externe>
<BOUCLE_interne(...)> .... </BOUCLE_interne>
<BOUCLE_externe> ...)

  C'est assez chaud à faire et ça nécessiterait
donc des tests intensifs, notamment pour les cas ou il y a des crochets
qui trainent au milieu du html sans être en rapports avec des champs.

C'est le problème en effet... Il faut que le parsing soit le moins
"glouton" possible (greedy).

  Je mettrai ça dans un recoin de web dès que j'ai un moment, mais
avant toute chose, est-ce que l'idée vous parait sympa ? utile ?

Entièrement (si y a pas d'effet de bord ;-)).

  D'ailleurs, ça m'a amener à penser qu'il serait peut-être utile à
l'occas de revoir le code de inc-calcul-squelette dans un sens plus
grammaire -> parsing -> génération de l'arbre de Texte+Boucle+Champ
  Ça rendrait surement le truc plus souple à maintenir, voire plus
performant.

Oui, certainement, mais bonne chance pour faire un parser générique
en PHP (il n'est pas viable de faire ça caractère par caractère,
tu es obligé d'utiliser des regexps).

a+

Antoine.

Bon, au moins c'est le pluralisme qui s'exprime :wink:

Oui, certainement, mais bonne chance pour faire un parser générique
en PHP (il n'est pas viable de faire ça caractère par caractère,
tu es obligé d'utiliser des regexps).

Pour la version 1.7 on pourrait abandonner l'exigence de compatibilité
php3+ereg, et exiger php4+preg, quand même plus puissants.

-- Fil

Le problÚme, c'est que ce genre de trucs devient rapidement tellement compliqué qu'on perd l'intérêt du systÚme de boucle (qui est tout de même la simplicité, à l'inverse de templates Nuke entiÚrement en PHP). Ce que je constate en général quand on rencontre ce genre de problÚme:

- on peut s'en sortir souvent avec une boucle de test. Par exemple, tu veux vérifier que l'article a bien un sous-titre. Alors il suffit d'ajouter un boucle qui teste la présence du sous-titre
<BOUCLE_test(ARTICLES){id_article}{soustitre!=}>
      #SOUSTITRE
</BOUCLE_test>
      Il n'y a pas de soustitre.
<//B_test>

- et dans les cas extrême, ben tant pis, mais en PHP c'est plus facile. Toutes les solutions où le langage des boucles de SPIP devient plus complexe que les tests simples de PHP, c'est que c'est pas bon :slight_smile:

A*

ben ca s'appelle glastnost non ?

ps : <private joke> pif, tu sors ! :-))) </private>

- on peut s'en sortir souvent avec une boucle de test. Par exemple, tu veux
vérifier que l'article a bien un sous-titre. Alors il suffit d'ajouter un
boucle qui teste la présence du sous-titre

  En fait, je suis tombé la dessus dans le cadre de ma tentative de
refonte du champ #FORMULAIRE_FORUM.
  L'idée est d'avoir un truc de ce genre
<form ...>
  [(#FORMULAIRE_FORUM|ff_titre)]
  ..
  [(#FORMULAIRE_FORUM|ff_auteur)]
  ..
  [(#FORMULAIRE_FORUM|ff_texte)]
  ..
</form>

  Mais il faut pouvoir encadrer tout ça d'un test pour savoir si
l'internaute à le droit de poster sur ce forum, selon abonnement,
login ..
  D'où l'idée d'un truc comme ça :
[(#FORMULAIRE_FORUM|ff_autorise)
  <form ...
    [(#FORMULAIRE_FORUM|ff_titre)]
    ..
  </form>
]

- et dans les cas extrême, ben tant pis, mais en PHP c'est plus facile.
Toutes les solutions où le langage des boucles de SPIP devient plus
complexe que les tests simples de PHP, c'est que c'est pas bon :slight_smile:

  Est-ce que cette écriture est si compliqué que ça ? Je parle du point
de vue de la lisibilité du squelette, pas du code qu'il faut mettre
derrière :slight_smile:

À+, Pif.

Oui, c'est parfois gênant.
Dans le même genre, on ne peut pas mettre une boucle dans le code
conditionnel avant d'une autre boucle

  Ha bon ? j'avais même pas remarqué ! c'est que j'en ai jamais eu
besoin :slight_smile:
  Pourtant, dans la partie "après" on peut, non ?

> D'ailleurs, ça m'a amené à penser qu'il serait peut-être utile à
> l'occas de revoir le code de inc-calcul-squelette dans un sens plus
> grammaire -> parsing -> génération de l'arbre de Texte+Boucle+Champ
> Ça rendrait surement le truc plus souple à maintenir, voire plus
> performant.

Oui, certainement, mais bonne chance pour faire un parser générique
en PHP (il n'est pas viable de faire ça caractère par caractère,
tu es obligé d'utiliser des regexps).

  J'y ai plenché hier soir, jusqu'à ce qu'une micro-coupure de courant
me paume le fichier que j'éditais et que j'en déduise qu'il était
temps d'aller au dodo ...
  En gros, c'est clair que c'est pas immédiat, et qu'une solution
vraiment générique est pas réalisable, mais il y a certaines
spécificités dont on peut profiter.

<PrivateJoke>Daffy, si tu me redemandes de sortir, je débarque
  dans ton bureau ;-)</PrivateJoke>

À+, Pif.

  L'idée est d'avoir un truc de ce genre
<form ...>
  [(#FORMULAIRE_FORUM|ff_titre)]
  ..
  [(#FORMULAIRE_FORUM|ff_auteur)]
  ..
  [(#FORMULAIRE_FORUM|ff_texte)]
  ..
</form>

C'est peut-être une mauvaise idée :wink:

  Mais il faut pouvoir encadrer tout ça d'un test pour savoir si
l'internaute à le droit de poster sur ce forum, selon abonnement,
login ..

<?php if (...) { ?>
    #MES BALISES
<?php } ?>

-- Fil

> L'idée est d'avoir un truc de ce genre
> <form ...>
> [(#FORMULAIRE_FORUM|ff_titre)]
> ..
> [(#FORMULAIRE_FORUM|ff_auteur)]
> ..
> [(#FORMULAIRE_FORUM|ff_texte)]
> ..
> </form>

C'est peut-être une mauvaise idée :wink:

  Ben, depuis le temps que plein de gens demandent comment
personnaliser ce formulaire, ça me parait pas complètement idiot comme
façon de faire.
  J'ai pas dit que ce truc allait parser le formulaire généré à chaque
fois, je suis remonté un peu plus haut dans le code, mais c'est un
autre débat.

> Mais il faut pouvoir encadrer tout ça d'un test pour savoir si
> l'internaute à le droit de poster sur ce forum, selon abonnement,
> login ..

<?php if (...) { ?>
    #MES BALISES
<?php } ?>

  Mouais, mais if quoi ? if([(#FORMULAIRE_FORUM|ff_autorise)]) ?
  En fait, c'est vrai que ça devrait marcher ça ... vis a vis du cache,
c'est un peu casse tête, mais j'ai l'impression que ça tient le coup.

À+, Pif.

Pour les aventuriers, voir
http://piif.free.fr/tmp/inc-calcul-squel.php3.txt
  Dedans, il y a la fonction parser_champs_etendus modifiée et juste
avant, la fonction sauter_champs que l'autre utilise.
  Ça vient d'un spip 1.6 mais je ne pense pas qu'il y ait beaucoup de
changement de ce coté là dans les versions suivantes ?
  Il devrait donc suffire de coller ses 2 fonctions à la place
de celle par défaut pour tester. En gros, ça doit faire pile poil
pareil qu'avant sauf qu'en plus, on a le droit de mettre un champ
(étendu ou pas) à l'intérieur des parties avant/après d'un champ
étendu.

  Ça permettra de voir ce que ça donne en entendant de savoir si
le débat "pour/contre cette fonctionalité" arrive à une conclusion.

À+, Pif.