Re: Perplexe

[...]

Déjà, le côté sécurité ne semble pas être pris en compte :

 html += f'<tr id="{contactId}" data-xdh-onevent="Select" style="cursor: pointer;">'
 for key in contact:
 html += f'<td>{contact[key]}</td>'
 html += '</td>'

Soit je rate quelque chose, soit il n'y a aucun échappement des caractères <, > et &.

Ils sont échappés lors du traitement de la saisie, avant stockage.

L'élaboration de HTML destiné à être injecté dans le DOM peut se faire de plusieurs manières. La méthode présentée ici est la plus simple et la plus aisément compréhensible, mais nécessite effectivement de prendre quelques précautions.
Sinon, peut utiliser un des nombreux moteurs de template existants, qui prennent normalement en compte ce genre de problématiques.
Concernant le toolkit Atlas, il existe un objet permettant de construire un arbre HTML, ou XML qui est ensuite transformé en HTML à l'aide de XSL, et qui procède aux échappement nécessaires...

Et on perd aussi les retours à la ligne pour la note (il y a 2 lignes dans le textarea, mais une seule dans le tableau).

Là, c'est un effet de bord qui m'arrangeait, vu que ça fait gagner de la place ; du coup, je l'ai laissé :-).

Et sur la partie visibilité des boutons, je suis perdu : pourquoi ajouter/retirer des balises <style> du DOM plutôt que d'ajouter/retirer directement les boutons ?

Les balises style ne sont pas ajoutées/retirées, mais activées/désactivées. Activer/désactiver un bouton aurait visuellement comme effet de le griser, et non pas de le faire disparaître, comme c'est le cas ici.

Ici, l’évènement est un clic sur une ligne du tableau contenant la liste des contacts, évènement auquel a été associée l’action Select via l’attribut data-xdh-onevent.

Je suppose que ça veut dire que l'on ne peut faire cette action qu'à la souris, pas au clavier. Bonjour l'accessibilité !

C'est exact, je n'y ai pas pensé. Il faudrait probablement revoir le code HTML.

Et, franchement pour donner envie, ça aurait été bien de faire quelque chose d'un plus joli. Ce n'est quand même pas très compliqué de prendre un framework CSS comme bootstrap et l'utiliser ici.

Je n'ai jamais utilisé bootstrap, ou un quelconque framework similaire, mais je pense que son utilisation aurait probablement alourdit le programme. Mais je suis d'accord que l'apparence de ce programme est plutôt rustique, on va dire, mais, n'étant pas développeur web, mes connaissances sont plutôt limitées en la matière. Les contributions sont bienvenues...

Je ne suis probablement pas le public visé, mais je trouve que c'est assez difficile de comprendre comment ça fonctionne à la lecture de cet article (probablement, faute de repères par rapport à ce que j'ai l'habitude). Et j'ai l'impression que c'est vite limitant (comme faire des transitions CSS ? de l'infinite scroll ? gérer du routage avec différentes URL ?).

Comme je l'ai indiqué plus haut, je ne suis pas développeur web, ce qui explique sans doute que je n'ai jamais eu de demande de la part de mes clients qui ai nécessité des transitions CSS ou de l'infinite scroll (enfin, je ne crois pas, vu que je n'ai qu'une très vague idée de ce en quoi cela consiste). Maintenant, à supposer que ce ne soit pas possible facilement avec le toolkit Atlas en l'état, il est tout à fait envisageable de le modifier pour remédier à cela.
Concernant le routage d'URL, cela me semble être typiquement une fonctionnalité d'application web. Or, il existe quantité de frameworks qui offrent ce genre de fonctionnalités, et bien plus. L'objectif du toolkit Atlas n'est pas d'être un n^ième framework web, mais d'offrir un moyen simple et rapide de programmer une interface graphique, d'où l'absence de certaines (de la plupart ?) des fonctionnalités que l'on trouvent typiquement avec ce genre de frameworks. Que l'utilisation du toolkit Atlas transforme un programme en application web n'est qu'un effet secondaire...

Zelbinium: pour la génération qui crée, pas celle qui scrolle...