Hook initList non exécuté lors de l'action editlist

4.0
Hook initList non exécuté lors de l'action editlist
0.0 0
Tags: #<Tag:0x00007f8b6ac1d3e0>

#1

Bonjour,

Je souhaite filtrer une liste automatiquement avant de la présenter à mon utilisateur qui doit l’éditer ensuite.
Pour ce faire, j’ai du code dans l’initList qui force le searchSpec pour filtrer.
En legacy, ce filtre est effectif lors de l’affichage de la liste puis lors de l’édition en liste.
En responsive, ce filtre n’est effectif que lors de l’affichage de la liste. En mode editlist, la liste n’est plus filtrée…

En débuggant, j’ai vu que
en legacy, le hook initList (server) est exécuté lors de l’affichage de la liste puis lors de l’action “editlist”.
en responsive, ce hook n’est pas exécuté lorsque j’active le mode “editlist”.

Est-ce voulu? Faut-il utiliser un autre hook pour pré-filtrer une liste éditée en responsive ? (un hook client?)

Merci beaucoup pour votre support.
Bruno


#2

Peux tu nous dire sur quelle version (release + revision) tu travaille car il me semble qu’il y a eu des évolutions/corrections sur les initXXX coté UI responsive ces derniers temps.


#3

Bonjour David,

En effet, j’ai reproduit ce comportements sur la version 4.0.P15.

Sur la version 4.0.P16, l’initList est bien exécuté en responsive en mode editlist mais j’ai détecté un autre problème: Dans mon code, je filtre aussi les colonnes horizontalement avec setVisibility(hidden) pour ne montrer que ce que le contributeur doit saisir (ou voir). Les champs d’input sont bien filtrés (seuls les champs non cachés sont montrés) mais l’entête de table liste tous les champs visibles par défaut dans le paramétrage de l’objet.

à nouveau, merci beaucoup pour ton support.
B.


#4

@francois est-ce que ça te dit quelque chose ? Est-ce que les entêtes de colonnes ne seraient pas affichés sur la base de meta données recupérées avant l’application du initList ?

@bmo peux tu tester ce cas sur ton instance http://renault.dev.simplicite.io qui est à jour des tout derniers devs poussés (= version 4.0.P17b du jour)

NB: Pour mémoire au niveau Docker nous publions une image “nightly” (simplicite/platform:nightly) elle aussi à jour des tout derniers devs poussés


#5

Bonsoir David,

j’ai livré “à l’arrache” la conf nécessaire pour reproduire le cas.
Tu peux utiliser le user Test1 (tu peux faire un reset du mdp).
La page d’accueil du user affiche une liste filtrée (en records et en colonnes).

  • En legacy, l’activation du mode editlist fonctionne bien : les filtres /masquages de colonnes sont bien effectifs y compris dans les entêtes de la table => sur les 5 records de la liste, seuls les records d’id 1,4 et 5 sont listés.
  • En responsive, lors de l’activation de mode editlist, les filtres ne sont plus pris en compte (l’ensemble des 5 records des affiché avec les champs d’input et les entêtes de colonne ne sont plus filtrées non plus).

#6

La legacy a été rodée pendant 10 ans, l’autre à 1 an et ne passe pas du tout par les mêmes couches de présentation, il y a des cas d’usage qui marchaient avant mais pas forcement pour de bonnes raisons qui ont conduit à son remplacement.

Ceci étant dit, les init sont sensés être appelés en fonction du contexte.
A mon avis, dans votre cas de edit-list, on est dans un ambiguïté de contexte = à la fois en liste et en update = faut il appeler initList ou initUpdate ?

Le mode edit-list force l’affichage des champs étendus en liste.
mais je ne vois pas pourquoi ça ne prendrait pas en compte les metadata si elles sont bien actualisées.

A priori votre code est à mettre sur le initList (liste en lecture) et le initUpdate (liste en modif). Les API ne supportent pas 2 contextes à la fois.

Ce n’est pas une anomalie, c’est un choix de passer par l’initUpdate lors d’un edit-liste pour mutualiser les regles de mise à jour sur la liste et le formulaire.

ou le mettre dans le preSearch pour être indépendant du context UI.


#7

Bonjour François,
merci beaucoup pour cet éclairage.
Nous utilisons déjà le code initUpdate pour appliquer quelques règles (OK côté legacy & responsive).
Je vais reboucler en interne pour déterminer les meilleures options. La piste du preSearch semble intéressante.
Cdlt


#8

Bonjour François,

j’ai testé avec le hook preSearch() : il semble que le filtre additionnel précisé dans le paramétrage (zone Recherche/filtre additionnel) ne soit pas pris en compte (console.log(getSearchSpec) affiche “1=1”).

Dans les hooks initList et initUpdate, je retrouve bien le filtre additionnel => J’ai dupliqué le code de l’initList dans l’initUpdate et je retrouve donc bien mes filtres lors de la présentation de la liste et lors de l’activation du mode editlist en legacy et en responsive.

Par contre, en responsive, j’ai toujours des problèmes pour masquer les colonnes en mode editlist: les entêtes de colonnes sont toutes affichées alors que dans la partie “input” (lignes en dessous) seuls les champs non masqués sont affichés.

Autre point que j’ai remarqué:

lors de la première présentation de la liste

  • en legacy: le code initList est exécuté 1 fois et le preSearch 2 fois. Dans les 3 cas, le filtre additionnel est bien pris en compte; les colonnes sont bien affichées/masquées comme attendu.
  • en responsive: le code initList est exécuté 1 fois (parfois 2) puis le preSearch 2 fois, le filtre additionnel est bien pris en compte; les colonnes sont bien affichées/masquées comme attendu.

lors de l’activation du mode editlist

  • en legacy: le code initList est exécuté 1 fois, le preSearch 2 fois et l’initUpdate 3 fois (pour 3 records listés/édités), le filtre additionnel est bien pris en compte; les colonnes sont bien affichées/masquées comme attendu
  • en responsive: le code initUpdate est exécuté 4 fois (pour 3 records listés) et le preSearch 2 fois, le filtre additionnel est bien pris en compte; les colonnes ne sont pas bien affichées/masquées.

Merci encore pour ton support.
Bruno