Erreur sur une action d'un autre Objet

Tout à fait d’accord la dessus mais mon action pointe bien sur NamJeune, je ne pense pas avoir fait d’erreur , du moins je pense :



En phase, je pense qu’il faut créer la méthode openDemandeRenouvellementSoutientAvenant dans votre objet NamJeune et non pas NamContratAvenant. Mais je ne sais pas exactement quel est le besoin de qui doit porter cette action.

Si votre action est utilisée sur plusieurs fonctions dans plusieurs objets, il faut que chacun d’entre eux implémente la méthode back. Si celle-ci est identique, utilisez un héritage pour factoriser la méthode ou une classe partagée.

Si vous faites une Action front, idem le SCRIPT front doit être implémenté dans chaque objet qui utilise l’action.

Merci,
quel est le paramétrage des fonctions de votre objet NameCandidat ?
car c’est lui qui semble bien porter l’action également, sans avoir la méthode implémentée.

voila la configuration de NamCandidat :

pour le code je vous laisses regarder dans le code que l’on vous as envoyé ça sera plus simple

En regardant le code source envoyé, la méthode dans NamJeune.java s’appelle :
“openDemandeRenouvellementSoutientAvenantForm”

et non pas ce qui est paramétré sur l’Action :
“openDemandeRenouvellementSoutientAvenant”

Pouvez-vous vérifier ?

Je vais regarder la log Simplicité car elle n’est pas très clair.

oui en fait j’ai modifié le nom depuis, pareil pour le nom de l’action il a peut-etre changé par rapport a la version que vous avez recu. C’est parceque j’ai fait le test de supprimer la fonction et l’action, de changer le nom de la méthode en java, et de tout refaire en faisant des clear cache entre 2.

Ok merci. la log est également correcte.

  • Simplicité cherche bien la méthode dans l’objet NamJeune
  • Mais il y a un problème étrange car NamJeune a chargé la classe de NamCandidat

Le this.getClass() de votre objet NamJeune instancié retourne la classe com.simplicite.objects.name.NamCandidat au moment où l’action est invoquée par reflection.

On va devoir passer votre implémentation au debugger car je n’ai jamais vu ça, il y a forcement un truc louche lors du chargement de l’objet pour se “tromper” de classe.

Est-ce que par hasard l’attribut “Class” de l’un ou l’autre de vos objets est renseigné ?

Non pour les deux ( NamJeune et NamCandidat ) cet attribut est vide

Suite à installation en local de vos modules :

  • Il y avait un problème de compilation du PlatformHooks sur une 5.1 (latest). La classe PlatformHookInterface a changé de package, on a ajouté un wrapper pour compatibilité ascendante de l’implémentation. En 5.0 (beta) il n’y a normalement pas de problème à ce niveau.

  • Il y a quelques problèmes pour créer des entités avant d’arriver au “Jeune”. Il faut nécessairement une base postgreSQL sinon ça ne marche pas bien (il y a des entiers configurés en taille 100 ou 200 notamment qui tombe en erreur SQL, je ne vois pas bien le besoin d’une telle taille).

Je vais réinstaller sur base PostgreSQL et je vous tiens informé.

@Francois je suis en train d’installer une instance sur l’image Docker “5-beta” avec la version de PostgreSQL la plus proche de celle qu’ils utilisent. On sera alors au plus proche de ce qu’ils ont déployé. Je te tiens au courant quand c’est prêt

Je pense avoir trouvé, le problème semble lié au paramétrage de vos héritages.

public class NamCandidat extends NamJeuneCandidatCommon

Mais cet objet est paramétré pour hériter de NamJeune

il faudrait donc plutôt que votre classe Java suive cette logique pour forcer Simplicité à utiliser la bonne classe :

public class NamCandidat extends NamJeune

puisque NamJeune n’hérite d’aucun objet métier, juste d’une classe commune :

public class NamJeune extends NamJeuneCandidatCommon

J’ai fait la modification et plusieurs tests et cela fonctionne, merci :)

Est-ce que vous avez une idée de pourquoi ce problème apparait maintenant ?
Cette portion de code et de paramètrage n’ont pas évolués depuis pas mal de temps

Pas facile de comprendre effectivement sans tracer ce que faisait le URLClassLoader, mais je pense que ça doit être lié à l’ordre de chargement des classes. Si on utilisait Jeune ou Candidat en premier, le comportement devait être différent lors de l’instanciation en mémoire.

En héritant explicitement de la bonne classe, il ne devrait plus y avoir de doute. Vérifiez vos autres héritages.

En tout cas, on utilise souvent l’héritage d’objet (à plusieurs niveaux pour factoriser des attributs, pour segmenter des accès par rapport un statut ou un type…) et on n’avait jamais vu ce genre de comportement d’inversion de classe.

PS:

En complément cf. une de mes réponses précédentes => si votre action est purement UI il faut la configurer comme une action “front” avec une URL qui appelle du JS client (javascript:...), c’est inutile de solliciter le serveur pour retourner un simple statement statique JS qui s’exécutera in fine coté client.

Les seuls cas où il est éventuellement nécessaire d’avoir une action serveur c’est si le statement JS en question est dynamique (= dépend de choses qui n’existent ou qui ne sont accessibles que coté serveur). Dans votre cas ce n’est pas vraiment le cas.

en fait ce choix correspond au problème décrit dans ce ticket :

Le cas où une action retourne un statement JS généré dynamiquement coté serveur (return javascript(...)) est fréquent.

Dans le cas précis que vous indiquez c’est à priori du JS totalement statique que renvoie votre action (à part une constante à priori statique Java). Mais il me manque peut être des infos pour bien cerner votre cas.

En tout cas quand il s’agit de ne faire que du JS coté client il est préférable de faire une action purement front pour ne pas solliciter le serveur pour rien.

Pour mémoire, le pattern où on renvoie une URL genre HTMLTool.getFormURL(...) est un pattern legacy hérité de l’ancienne UI des version 3.x, il continue à marcher car on a fait ce qu’il faut coté client pour “traduire” à la volée ces URLs legacy en appels JS mais c’est à considérer comme “deprecated”.

Pour mémoire l’ancienne UI avait été conservée en 4.0 pour laisser le temps au clients de basculer sur la nouvelle, mais en version 5 elle a définitivement disparue, tout ce qui lui est associé finira donc par disparaitre un jour.

Petite précision :

Même pour une action de type “front” contenant juste un javascript, il y a un “save” envoyé au serveur. Toute action commence par un save du formulaire, pour aligner les données en front et en back (surtout appliquer un validate sur les données) avant de réaliser l’action elle-même sur des données fiables (appel de méthode java ou javascript front).

  • Si vous voulez faire une action totalement front (sans auto-save + validate), il faudra ajouter un bouton sur le template et implémenter directement le click, sans modéliser une action.
  • S’il faut une action pour utiliser les habilitations, alors il faudra écraser le handler par défaut dans le SCRIPT form.onload via $("[data-action='myaction']").off("click").click(...).