Rendez vos applications Qodly dynamiques et interactives avec les états

Les états jouent un rôle crucial dans la création d’interfaces dynamiques et réactives dans 4D Qodly Pro. Ils vous permettent de contrôler l’affichage et le comportement des widgets en fonction de conditions spécifiques, telles que le rôle d’un utilisateur, ses privilèges ou des données provenant de votre base de données.

Ce blog explore ce concept, présente les différents types d’états et illustre leur utilisation à l’aide d’exemples tirés de l’application Performance Review pour vous aider à comprendre comment les exploiter efficacement.

Application Performance Review

Qu’est-ce qu’un état dans Qodly Studio ?

Un état représente une configuration spécifique d’une page à un moment donné, définissant son apparence et ses fonctionnalités.

Par exemple, un état peut être utilisé pour :

• Afficher ou masquer des éléments en fonction de conditions définies.
• Appliquer des styles spécifiques.
• Ajuster dynamiquement l’interface utilisateur en fonction des rôles, des autorisations ou des données.

Pour une présentation complète, voir la documentation officielle sur les états.

Types d’états dans Qodly Studio

Qodly Studio propose deux types d’états :

état non conditionnel

Un état non conditionnel est appliqué de manière statique, sans dépendre d’une condition dynamique. Il permet d’activer ou de désactiver un widget d’une manière prédéfinie.

Exemple : Afficher un formulaire uniquement lorsque l’utilisateur clique sur un bouton, sans vérifier de conditions supplémentaires.

État conditionnel

Un état conditionnel est basé sur une logique définie par l’utilisateur. Il modifie l’affichage ou le style des widgets en fonction de critères tels que les rôles des utilisateurs ou les valeurs de la base de données.

Exemple : Masquer le bouton « Soumettre » si la tâche est déjà terminée ou activer/désactiver un champ en fonction du rôle de l’utilisateur.

Exemples d’états

Pour mieux illustrer l’utilisation des états, voici deux exemples concrets tirés de l’application Performance Review.

Exemple 1 : Restreindre l’édition en fonction du statut

Dans l’application Performance Review, le statut d’un Review détermine si un utilisateur peut voir ou modifier les données.

• Collaborateur: Les données sont en lecture seule si le statut est Terminé ou Fermer.
• Gestionnaire: Les données sont en lecture seule si le statut est Fermer.
• RH: accès complet aux données, quel que soit le statut.

 

Création de l’état « readOnly

Pour restreindre l’édition des données en fonction du statut d’un Review, nous créons un état spécifique appelé« readOnly« .

Sélectionnez maintenant l’état « readOnly » que vous venez de créer. Pour vous assurer que l’état est actif et qu’il s’agit bien de celui que vous souhaitez modifier, vérifiez que son nom apparaît dans le coin inférieur droit de la zone d’édition de la page.

 

Configurer l’affichage des widgets

Pour chaque widget de saisie, modifiez l’attribut « disabled » à true pour désactiver l’édition du champ

Ensuite, renommez les boutons Edit en View.

Ensuite, masquez les boutons Create et Save en définissant la propriété d’affichage à none.

Appliquez également les mêmes modifications aux boîtes de dialogue modales ouvertes par le bouton View :

• Désactiver les champs de saisie.
• Masquer les boutons d’action Save et Drop.
• Renommez Cancel en Close.

Si un bouton est caché par inadvertance, utilisez le panneau Outline de Qodly Studio pour localiser et corriger la configuration.

Mise en œuvre de la logique d’affichage

L’étape suivante consiste à mettre en œuvre la logique qui active ou désactive l’état « readOnly » en fonction de l’état de la révision et du rôle de l’utilisateur.

Le rôle de l’utilisateur est stocké dans les données de session. Par exemple, un manager a un double rôle : il agit en tant que manager lorsqu’il gère les révisions de son équipe, mais en tant que collaborateur lorsqu’il gère les siennes. Dans la barre de menu de l’application, la sélection de Collaborateur met à jour l’attribut de rôle dans le stockage à « collaborateur« , tandis que la sélection de Manager le met à « manager« .

Nous ajoutons un attribut calculé à l’entité Review :

exposed Function get isReadOnly() : Boolean
  var $status : Boolean:=False
  If (ds.getUserInfo()#Null)

   If ((ds.getUserInfo().role="Collaborator") && (This.ID_Status>2))
    $status:=True
   End if

   If ((ds.getUserInfo().role="Manager") && (This.ID_Status>3))
    $status:=True
   End if
  End if

  return $status

Cette fonction renvoie un message vrai si l’utilisateur ne peut que consulter les données et un message faux s’il est autorisé à les modifier.

Remarque : la fonction getUserInfo() permet d’accéder au stockage de la session.

Lier la condition à l’état « readOnly

Enfin, cliquez sur le bouton Conditions de l’état« readOnly » pour définir les règles d’affichage.

Ajoutez une condition.

 

Saisissez simplement la formule : « selectedReview.isReadOnly is True ».

Avec cette configuration, la page passe dynamiquement du mode lecture seule au mode édition sans nécessiter d’intervention manuelle ou de code complexe.

Exemple 2 : contrôle de la visibilité des boutons en fonction de l’état des données

Dans l’application « Examen des performances », une barre latérale apparaît lorsqu’un examen est sélectionné. Les boutons affichés dans cette barre latérale dépendent de plusieurs facteurs :

• L’état des données est en lecture seule ou en lecture-écriture.
• Si un document PDF est disponible.
• Le rôle de l’utilisateur est gestionnaire, collaborateur ou RH.
• Si le PDF est affiché.

Pour traiter efficacement ces différents cas, nous créons des états pour toutes les combinaisons possibles.

Pour rappel, le rôle est attribué lorsque l’utilisateur se connecte et sélectionne la page RH, Manager ou Collaborateur. Cette information est stockée dans la mémoire de la session. Ce concept sera développé plus avant dans un prochain article de blog traitant de la navigation entre les différentes pages de l’application.

Création d’états pour chaque scénario

Pour garantir une expérience utilisateur fluide, nous définissons des états spécifiques qui contrôlent la visibilité des boutons en fonction des conditions ci-dessus. Chaque état ajuste dynamiquement l’interface pour n’afficher que les actions pertinentes.

Exemples :

 

Enregistrement de conditions réutilisables

Pour simplifier la gestion de l’état et éviter la logique redondante, nous définissons des conditions nommées réutilisables :

• Collaborateur: userInfo.role est « Collaborateur »
• Manager: userInfo.role est « Manager »
• HR: userInfo.role est « HR »
• selected: selectedReview n’est pas Null et selectedReview.pdfDocument est Null
• selectedWithPDF: selectedReview.pdfDocument n’est pas Null
• viewPDF: viewPdf est True
• isReadOnly: selectedReview.isReadOnly est True
• isReadWrite: selectedReview.isReadOnly est False

 

Pour enregistrer les conditions, cliquez sur le bouton « … » et sélectionnez « Enregistrer la condition » dans le menu.

Appliquer des conditions aux états

Grâce à ces conditions prédéfinies, la configuration des états devient beaucoup plus facile. Au lieu de définir manuellement des conditions complexes pour chaque état, nous faisons simplement référence aux conditions enregistrées. Cela garantit la clarté, la cohérence et la facilité de maintenance.

Par exemple, pour définir la visibilité de l’état « readWritePDFManager« , nous définissons les conditions suivantes : selectedWithPDF, isReadWrite et Manager.

A vous de découvrir comment sont configurés les autres états, et si vous avez des questions, rejoignez-nous sur le forum 4D.

Cette approche garantit que l’interface s’adapte dynamiquement aux différents rôles des utilisateurs et aux statuts des Review, offrant ainsi une expérience utilisateur intuitive et efficace.

Conclusion

L’utilisation des états dans 4D Qodly Pro est une approche puissante pour personnaliser l’expérience utilisateur et optimiser les interfaces. En les utilisant efficacement, vous pouvez :

• Adapter la visibilité des éléments en fonction des rôles et des permissions.
• Améliorer l’interactivité et la pertinence des actions disponibles.
• Concevoir des applications robustes adaptées aux besoins réels des utilisateurs.

Pour en savoir plus, consultez notre documentation complète sur les états.

Comment utilisez-vous les états dans vos applications Qodly ? Partagez vos idées ou vos questions sur le forum 4D!