Template d'un objet héritier depuis une liste d'objet parent

Template d'un objet héritier depuis une liste d'objet parent
0
Tags: #<Tag:0x00007fec58d1c300>

Bonjour,
j’ai un objet A qui possède deux héritiers B et C. A contient les champs communs à B et C.
J’ai deux questions :

  1. Dans ma vue, j’affiche un tableau de A (qui affiche également B et C). Lorsque je clique sur un élément B, j’aimerai que le template de B s’affiche. Actuellement c’est le template de A qui est utilisé. Comment puis-je forcer l’affichage du template ?

  2. Dans mon template B, j’aimerai afficher les champs communs. Lorsque je crée le template de B, la plateforme ne me propose pas les champs du parent. Comment puis-je donc intégrer le template de A dans B ?

Merci d’avance

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-05-12 19:02 (revision e41eff925d436bd9bd5f6282e8d4a624f2046d16)
Encoding=UTF-8
EndpointIP=21.0.9.3
EndpointURL=http://82260c545b1a:8080
TimeZone=Europe/Paris
SystemDate=2020-05-15 13:01:01

Il faut utiliser le hook getTargetObject qui permet de “router” les items d’une liste composite d’objets pères vers les bons objets fils.

Ex: sur une liste de légumes quand on ouvre un record il ne s’ouvre non pas en tant que légume mais en tant que carotte ou que choux

Bonjour
merci pour votre retour. J’ai tenté de mettre votre solution en place sans succès.
J’ai bien mis mon hook dans A. Dans les logs, je constate qu’il me trouve bien B en target.
Par contre je n’arrive pas sur la page d’édition de B. Dois t-il y avoir du code dans la classe B ?

Qu’en est-il de mon deuxième point ? Dois-je redéclarer les champs dans mon objet B afin de pouvoir les afficher ?

Cordialement
Amandine

Bonjour,

Merci d’indiquer le code de votre getTargetObject dans l’objet A.
Il doit bien retourner le nom de l’objet B ou C (en fonction d’un champ type par exemple), l’instance et le row_id (différent de A si B et C ne sont pas dans la même table).

Il n’y a rien à faire de particulier dans B ou C. Il n’est pas nécessaire d’être un héritier pour faire fonctionner le getTargetObject, l’héritage sert juste pour récupérer le paramétrage du père.

Au niveau template, B et C héritent des zones du parent (donc le template doit au moins avoir assez de zones 1,2,3…), puis vous devez ajouter des zones pour positionner des champs supplémentaires, les zones du père ne sont pas modifiables mais vous pouvez déplacer les champs de A dans les zones supplémentaires de B et C (4, 5, 6…).

public class A extends ObjectDB {
	private static final long serialVersionUID = 1L;

	@Override
	public String[] getTargetObject(String rowId, String[] row) {
		if (rowId.equals(ObjectField.DEFAULT_ROW_ID)) return null;
		if (row == null && (rowId.equals(getRowId()) || select(rowId)))
			row = getValues();
		String target = null;
		if (row != null) {
			String type = row[getFieldIndex("RCMRequestType")];
			if (type.equals("MESSAGE") || type.equals("MESSAGE_DEL")) {
				target = "B";
			}
			
		}
		if (target==null) return null; // no redirection
		String t[] = new String[3];
		t[0] = target; // target object
		t[1] = "the_ajax_"+target; // main target instance
		t[2] = rowId; // target id
		return t;
	}
}

Pour le point 2, après divers test, il semblerait que le soucis vienne d’actions provoquant une incohérence pour Simplicité. Je mets le détail si jamais quelqu’un rencontre le même soucis.

Fonctionnement de Simplicité :
je définie A et son template --> le template crée une zone d’attribut A-1
je définie B, héritier de A et son template --> le template crée une zone d’attribut B-2 . Le template est composé de A-1 et B-2

Actions sur mon instance :
J’ai créé B et défini son template --> le template crée une zone d’attribut B-1
Mon modèle évolue et j’ai décidé de faire de l’héritage.
Je crée A et défini son template --> le template crée une zone d’attribut A-1
Je rajoute B, héritier de A. --> depuis le template de B impossible de mettre la zone A-1.
Il a fallu renommer B-1 en B-2.

Merci, je ne vois rien de spécial dans votre code

  • sauf si le type est différent des valeurs données pour aller vers B on restera sur A (le père), on ne va donc jamais vers C.
  • sauf si vos objets B et C ne pointent pas sur la même table physique (row_id incohérent = no record found)
  • et si B et C héritent de A (au sens java dans le code de B : B extends A), ils vont aussi appliquer ce hook hérité, donc à titre préventif on peut filtrer qui cela concerne :
if (!getName().equals("A")) return null; // getName = A or B or C

pour rester sur l’objet si s’agit déjà de B ou C.