Appel initCreate via BusinessObjectTool

Request description

Bonjour,

J’utilise la méthode getForCreateOrUpdate d’un BusinessObjectTool, mais si mon objet n’existe pas, j’ai l’impression que je ne passe pas dans le initCreate.

Est-ce possible ? Ou ai-je fait une erreur ?

otApp.getForCreateOrUpdate(new JSONObject()
										.put("rciAppIdentifier", irn)
									);

									app.setFieldValue("rciAppName",name);
									app.setFieldValue("rciAppLongName",longName);
									app.setFieldValue("rciAppState", etat);
									app.setFieldValue("rciAppCmdbTechno", techno);
									app.setFieldValue("rciAppSIA", sia);
									app.setFieldValue("rciAppDivision", DIVISION_LOCAL);
									app.setFieldValue("rciAppDescription", description);
									app.setFieldValue("rciAppCriticality", criticality);
									app.setFieldValue("rciAppCmdbUpdated", new SimpleDateFormat("yyyy-MM-dd").format(new Date()));
										
									otApp.validateAndSave();

Merci d’avance pour votre aide !
Emmanuelle

De quelle version et révision parle-t-on ?

Oups

Version=5.2.39
BuiltOn=2023-05-02 12:08

OK.

On va vérifier si on est pas ici dans un cas particulier mais normalement les getForXxx passent dans les initXxx.

Rectification: les BusinessObjectTool.getForXxx ne passent pas par les hooks initXxx() qui restent très orientés UI. Conceptuellement ils correspondent à des select.

Cela dit, il reste toujours possible de les appeler manuellement:

if (obj.getForCreateOrUpdate(...)) {
    ob.initCreate();
    (...)
} else {
    ob.initUpdate();
    (...)
}

On ne peut pas changer le comportement de ces getForXxx sans prendre des risques d’induire des changements de comportements des applications existantes. Par contre il serait envisageable (en 5.3+) d’ajouter des variantes de ces méthodes avec un argument supplémentaire init pour dire explicitement si on souhaite appelle ces hooks initXxx mais ça apporte peu vs un appel explicite comme dans l’exemple ci-dessus.

Bonjour David,

sans vouloir pirater ce fil, je confirme que cette conception “orientée UI” des hooks initXXX induit des contraintes (mais pas nécessairement de problème) dans la conception de nos systèmes de règles métier.

En l’occurrence, nous avons besoin de garantir l’uniformité et la cohérence de l’application des règles métier quel que soit le media utilisé pour opérer le modèle (UI, API, batch, etc…). Dès lors que les hooks initXXX ne sont pas appelés dans les contextes getForXXX ou API, nous sommes contraints d’implémenter nos règles dans le preValidate (standard applicable par défaut) et éventuellement en cas de besoin UI particulier de factoriser l’implémentation de certaines règles dans des fonctions appelées dans les hook initXXX et preValidate.

Si les hook initXXX étaient appelés systématiquement dans tous les contextes (UI, API, getForXXX, etc…) nous pourrions simplifier nos implémentations avec un luxe de choix pour localiser nos règles en tenant compte du moment de l’interaction utilisateur dans le contexte UI (avant avec les hooks initXXX ou après avec le hook preValidate).

Je comprends cependant que ce serait une évolution en rupture avec la logique actuellement supportée. Mais ce serait néanmoins intéressant ;). Cela ouvrirait par ailleurs de nouvelle proposition de valeur par nos API à nos clients “smart front-end” implémentant la logique hypermédia/HATOAS en servant des “proto-ressources” (GET / forCreate / forUpdate) en extension de l’implémentation existante sur les fonctions (annonce des relations/actions du modèle selon les droits alloués à l’opérateur).

Cela dit, on peut tout à fait le faire en prenant en charge les appels explicites à obj.initXXX() dans les contexte API ou getForXXX comme tu l’indiques. Mais ça fait écrire une ligne de code en plus avec un risque qu’on oublie sans s’en rendre compte…

OK du coup je passe le post en feature request pour ajoutre des methodes getForXxx avec appel aux inits optionnels.

C’est potentiellement trop impactant de changer le comportement des getForXxx existants

@bmo ces posts sont là pour être piratés et échanger sur les Feature Requests! :slight_smile:

Il serait intéressant de profiter de cette FR pour mener une réflexion de fond sur les fonctions de BusinessObjectTool. Pourquoi ne pas intégrer dans ObjectDB tous ces tools et deprecate BusinessObjectTool, puisqu’ils sont la bonne pratique?

Voire créer un CoolKidsObject (nom à définir) qui extend ObjectDB, qui adopte complètement la notion d’Exceptions sans créer de problèmes de compatibilité ascendante.

Merci David pour ton retour !
En effet j’ai appelé le InitCreate manuellement. J’ai aussi positionné les valeurs par défaut manuellement car il me semble qu’elles ne sont pas non plus appliquées.
Je comprends très bien les impacts que pourrait provoquer l’ajout de cet appel par défaut si ce n’est pas prévu intialement. Cependant il me semblait que le BusinessObjectTool était l’outil recommandé par défaut quand on manipule des objets, mais si je comprends bien ce n’est pas le cas ? Dans quelles circonstances est-il recommandé de l’utiliser ou non ?

Merci et bonne journée !

Les valeurs par défaut et attributs calculés (au sens du paramétrage) sont bien sensées être positionnés par les getForXxx

On va ajouter les variantes de ces méthodes qui appellent condionnnellement les initXxx

Sinon, la vocation du BusinessObjectTool c’est d’offrir des méthodes simplifiées (ex: validateAndSave) qui renvoient des exceptions en cas de pb. On recommande de l’utiliser car il permet d’écrire du code plus simple et plus lisible.

1 Like

C’est bizarre, je dois écraser cette valeur par défaut quelque part alors, je vais enquêter !

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