Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

widget media : cacher des champs / filtrer la liste des types de média #1072

Closed
metourneau opened this issue Oct 8, 2020 · 5 comments
Closed
Assignees

Comments

@metourneau
Copy link
Contributor

metourneau commented Oct 8, 2020

Bonjour,

Je suis également en train de voir si l'on peut cacher certains champs dans le composant média et filtrer les types de média en fonction du type de média que l'on souhaite ajouter (exemple : limiter un média à un son d'ambiance => pré-sélectionner audio et éventuellement le cacher).
J'ai développé la partie pour cacher certains champs, on ajoute un paramètre "hide_details_fields" : true au type média, dans ce cas, les champs présents dans "details" seront cachés (techniquement, on décoche détail à l'initialisation et on cache la checkbox).

Entre parenthèse :
D'ailleurs l'initialisation de la widget "bool_checkbox" ne prend pas la valeur du paramètre "value" lorsque celle ci est initialisée avec une fonction :
Dans media-form-definition
displayDetails: { type_widget: 'bool_checkbox', attribut_label: 'Avancé', definition: "Afficher plus d'options pour le formulaire", value: ({ meta }) => !meta.hideDetailsFields, hidden: ({ meta }) => !(meta.details && meta.details.length) || meta.hideDetailsFields },
Dans dynamic-form, ajout de [checked] :
[checked]="formDefComp.value"

A voir aussi comment ajouter un label au checkbox pour l'ergonomie.
Fermer la parenthèse.

Ensuite concernant le filtre de certain média, à l'heure actuelle, la liste est basée sur une nomenclature.
Je me pose la question suivante, le mieux :
1 . serait de créer une nomenclature par type de media
2 . de filtrer la nomenclature en utilisant la table cor_taxref_nomenclature sur le model des espèces
3 . de mettre en dur, dans les paramètres du média, le(s) type(s) que l'on souhaite afficher

@camillemonchicourt
Copy link
Member

Oui ça serait utile de pouvoir utiliser le composant "media", en limitant les types de médias proposés. Je pense pas qu'il faille créer une nomenclature à part, ni se baser sur les limitations taxonomiques car les types de médias n'ont pas de lien avec la taxonomie. Il faut plutôt pouvoir passer un paramètre des types auxquels on se limite, dans la conf du composant.

Et idem pour le fait de pouvoir masquer des champs, ça serait un plus.

PS : Concernant les champs avancés, j'en profite pour noter que la checkbox n'est pas idéale, car une checkbox laisse penser à une information que l'on saisit. Juste un accordéon ou un bouton serait plus pertinent à mon avis.

@joelclems
Copy link
Contributor

joelclems commented Oct 8, 2020

@metourneau

pour les composant cachés, c'est déjà en mis en oeuvre et utilisé dans occtax.
https://github.com/PnX-SI/GeoNature/tree/master/contrib/occtax/frontend/app/occtax-form/counting

(on predefini le champs titre, auteur description) avec l'input defaut de pnx-medias qui donne ces valeur à tous les media de la liste

j'avais fait en sorte que des qu'on renseigne l'input details, le champs hideDetails est visible et à true et les champs présents dans détails sont cachés.
(si detail est vide ou null le champs hideDetail est a false et caché)

pour le choix d'un type de media on peut se servir de value (mais il faut donner le bon id_nomenclature)

Une solution serait de remplacer le composant nomenclature par un composant datalist
le type de fichier du composant file change automatiquement selon le type de media

le composant datalist perment

  • de choisir dans une liste de nomenclature
  • de filtrer cette liste par cd_nom (pour avoir une sous liste de nomenclature)
  • de choisir une valeur par défaut à partir du cd_nom

la configuration serait :

    "id_nomenclature_type_site": {
      "type_widget": "datalist",
      "attribut_label": "Type de média",
      "api": "nomenclatures/nomenclature/TYPE_MEDIA",
      "application": "GeoNature",
      "keyValue": "id_nomenclature",
      "keyLabel": "label_fr",
      "data_path": "values",
      "type_util": "nomenclature",
      "required": true
      "filters": {
        "cd_nomenclature": ["1", "2", "3"]
      },
      "default": {
       "cd_nomenclature": "1"
       }
    },


"id_nomenclature_type_site": {
    },

on pourrait passer au composant media une sous liste de nomenclature et une valeur par défaut

@camillemonchicourt

  • pour l'accordéon je reflechi à comment pouvoir agender les formulaires dynamiques par group ede champs, et cela rentrerai dans ce cadre.
  • pour un boutton on peut rajouter un composant dans les formulaires dynamique

@joelclems
Copy link
Contributor

pour la partie limiter le nombre de type de media

une solution plus simple serait

  • ajouter un input cdNomenclatures au composant pnx-nomenclature (qui permettrai de filter avec les cd_nom )

    • on filtre si cdNomenclatures est non nul et de longueur non nul
    • il existe ce besoin par exemple dans monitoring pour limiter la liste de types de sites
  • ajouter un input mediaTypes aux composants pnx-media(s)

    • mediaTypes assigné a la definition du formulaire en tant cdNomenclatures pour le champs id_nomenclature_media_type

@metourneau
Copy link
Contributor Author

Je suis allé au plus simple, pour le moment j'ajoute l'id_nomenclature_media_type dans l'input default du widget medias. puis je cache la liste déroulante. De cet façon le choix de média est bloqué.
Si j'ai le temps, je réaliserai la modification que tu préconises.

@camillemonchicourt
Copy link
Member

Plutôt que les id des nomenclatures (qui peuvent être différents d'un GeoNature à l'autre) est-il possible d'utiliser les codes des nomenclatures ou de leurs types, justement faites pour être sur des valeurs communes à tous les GeoNature ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants