j’ai un besoin de clarification sur l’orchestration d’execution des méthodes “hook” dans les classes qui extends PlatformHooksInterface.
Nous avions historiquement une seul classe PlatformHooks dans un module A, j’ai utilisé la possibilité de créer une autre classe PlatformHooks_ModuleB dans un autre module (B) pour y spécifier un besoin métier.
Steps to reproduce
This request concerns an up-to-date Simplicité instance
and these are the steps to reproduce it:
1.Avoir une classe PlatformHooks
public class PlatformHooks extends com.simplicite.util.engine.PlatformHooksInterface {
@Override
public String preSearchIndex(Grant g, java.lang.String search) {
//Stuff happening here
return search }
}
2.Avoir une classe PlatformHooks_ModuleB dans un module différent qui surcharge la même méthode.
public class PlatformHooks_ModuleB extends com.simplicite.util.engine.PlatformHooksInterface {
@Override
public String preSearchIndex(Grant g, java.lang.String search) {
//Other Stuff happening here
return modifiedSearch }
}
Les 2 méthodes s’executent lors d’une recherche (j’ai l’impression) sans “avoir connaissance” de l’autre implémentation
Pouvons nous prédire que l’ordre de chargement/exécution des classes/méthodes sera toujours le même ? (lié à l’ordre de chargement des modules ?)
Si oui, si on continue avec ma situation, est que la classe PlatformHooks_ModuleB pourrait “recupérer” la requete modifié par la classe PlatformHooks (originel) pour après y appliquer son propre traitement ?
Technical information
Instance /health
[Platform]
Status=OK
Version=5.3.45
BuiltOn=2024-08-18 13:52
[JavaVM]
Version=17.0.12
Vendor=Eclipse Adoptium
VMName=OpenJDK 64-Bit Server VM
VMVersion=17.0.12+7
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
Le PlatformHooks est un singleton donc il ne peut pas y en avoir plusieurs sur une même instance.
Vous devez donc merger vos classes (ou partir sur une implémentation plus complexe/subtile avec un PlatformHook “générique” qui appellerait les méthodes ad hoc de classes partagées de vos modules dans un ordre approprié et en gérant le fait que certains modules peuvent potentiellement ne pas être présents, d’où sans doute le besoin de passer par de la reflection, etc.)
On me souffle qu’il y a effectivement une gestion de multiples platform hooks. J’avoue ne jamais avoir fait ça donc je vais laisser la main sur ce point pour clarifier la manière de faire (y compris en termes d’ordre d’appel de hooks)
Oui on peut avoir plusieurs classes suffixées comme on veut.
Ensuite Simplicité n’a pas d’autre intelligence que d’appeler les hooks de chacun, dans l’ordre alphabétique des noms de script.
Par exemple pour
PlatformHooks1
PlatformHooks2
avec du code
public class PlatformHooks1 extends com.simplicite.util.engine.PlatformHooksInterface {
@Override
public void postLoadGrant(Grant g) {
AppLog.info("PlatformHooks1.postLoadGrant");
}
}
La logique de “merge” entre les réponses des hooks appelés est la suivante :
un hook implémenté une seule fois aura toujours raison
des hooks qui retournent un boolean : logique AND (ex checkMFA, isMenuItemEnabled)
des listes : “merge distinct” de tous les items (ex validatePassword, postSearchIndex)
des string : garde seulement la dernière valeur non null (ex parseAuth)
Donc :
Si un même hook est implémentés 2 fois, mais avec des logiques métier contradictoires (le User doit être “ceci” dans le module 1, puis “pas ceci” dans le module 2), c’est qu’ils n’auraient pas dû être livré sur une même instance ou qu’il va falloir prioriser (en testant la présence de l’autre module…)
Quant à faire des “ponts” logiques entre métier/hooks, à vous de prévoir ça en passant dans des variables de session via Grant get/setParameter pour déterminer lequel des hooks a raison si un paramètre est déjà là… ou les ordonner de façon maline…
Ou enfin “re-centraliser” plusieurs hooks dans un seul d’un module commun
Ceci… est je pense la solution la plus souple.
Nous allons revoir le pattern de code du PlatformHook preSearchIndex pour réinjecter en tant que query pour chaque instance de preSearchIndex l’état courant fourni par le dernière instance exécutée.