issue90 #157

Cette PR résoud en partie #90. A savoir pour les options qui se gèrent différement en dev (PHP/SPIP) et en interface humaine (constructeur type formidable/champs extra interface).

En revanche pour les options qui n'existent pas du tout en interface, tel que id/inserer_avant/inserer_apres, j'hésite :

soit dans le .yaml on met des 'non saisies' du type :

saisie: 'nope'
options:
  nom: 'inserer_avant'
  explication_dev : '...'

soit on se dit que comme de toute facon ce sont des options qui existent normalement pour TOUTES les saisies, on peut simplement les mettre en dur sur les 2 pages de doc (celle de l'interface privé de spip et celle pour générer la doc sur contrib)

ping @rastapopoulos et @JLuc pour avis

@rastapopoulos un avis ?

Je ne saisis pas bien les enjeux, mais voici mes impressions, charge à toi d'en faire le tri et bon usage éventuellement :

Avoir des saisies 'nope' ne semble pas génial. Je pige pas bien pourquoi des nouvelles saisies alors que ça qualifie des saisies déjà présentes et que ça semble plutôt devoir être un nouvel attribut.
Que veux tu dire par "en dur" (dans les 2 pages de doc) ? "en dur" = écrit à la main dans le contenu éditorial de la doc, sans passer par les yaml ?

Avoir des saisies 'nope' ne semble pas génial. Je pige pas bien pourquoi des nouvelles saisies alors que ça qualifie des saisies déjà présentes et que ça semble plutôt devoir être un nouvel attribut.

parce que pour l'instant toute la doc des saisies est faites en... décrivant des saisies dans le .yaml

Cela étant, ta remarque me fait penser qu'on pourrait très bien avoir un .yaml de la forme suivante :

titre, description, icone, categorie, comme actuellement
options comme actuellement, qui a une double fonction:
décrire les options dans un constructeur de formulaire (type formidable ou champs extra interface)
defaut, comme actuellement
options_complementaires / docs_complementaires, pour décrire les options qui nécessite une documentation MAIS ne doivent pas être accessible par constructeur.

Que veux tu dire par "en dur" (dans les 2 pages de doc) ? "en dur" = écrit à la main dans le contenu éditorial de la doc, sans passer par les yaml ?

Exactement

Du coup ça serait bien d'utiliser le même suffixe pour les deux cas ?

explication_dev + options_dev ?

quelque chose comme ca

- options_dev
  - <nom de l'option> : <explication>

?

Si c'est "en dur", alors il vaut mieux que ça soit dans un autre article, pour faciliter les actualisations et éviter de perturber l'appel du modele qui récupère la doc (et qui est peut être fragile).

Ensuite par rapport à "- options-dev" vs "en dur" :

en dur c'est centralisé et le mécanisme ne fonctionne pas pour les saisies persos propres à un site (et c'est à la charge de leur dev de documenter, mais dans une bonne part des cas, cette doc ne concernera que lui...)
avec "options-dev" je pense qu'il vaudra mieux que la doc aille dans une page de doc à part (comme pour "en dur") car la doc user est déjà longue et lourde.
"options-dev" c'est le prolongement du concept de "doc générée automatiquement à partir des yamls" alors si ça marche bien c'est intéressant de continuer à creuser ce sillon...

mmh non @maieul je pensais plus à exactement la même chose, juste la racine qui change, et mettre un marqueur (CSS à priori) suivant la racine quand on génère le code final, mais bien fusionner les deux à chaque fois, sans code de génération différent (autre que le marqueur). Car pour les options de dev on veut tout autant dire les valeurs par défaut, un label court et une explication longue, etc, le même détail que les autres.

j'aurais besoin d'un exemple...

bé tout pareil je disais, donc l'exemple c'est littérallement la même chose que ce qu'il y a dans le "options" de base

options:
  -
    saisie: input
    options:
      nom: placeholder
      label: <chaine>
      explication: <chaine>
options_dev:
  -
    saisie: input
    options:
      nom: id
      label: <chaine>
      explication: <chaine>
  -
    saisie: radio
    options:
      nom: optionchoixfermé
      label: Nom humain
      explication: Plus longue
      data:
        choix1: Explication du choix 1
        choix2: Explication du choix 2

Bon, c'est fait. Relecture du code bienvenue.

Intégré. On releasera quand on aura des evolutions fonctionnelles, vu le nb de release faite ces dernières semaines.

 <div class="avec_sous_saisies fieldset[ fieldset_(#ENV{nom}|saisie_nom2classe)][ (#ENV{conteneur_class,#ENV{li_class}})][ (#ENV{type_saisie}|saisie_type2classe)][ (#GET{classe_pliable})[ (#GET{classe_plie})]][ (#GET{classe_onglet})]"[ data-id="(#ENV{id_saisie})"][ data-afficher_si="(#ENV*{afficher_si}|saisies_afficher_si_js{#ENV{_saisies}})"]>
 	#ENV*{inserer_debut}
 	<fieldset>
 	<fieldset id="champ_[(#ENV{id,#ENV{nom}}|saisie_nom2classe)]">