Qodly Studio pour 4D : Interfaces utilisateur dynamiques avec les états de page

Avec 4D 20 R6, Qodly Studio for 4D a introduit une nouvelle fonctionnalité passionnante : Les états de page. Vous avez peut-être déjà lu notre précédent article, mais explorons ce qui rend cette fonctionnalité si précieuse pour les interfaces utilisateur dynamiques.

Imaginez des interfaces utilisateur qui s’adaptent instantanément aux différentes étapes ou contextes d’utilisation.

Voici quelques cas d’utilisation courants dans lesquels les états de page sont indispensables :

  • Activer ou désactiver des composants en fonction des actions de l’utilisateur (par exemple, activer le bouton « Enregistrer » uniquement lorsque tous les champs obligatoires sont remplis).
  • Passer d’un mode clair à un mode sombre par un simple click.
  • Restreindre l’accès aux actions (lecture, mise à jour, etc.) en fonction des privilèges de l’utilisateur.

     

    PIQS_States

    États de page : Une solution dynamique pour les interfaces interactives

    Mais qu’est-ce qu’un état de page ? Un état est défini par la manière dont il diffère de la page Qodly originale, connue sous le nom de page de base, ce qui vous permet de rendre les éléments de l’interface utilisateur visibles sous certaines conditions ou d’appliquer des styles différents en fonction des actions de l’utilisateur. Et tout commence avec la page de base, l’origine de votre interface utilisateur.

    Une nouvelle section « States » permet de gérer les états.

    Commençons par un exemple simple.

    Cette page Qodly comporte une style box avec un arrière-plan transparent. Il s’agit de la page de base.

    blank

    Si vous souhaitez présenter à l’utilisateur une variante de la page de base, créez un nouvel état, sélectionnez-le dans la liste des états et concevez-le.

    Ici, un état Green a été créé pour avoir un fond vert au lieu du fond transparent de la page de base.

    blank

    Un état Purple a également été créé avec un arrière-plan violet au lieu de l’arrière-plan transparent de la page de base.

    blank

    L’objectif est d’activer ou de désactiver un état en fonction des situations rencontrées par l’utilisateur.

    Sur une page Qodly, vous pouvez créer autant d’états que nécessaire en fonction des cas d’utilisation que l’utilisateur final rencontrera.

    Plusieurs états peuvent être activés simultanément.

    Comment activer ou désactiver les états ?

    L’activation ou la désactivation d’un état peut se faire de trois manières :

    1. En utilisant des actions standard
    2. Par l’intermédiaire d’une condition
    3. À partir de code exécuté sur le serveur

     

    les actions standard de l’état

    Grâce aux actions standard, vous pouvez activer/désactiver des états lorsque l’utilisateur interagit avec la page.

    Dans l’exemple ci-dessous, l’interface utilisateur propose des modes clair et foncé. L’état Light gère le mode clair avec une classe CSS lightMode.

    blank

    et l’état Dark gère le mode sombre avec une classe CSS darkMode.

    blank

    La page de base est présentée ci-dessous. Lorsque l’utilisateur clique sur l’icône Light, l’état Light est activé et l’état Dark est désactivé.

    blank

    (Et vice-versa lorsque l’utilisateur clique sur l’icône Dark : l’état Dark est activé et l’état Light est désactivé).

    Voici le résultat final.

    blank

    états conditionnels

    C’est ici que la vraie magie opère. Les états peuvent être liés à des conditions, ce qui permet à l’interface utilisateur de répondre à des critères spécifiques tels que les privilèges de l’utilisateur ou la valeur des données. L’état est activé ou désactivé dynamiquement en fonction de l’évaluation de la condition (VRAI ou FAUX).

    Dans cet exemple, l’interface utilisateur présente une liste de produits et une section Détails du produit qui permet de mettre à jour le nom du produit sélectionné.

    Deux états ont été créés :

    • l’état ReadOnly (lecture seule)
    • l’état Update

    blank

    Il est facile de le deviner : l’état Update est nécessaire lorsque l’utilisateur peut mettre à jour le produit sélectionné, tandis que l’état ReadOnly est nécessaire lorsque l’utilisateur ne peut que consulter les données du produit.

    Voici l’état Update. Dans la section Détails du produit, le champ Nom est actif et il y a un bouton Enregistrer.

    blank

    Et voici l’état ReadOnly. Dans la section Détails du produit, le champ Nom est inactif et il n’y a pas de bouton Enregistrer.

    blank

    Les états ReadOnly et Update sont tous deux liés à une condition. La possibilité de mettre à jour un produit dépend de l’attribut de updatable du produit sélectionné.

    L’état ReadOnly est activé si la condition theProduct.updatable = false. L’état Update est activé si la condition theProduct.updatable = true.

    blank

    blankVoici le résultat final.
    blank

     

    Grâce à l’éditeur de conditions puissant et convivial , vous pouvez créer des conditions imbriquées pour gérer la logique métier la plus complexe !

    Ces conditions peuvent être basées sur des critères tels que les valeurs des sources Qodly, le fait que la session dispose ou non de certains privilèges, etc. Consultez la documentation pour en savoir plus.

    Gérer les états sur le serveur

    La dernière chose dont il faut être conscient est que l’activation/désactivation des états à partir du code du back-end peut être utile lorsque certaines règles métier ne peuvent être évaluées qu’au niveau du back-end.

    Dans la démo ci-jointe, vous verrez un exemple de ceci. L’utilisateur sélectionne des produits. Lorsque le montant total des produits sélectionnés est supérieur ou égal à 300 $, un état empêchant toute sélection de produits est activé.

    Ceci est possible grâce aux fonctions Web Form.enableState() et Web Form.disableState().

    Voici le code ci-dessous. L’état LimitReached désactive toute sélection de l’utilisateur.

    	If ($tempSelection.sum("price")>=300)
    		Web Form.enableState("LimitReached")
    		Web Form.disableState("Initial")
    	End if 

    Voici le résultat final.
    blank

     

    Vous voulez le voir en action ?

    Téléchargez la démo Play In Qodly Studio ci-jointe pour apprendre à utiliser les états de page et à offrir une interface dynamique à vos utilisateurs finaux.

    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.