Ajouter des valeurs à vos requêtes ORDA génériques

Traduit automatiquement de Deepl

Vous avez sûrement remarqué que les requêtes ORDA ne sont pas seulement légères et lisibles, elles permettent également de naviguer facilement dans l’ensemble du modèle de données en utilisant des concepts orientés objet ! Dans cet article de blog, nous vous avons montré comment écrire des requêtes puissantes et faciles à maintenir. L’une des méthodes recommandées consistait à fournir la requête et les valeurs séparément via des placeholders. 4D v17 R5 va encore plus loin avec les placeholders en vous permettant d’écrire des requêtes ORDA génériques : dites bonjour aux placeholders nommés pour les valeurs !

HDI : Exemple de placeholders nommés pour les valeurs dans les requêtes ORDA.

Ces nouveaux placeholders sont fournis comme paramètres d’objet dans les paramètres de la requête. Comme un objet est une carte clé/valeur, il est très facile de les utiliser dans vos requêtes.

Un exemple vaut mieux que mille mots

Voici une requête pour obtenir un client nommé Charlie avec le client loyal en commentaire. Cela vous rappelle-t-il quelque chose ? Si ce n’est pas le cas, vous devriez consulter cet article pour vous rafraîchir la mémoire.

C_OBJECT($clients)
$clients :=ds.Clients.query("nom = :1 et commentaire = :2" ; "Charlie@" ; "Client fidèle")

La requête peut également être écrite comme suit

C_OBJECT($settings;$clients)
$settings :=New object
$settings .parameters:=New object("givenName" ; "Charlie@" ; "givenComment" ; "Loyal client")
$clients :=ds.Clients.query("name = :givenName and comment = :givenComment" ;$settings)

Il suffit d’utiliser l’espace réservé avec son nom préfixé par « : » .

Votre code est facilement lisible et maintenable, cependant, un avantage encore plus grand est de pouvoir écrire des requêtes génériques dont les paramètres de valeur peuvent provenir de différentes sources (une interface utilisateur ou une requête).

Que diriez-vous d’un modèle comme celui-ci ?

Vous pouvez également fournir à vos utilisateurs une interface de requête où ils peuvent choisir les critères de recherche et les valeurs à appliquer.

Le code ci-dessous est destiné à une interface qui permet à un vendeur de parcourir la liste de ses clients. Elle renvoie un contenu filtré en fonction de l’ID du vendeur.

C_OBJECT$settingsparameters($formData;$settings;$clients)
C_TEXT ($queryString)

$formData :=New object
DIALOG ("QueryEditor" ;$formData)
CLOSE WINDOW

if (OK=1)
//The logged sales person can only browse their clients
$queryString := "salesPersonUserId = :givenUserId"
//The $formData object comes from the user's interface with search criteria filled

//It contains the sales person's user id and some additional search criterias (name and city)

$settings :=New object

$settings .parameters:=$formData

If ( xml-ph-0034@deepl.ingivenName#Null)
$queryString :=$queryString+" and name = :givenName"
End if

If ($settings.parameters.givenCity#Null)
$queryString :=$queryString+" and city.name = :givenCity"
End if

$clients :=ds.Clients.query($queryString;$settings)
end if

Les exemples ci-dessus concernent l’interrogation d’une dataClass, mais si vous consultez la documentation, vous verrez qu’elle est également applicable aux collections !

Comme vous pouvez le constater, construire des requêtes de manière dynamique est un jeu d’enfant. Téléchargez et exécutez l’IDH pour en savoir plus !

Avatar
- Product Owner - Marie-Sophie Landrieu-Yvert a rejoint l'équipe de 4D Product en tant que Product Owner en 2017. En tant que Product Owner, elle est en charge de rédiger les user stories puis de les traduire en spécifications fonctionnelles. Son rôle est également de s'assurer que l'implémentation de la fonctionnalité livrée répond au besoin du client.Marie-Sophie est diplômée de l'école d'ingénieur ESIGELEC et a commencé sa carrière en tant qu'ingénieur chez IBM en 1995. Elle a participé à divers projets (projets de maintenance ou de construction) et a travaillé en tant que développeur Cobol. Elle a ensuite travaillé en tant que concepteur UML et développeur Java. Dernièrement, ses principaux rôles étaient d'analyser et de rédiger des exigences fonctionnelles, de coordonner les équipes commerciales et de développement.