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?)
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.
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.
@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
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).
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.
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
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.
il y a plusieurs types de recherche et filtres additionnels sur l’objet et/ou sur les champs. vous ne devez pas utiliser le bon. La search-spec sur l’objet n’est pas la “additive” search-spec qui ne sert que sur une recherche prédéfinie via item de vue. Donnez nous votre code pour analyse.
edit-list : on va faire des tests, car le mode “edit” est une mise à jour qui force certaines visibilités (notamment pas de champ étendu mais il y a peut être d’autres contraintes) avec toutes les méta-data de l’objet , alors qu’une liste est optimisée pour ne charger que les champs visibles.
l’ihm responsive est asynchrone et on n’est plus sur du procédural, un initList peut donc être appelé via un count d’onglet par exemple sur la responsible. Bref on ne peut pas comparer les appels car les usages sont différents.
le preSearch est appelé 2 fois = oui côté serveur avant le “select count” pour savoir comment paginer, puis avant le "select * " de la page courante.
edit-list : déjà expliqué c’est un problème de choix cornélien : initList xor initUpdate = les 2 IHM font chacune la moitié du taff, vous pensez que la legacy est correcte mais non, c’est l’inverse.
Il n’est plus possible de ne pas appeler le contexte initUpdate pour avoir les méta-data de la liste en édition sinon les colonnes ne seront pas celles des lignes (donc 1 appel pour avoir les méta de l’objet en contexte update + 1 fois par ligne), si on ne le fait pas il est impossible d’avoir les mêmes méta des colonnes en contexte liste (on reçoit que les champs visibles en lecture) vs en update (on reçoit toutes les colonnes même masquées pour appliquer les contraintes…).
=> On va devoir créer un CONTEXT_EDITLIST qui appelle les 2 hooks pour les 2 IHMs côté serveur.
Exemple de code qui masque le champ demoSupWebsite de la démo en liste, et l’affiche en édition (de liste ou de formulaire). Il n’y pas de problème d’alignement des colonnes en liste, les 2 contexte ne se croisent jamais car les colonnes de la liste sont bien affichées en fonction de ses lignes en lecture ou non.
package com.simplicite.objects.Demo;
import java.util.*;
import com.simplicite.util.*;
import com.simplicite.util.tools.*;
/**
* Business object DemoSupplier
*/
public class DemoSupplier extends ObjectDB {
private static final long serialVersionUID = 1L;
@Override
public void initList(ObjectDB parent) {
AppLog.info(DemoSupplier.class, "initList", "hide demoSupWebsite", null);
getField("demoSupWebsite").setVisibility(ObjectField.VIS_HIDDEN);
}
@Override
public void initUpdate() {
AppLog.info(DemoSupplier.class, "initUpdate", "show demoSupWebsite", null);
getField("demoSupWebsite").setVisibility(ObjectField.VIS_BOTH);
}
}