issue90 #157

Closed
maieul wants to merge 11 commits from issue90 into master
maieul commented 8 months ago
Owner

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)
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)
maieul added 2 commits 8 months ago
maieul changed title from issue90 to [WIP] issue90 8 months ago
Poster
Owner

ping @rastapopoulos et @JLuc pour avis

ping @rastapopoulos et @JLuc pour avis
Poster
Owner

@rastapopoulos un avis ?

@rastapopoulos un avis ?
Collaborator

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 ?
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 ?
Poster
Owner

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

> 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 ?

Du coup ça serait bien d'utiliser le même suffixe pour les deux cas ? explication_dev + options_dev ?
Poster
Owner

quelque chose comme ca

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

?

quelque chose comme ca ``` - options_dev - <nom de l'option> : <explication> ``` ?
Collaborator

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...
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.

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.
Poster
Owner

j'aurais besoin d'un exemple...

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
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 ``` yaml 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 ```
maieul force-pushed issue90 from 4d247be4b9 to ff3acd59a3 8 months ago
maieul force-pushed issue90 from ff3acd59a3 to 2ec0e49742 8 months ago
Poster
Owner

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

Bon, c'est fait. Relecture du code bienvenue.
maieul changed title from [WIP] issue90 to issue90 8 months ago
maieul referenced this issue from a commit 8 months ago
rastapopoulos reviewed 8 months ago
<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)]">
Owner

je sais pas pour quoi c'est cet id mais attention au conflit avec l'autre branche qui supprime l'imbrication et donc rajoute déjà plein de choses sur le fieldset directement

je sais pas pour quoi c'est cet id mais attention au conflit avec l'autre branche qui supprime l'imbrication et donc rajoute déjà plein de choses sur le fieldset directement
Poster
Owner

ca à la rigueur je m'en charge. Je sais plus pourquoi non plus j'ai mis cela dans cette branche :P

ca à la rigueur je m'en charge. Je sais plus pourquoi non plus j'ai mis cela dans cette branche :P
Poster
Owner

ah oui je me rappelle : c'était la seule saisie qui n'avait pas la possibilité du id_manuel. et comme je documentais précisement le id...

ah oui je me rappelle : c'était la seule saisie qui n'avait pas la possibilité du id_manuel. et comme je documentais précisement le id...
maieul closed this pull request 8 months ago
Poster
Owner

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

Intégré. On releasera quand on aura des evolutions fonctionnelles, vu le nb de release faite ces dernières semaines.
maieul referenced this issue from a commit 8 months ago
maieul referenced this issue from a commit 7 months ago
maieul referenced this issue from a commit 7 months ago
This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.