je ne sais pas si c’est un défaut ou une mauvaise mise en œuvre de mon côté:
J’ai un objet hérité par d’autres objets (sous-types de l’objet hérité). Des contraintes de visibilité de champs ont été définies sur l’objet hérité. Ces contraintes fonctionnent bien lors de l’affichage de l’objet hérité mais pas lors de l’affichage des objets héritiers.
Faut-il dupliquer la définition des contraintes dans les objets héritiers?
Question subsidiaire: où puis-je trouver de la doc sur le bon usage des cas d’héritage concernant l’accès à l’objet hérité (super?); les règles d’exécution des hooks de l’objet hérité, etc…
Question habituelle : quelle version/patchelevel/revision.
Pour ce qui est des contraintes je laisse @Francois répondre.
Pour ce qui est de l’accès au methodes du code de l’objet père dans le code de l’objet fils, ça dépend si on est en script Rhino ou en Java.
En Java c’est un super.<methode>(...) classique moyennant de bien faire hériter la classe de l’objet fils de la classe de l’objet père
En script Rhino l’appel aux methodes du père se fait par un <nom de l'objet père>.<methode>.call(this, ...) (le script Rhino des objets père sont visibles des scripts des objets fils)
Exemple:
MyChildObject.postCreate = function() {
MyFatherObject.postCreate.call(this); // Call parent object hook
// do something specific to child object
}
un oubli de ma part:
Simplicité® version 4.0.P19, built on 2018-06-09 15:49 (revision 8d8a4bc8eb25a784affad4e9c95ba2fe65591711) for tomcat 8, encoding UTF-8 (system encoding UTF-8)
Server: Apache Tomcat/8.5.31 of type WEB run by user root, Database MySQL
JVM: 1.8.0_171 Oracle Corporation OpenJDK 64-Bit Server VM 25.171-b10, OS: Linux amd64 3.10.0-693.17.1.el7.x86_64
Merci beaucoup pour la mise à jour de la doc. Mon code est en effet en Rhino.
Je comprends donc dans un premier temps (1) que les hooks de l’objet hérité ne sont pas exécutés par défaut par les objets héritiers et (2) que je dois les appeler explicitement en ajoutant dans le code des objets héritiers les quelques lignes indiquées dans la documentation.
Concernant les contraintes, comment faire en sorte qu’elles s’appliquent aussi aux objets héritiers?
Nb: si je n’utilise pas le concept des contraintes mais que je code ces règles d’affichage/masquage dans les hooks adéquats, la solution précédente devrait permettre de couvrir mon besoin.
Je laisse @Francois répondre sur les contraintes. En effet les contraintes permettent de faire des choses que ne permettent pas les hooks initXxx à savoir s’appliquer sous forme de contrôles de surface coté client (dans la UI responsive de la 4.0 en tout cas).
Par contre la release P19 commence à vraiment dater (plus de 3 mois). Pour information entre la P19 et la P20 il y a eu pas moins de 233 commits (et 417 si on pousse jusqu’au HEAD qui est en instance de devenir la P21).
Oui l’héritage des contraintes existe.
Si un objet Y hérite de X et n’a pas de contrainte, le loader lui applique les contraintes de X.
Il faudrait nous donner plus de précision sur les contraintes de X et Y paramétrées afin qu’on essaye de voir s’il y a une anomalie ou une erreur de paramétrage.
Sur le sujet des hook hérités, la plateforme se comporte conformément à un “override” : il faut appeler les méthodes parentes au sein de la méthode qui la surcharge (au début ou à la fin au niveau du return). La logique est la même qu’en java.