Export conditionnel de champs d'objets référencés par un objet

Support
1

Description

Je souhaite exporter “conditionnellement” les attributs d’un objet référencé par un autre objet.

En gros, je souhaite exporter certains champs d’un objet_2 (affiché en onglet dans le formulaire de l’objet_1), lorsque j’exporte l’objet_1.

Dans le fichier XLS produit, une feuille nommée “objet_2” est bien générée, mais cette dernière ne contient pas tous les attributs que je souhaite y trouver.

En gros, l’objet_2 contient des contraintes/impacts de visibilité sur certains champs, mais je me demandais si ces contraintes étaient “exécutées” lorsqu’on exporte l’objet_1 (référençant l’objet_2) ?

J’avais pensé ajouter un test dans une des contraintes de visibilité de l’objet_2, du style
“export_objet_1” == [OBJECTINSTANCENAME]
mais ça ne semble pas fonctionner…

Merci pour votre aide.

2

Bonjour,

La visibilité d’un champ ne s’applique pas aux exports de données mais à la UI.
Pour jouer sur le caractère visible ou non d’un champ dans Excel/CSV…, il y a sa propriété “exportable”.

Par exemple dans le hook postLoad ou preExport de votre objet

if (isPanelInstance()) // onglet fils ?
   getField("myField").setExportable(false);

Pour préciser de quel objet parent on parle si l’objet fils peut avoir plusieurs pères dans le modèle, on peut aussi utiliser :

isPanelOf("MyParentObjectName", "myForeignKeyName")

à voir si ce verbe fonctionne dans votre cas.

3

Merci pour votre réponse.

Je viens de faire le test en ajoutant des setExportable dans le postLoad de mon objet_2.
Malheureusement et malgré le fait que je passe bien dans ce bout de code, les champs n’apparaissent pas dans l’onglet “objet_2” du fichier XLS généré par l’export de l’objet_1…

Faut-il que les champs soient visibles (en plus d’être exportables) au sens UI ?

4

Ok merci pour le retour,

Ca doit être un peu plus complexe à faire.
On va refaire des tests pour savoir quelle instance fait l’export quand c’est un objet lié dans Excel :
isExportInstance ou isPanelInstance ? getParentObject valorisé… ?
et si l’option “exportable” est bien opérante dans cet objet.

6

Ok vu, en fait les objets liés dans un export Excel ne sont pas des instances d’export comme l’objet principal (isExportInstance), ce sont bien des instances panel (isPanelInstance avec le parent object d’export renseigné), donc le code ne peut pas être mis dans le postLoad (trop tôt, le parent n’est pas encore renseigné), ni dans le preExport (pas appelé).

Exemple dans la démo d’un export de “client”, pour masquer le code client dans l’onglet “commande” :

// DemoOrder
@Override
public List<String[]> postSearch(List<String[]> rows) {
	if (isPanelInstance() && getParentObject()!=null && getParentObject().getName().equals("DemoClient")) {
		AppLog.info("demoCliCode exportable = false", null);
		getField("demoCliCode").setExportable(false);
	}
	return rows;
}

On devra garder l’instance panel pour compatibilité ascendante; Par contre, on va améliorer la recherche en base pour invoquer la méthode searchExport paginée, et non pas un search non paginé, afin de bénéficier des hooks pre/postExport des objet liés.

7

Merci François pour ces explications détaillées !

8

[Message prédéfini]

Nous conseillons aux utilisateurs de marquer comme “solution” la réponse résolvant leur problématique pour permettre au support de mieux suivre les sujets non résolus, et à la communauté de trouver plus facilement la bonne réponse.

Vos messages indiquant une résolution du problème, nous avons réalisé cette opération pour vous.

9

Quand vous serez à jour, il faudra déplacer ce code dans le preExport, ce sera plus lisible.

10

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.