[Jean-Rémy]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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