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 :
readOnly
readOnlyPDF
readWriteManager
readWritePDFManager
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!