Power Apps – Règles de nommage des contrôles

Étiquetté : ,

  • Power Apps – Règles de nommage des contrôles

    Posté par R3dKap sur 4 octobre 2022 à 17h01

    Comme je vois régulièrement fleurir de-ci de-là des questions sur la bonne pratique en termes de nommage des contrôles dans ses applications Power Apps, je vous propose ci-dessous les règles que j’applique depuis pas mal de temps à mes propres applications.

    Ces règles s’appuient sur le Power Apps canvas app coding standards and guidelines de Microsoft, avec quelques retouches personnelles que je considère comme des améliorations ou des facilités que j’ai mis en place au fur et à mesure de mes expériences. Celles-ci sont bien sûr ouvertes à tout débat… 😉 N’hésitez pas à donner votre avis…

    Les écrans

    Nom de mon écran

    👉 Nom clair et parlant pour ce qu’il contient, pas d’abréviations

    J’étais parti au départ pour une nomenclature plutôt technique pour les écrans mais suite à des retours et des confirmations vues ailleurs, il s’avère que les noms des écrans sont lus par les lecteurs d’écrans pour les personnes en difficulté visuelle. Il est donc important que celui-ci soit le plus clair possible, quitte à ce qu’il soit un peu long.

    Exemples :

    • Accueil

    • Liste produits

    • Edition client externe

    Note : cela impliquera, dès lors qu’il contient un espace, de l’entourer d’apostrophes dans vos formules Power Fx.

    A chaque écran va correspondre un code (en majuscule) sur 2, 3 ou 4 caractères au plus afin de suffixer les contrôles qu’il contiendront (voir ci-après).

    Les contrôles

    xxxMonContrôle_YYY (xxx=type de contrôle, YYY=code écran)

    👉 Pas d’espace, pas de caractères spéciaux, caractères accentués autorisés

    RAPPEL : un contrôle doit avoir un nom unique dans l’ENSEMBLE de votre application -> 2 contrôles ne peuvent avoir le même nom sur 2 écrans différents.

    Pour cette raison, il est recommandé d’utiliser systématiquement un code écran en suffixe du nom de vos contrôle pour identifier clairement leur localisation dans l’application. Je l’invente en fonction du nom de l’écran : ACC pour Accueil, LP pour Liste produits, ECE pour Edition client externe, …

    J’utilise les préfixes suivants pour les types de contrôles :

    Les plus utilisés

    lbl = Etiquette (Text label)
    btn = Bouton (Button)
    txt = Entrée de texte (Text input)
    cbx = Zone de liste déroulante (Combo box)
    ddl = Liste déroulante (Drop down)
    dat = Sélecteur de dates (Date picker)
    lbx = Zone de liste (List box)
    chk = Case à cocher (Check box)
    rad = Case d’option (Radio)
    tog = Bascule (Toggle)
    gal = Galerie (Gallery)
    sli = Curseur (Slider)
    tim = Minuteur (Timer)
    frm = Formulaire Modifier/Affichage (Edit/Display form)
    dc = Datacard (dans un formulaire)
    ctr = Conteneur (Container)
    lay = Conteneur horizontal/vertical (Horizontal/Vertical container) *
    img = Image
    cmp = Composant (Component)
    ico = Icône (Icon)
    rec = Rectangle
    cir = Cercle (Circle)
    htm = Texte HTML (HTML text)
    rte = Editeur de texte enrichi (Rich Text Editor)
    cam = Caméra (Camera)

    * Car en réalité il s’agit (en anglais) de Layout Containers

    Les autres

    pen = Entrée du stylo (Pen input)
    rat = Evaluation (Rating)
    adr = Entrée d’adresse (Address input)
    tab = Table de données (Data table)
    bar = Scanneur de codes-barres (Barcode scanner)
    vid = Vidéo (Video)
    aud = Audio
    mic = Microphone
    pic = Ajouter une image (Add picture)
    imp = Importer (Import)
    exp = Exporter (Export)
    pdf = Visionneuse PDF (PDF viewer)
    map = Carte (Map)

    Les variables

    xxxMonNomDeVariable[_YYY] (xxx=type de variable, YYY=code de l’écran, facultatif)

    👉 Pas d’espace, pas de caractères spéciaux, caractères accentués autorisés

    J’utilise les préfixes suivants pour les types de variables :

    glo = variable globale définie avec Set()
    loc = variable locale définie avec UpdateContext()
    col = collection définie avec ClearCollect()

    Le suffixe facultatif _YYY me sert principalement à identifier une collection que je n’utilise que sur un écran en particulier. Ainsi, si je vois une collection suffixée avec un code d’écran je sais qu’elle n’est utilisée que sur cet écran là…

    Les composants

    MonNomDeComposant

    👉 Pas de préfixe, pas d’espace, pas de caractères spéciaux, caractères accentués autorisés

    Pour les contrôles, même nomenclature que sur les écrans mais où le suffixe YYY représente le code du composant.
    Par exemple, pour un composant ActiveEasyTheme -> togMonToggle_AET, pour un composant ActionPopup -> cbxMaComboBox_AP, …
    Et je m’assure qu’il n’y a pas déjà un écran avec le même suffixe…

    Voilou… 😉

    PostID=rBXRms6gmFVcdT5

    DavidZed a répondu Il y a 2 mois, 3 semaines 1 Membre · 10 Réponses
  • 10 Réponses
  • Jean-Rémy

    Membre
    6 octobre 2022 à 10h55

    Merci pour ce partage, j’aurais quelques questions :

    • je vois deux fois cbx (check box et combo box), est-ce volontaire ? Personnellement j’utilise chk pour Checkbox

    • Est-ce que tu utilises une nomenclature particulière pour les named formulas ?

    CommentID=YVGkNexRK5RpnAL, PostID=rBXRms6gmFVcdT5

  • R3dKap

    Membre
    6 octobre 2022 à 12h30

    Salut Jean-Rémy Gallapont,

    Avec plaisir 😊

    Merci pour la coquille sur la check box : j’utilise aussi “chk”… 😉 C’est corrigé !

    Pour ce qui est des Named Formulas je ne me suis pas encore penché sur le sujet vu qu’il vient de sortir. Mais je ne manquerais de le rajouter dans les jours/semaines à venir… 🙂

    CommentID=utzmUM2u2cUkcRn, PostID=rBXRms6gmFVcdT5

  • R3dKap

    Membre
    6 octobre 2022 à 12h42

    Jean-Rémy Gallapont comme ça au premier abord je partirais bien sur une nomenclature simple au format Pascal Case comme cela est donné en exemple dans l’article de blog qui annonce la feature :

    Mais en même temps, toujours pour le côté pratique de pouvoir cibler des objets ou variables bien précises dans l’intellisense de l’éditeur de formules, je préfixerais bien les Named Formulas avec nf par exemple…

    Ceci étant, vu qu’une Named Formula varie automatiquement dans le temps sans que l’on aie besoin de la redéfinir (contrairement à Set() et UpdateContext()), il me semble que le mot “variable” prend alors tout son sens. Et du coup je me dis que je les préfixerais bien avec var

    Qu’en penses-tu ? Qu’en pensez-vous, les autres 😁 ?

    CommentID=NpUwpKtoV92mjHY, PostID=rBXRms6gmFVcdT5

    • Jean-Rémy

      Membre
      10 octobre 2022 à 9h21

      R3dKap Pour le moment j’ai fais le choix de ne pas préfixer mes named formulas mais de les écrire avec une majuscule au début de chaque mot. Par exemple “NumberOfRegisteredUsers”

      C’est un choix que j’ai fait (au moins temporairement) car une formule nommée n’est pas un composant donc je ne vois pas de raison de lui mettre un préfixe. On se rapproche ainsi de la nomenclature d’accès aux propriétés des sources de données ou collection.

      SubCommentID=qBWC8kdVvB96qXX, CommentID=NpUwpKtoV92mjHY, PostID=rBXRms6gmFVcdT5

  • Alexandre

    Membre
    7 octobre 2022 à 21h37

    Je valide la plupart des points à l’exception des noms d’écrans. En effet ceux ci sont énoncés par les liseuses d’écran comme étant le titre de ton écran, et si tu nommes ton écran scrNomDeMonEcran je te laisse imaginer à quel point ca risque de ne pas beaucoup aider les utilisateurs… (et pour info bon nombre d’entreprises ont des obligations légales vis à vis de l’accessibilité numérique)

    https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/accessibility-checker#:~:text=Revise%20screen%20name,the%20screen%20reader.

    CommentID=4YErZikyezdL7F0, PostID=rBXRms6gmFVcdT5

    • Jean-Rémy

      Membre
      10 octobre 2022 à 9h34

      Alexandre Perret je comprend bien l’importance de prendre en compte l’accessibilité pour adresser les end users, d’ailleurs il serait bien que Microsoft puissent permettre de distinguer le nom technique de l’écran du nom end user (pour l’accessibilité)

      Est-ce que tu as eu le cas où les makers avaient besoin d’une prise en compte de l’accessibilité pour pouvoir utiliser l’environnement de création Power Platform ?

      Car dans une approche Citizen Dev, finalement offrir un environnement de création accessible est aussi important que l’accessibilité pour les end users. Je ne sais pas du tout à quel point https://make.powerapps.com/ le permet

      SubCommentID=h12BYZJHzHVjbpL, CommentID=4YErZikyezdL7F0, PostID=rBXRms6gmFVcdT5

    • Alexandre

      Membre
      10 octobre 2022 à 19h48

      De ce que j’en sais, Microsoft fait les choses plutôt bien pour l’accessibilité. Rares sont les points à peaufiner pour que l’app soit le plus accessible possible, tandis que d’autres ne sont tout simplement pas accessibles car les composants ne le sont pas (le calendrier je crois, mais aussi les galeries utilisées en guise de table…) Après dans certaines entreprises c’est une obligation légale, à minima d’afficher un rapport d’audit sur l’accessibilité, et si des fonctionnalités ne sont pas accessibles, il est obligatoire d’indiquer ce qu’il ne l’est pas.
      Donc oui, c’est pas toujours simple pour des citizens de, à la fois, faire une application qui fonctionne, qu’elle soit optimale, et qu’elle soit accessible… Dans ma boite, on a des tas d’applications qui naissent chaques jours, et pour celles jugées plus utiles (ou plus rentables) elles arrivent parfois dans les mains des équipes de dev internes pour industrialisation. Et malheureusement dans ces cas là c’est plus compliqué quand il faut tout reprendre pour que ca soit ‘mieux’

      SubCommentID=Q4nDrKe58khoEFm, CommentID=4YErZikyezdL7F0, PostID=rBXRms6gmFVcdT5

  • R3dKap

    Membre
    9 octobre 2022 à 19h54

    Je te suis Alexandre Perret et je met à jour l’article… Car c’est en effet une recommandation que j’ai vu ailleurs…

    CommentID=VoF1jTIn8ScFPSV, PostID=rBXRms6gmFVcdT5

  • Alexandre

    Membre
    24 octobre 2022 à 22h16

    En plus de tout ca, j’aime rassurer les équipes en leur disant qu’il est inutile de renommer l’intégralité des contrôles !
    En effet je ne renomme que les contrôles qui m’aident à m’y retrouver dans l’arborescence (les containers notemment) et les contrôles que je dois manipuler par le code pour éviter les fonctions incompréhensibles à débugger (TextBox1.Text & ” ” & TextBox1_8.Text …. ) : Un contrôle utilisé dans la moindre formule : je le renomme immédiatement en respectant les conventions

    CommentID=w7SG2SS7au2t4mj, PostID=rBXRms6gmFVcdT5

  • DavidZed

    Membre
    10 novembre 2022 à 16h45

    Pour ma part je m’astreins à ce que mes contrôles aient en préfixe le nom par défaut : InputText, ComboBox, Gallery, Button etc….

    • 👎 L’inconvénient :

      • Ca n’aide pas à raccourcir le nom des contrôles 😢

    • 👍 Les avantages :

      • Le côté universel: En effet, le nom généré est toujours le même quel que soit le langage. donc quand quelqu’un reprend une app que j’ai développé, s’il cherche un type de contrôle, il sait automatiquement quoi mettre pour le trouver, il n’a pas à chercher quelle règle de nommage j’ai pu employer.

      • Comme c’est le nom par défaut: gain de temps à renommer entièrement le contrôle, mettre un préfixe etc…

      • Et pas de risque de faute de frappe 🧐

    CommentID=G5Wvuq9dAtnYG2Q, PostID=rBXRms6gmFVcdT5

Connectez-vous pour répondre.