Bonjour,
J’ai une problématique: alimenter une recherche d’objets via un WebService, afin de remplir des champs de formulaires depuis un référentiel sans avoir des copies à gauche a droite de ce référentiel.
Aujourd’hui, le code qui appelle le webservice est dans le hook postSearch, qui modifie alors la liste de lignes fournies.
En pseudo code:
@Override
public List<String[]> postSearch(List<String[]> rows) {
var listeDiplomes = WebService.getDiplomes();
for (diplome : listeDiplomes) {
rows.add(diplome); // normalement sous forme d'array, je simplifie juste
}
return rows;
}
Cependant, ce système casse la pagination et semble être limité en nombre de ligne (au delà de 500 lignes environ, la recherche est vide).
Auriez-vous quelques indications pour déplacer ce traitement dans un autre hook, afin de récupérer la pagination ?
Le “framework” pour developper un objet métier “service” = un objet métier Simplicité qui interagit avec des webservices distants est ObjectService cf. ObjectService
Mais bien entendu la capacité à paginer de cet objet service dépendra de la capacité à paginer des webservices que vous appelez.
nous avons créer un objet métier car nous avons besoin de faire un mapping avec un autre objet métier.
cette façon de faire fonctionnait très bien en V3.
Nous alimentions notre objet métier avec les 767 diplomessans problème.
En V4, lorsque le nombre de row récupéré est trop important, la liste affichée est vide. Alors que le ws ramène bine la totalité des lignes
C’est fait pour ce genre de choses = manipuler un objet qui n’est pas local mais récupéré via des appels de services. Typiquement pour faire des datamaps ou des liens “meta objet”
Out of the box nous avons 4 types d’objet “service” :
Remote Simplicité object (ObjectServiceSimplicite) = se mappe sur un objet métier d’une autre instance Simplicité
Ok je reproduis bien le problème même pour un objet “normal”, ce n’est donc pas lié au fait d’aller chercher des enregistrements ailleurs.
Passé 500 lignes, la UI n’affiche plus rien en liste, il doit y avoir une limite technique quelque part, même quand le flag “Pagination = non” dans la définition de l’objet.
On va corriger car sur l’ancienne UI legacy, il n’y avait pas cette limite
Mais ça reste dangereux de laisser ouverte la porte du “search” sans limite ou pagination côté UI
Du coup je suis perplexe sur ce qu’il conviendrait de faire = corriger mais laisser tout de même une limite à 500 avec un warning ?
Car en terme UX afficher une liste de plus de 500 lignes n’a pas de sens :
d’une part c’est long à afficher
et en plus on doit scroller sur 50 pages pour retrouver ce qu’on cherche
Ce serait l’idéal en effet, mais le manque de temps se fait ressentir dans ce cas ci. De plus, je n’ai pas trouvé grand chose comme documentation concernant les ObjectService.
Oui l’ObjectService était pratique à l’époque des hooks Rhino, maintenant qu’on peut faire du Java et surcharger les verbes CRUD d’accès aux données (getCount, search, create…), ça revient un peu au même.
En tout cas on a un bien un problème à résoudre pour les objets à “pagination = non” initialement prévu pour les objets à faible volumétrie.
ils ne scrollent pas toutes les pages. la recherche permet de filtrer les diplomes.
en ce qui concerne les temps d’affichage, on n’a jamais eu de pb ni de remarque
Il y avait bien une limite technique du navigateur dans la boucle qui alimentait les lignes de façon asynchrone. Une modification a été faite en V4 et V5 sur les listes pour ne plus brider à 500 lignes s’il n’y a pas de pagination. Ca devrait également améliorer le temps de construction de la liste.
Attention,
il n’y a pas encore de garde fou pour limiter la liste si jamais le back retourne 1M de lignes… Même si vous n’utilisez pas de pagination, il faut au moins contrôler ou limiter ce que retourne votre WS pour éviter de planter le serveur et la UI.
Le garde fou qui viendra dans un second temps consistera surement à forcer une pagination à 500 lignes. Ca ne pourra se faire qu’en V5 car la notion de “min/max rows” de pagination a été ajoutée au niveau d’un objet en surchage des préférences utilisateurs.
Il s’avère que la liste des données en question, nous est fournie par un autre organisme et nécessiterait un traitement supplémentaire pour enlever les choix obsolètes qu’il peut y avoir. Une fois ceci fait, nous devrions avoir moins de 500 lignes dans tous les cas. Du moins je l’espère.
