J'ai testé et compris le concept

J'ai récemment dév un outil utilitaire et le "portage" sur Atlas a été un bon test.

Mon outil fait la chose suivante :

1. il prend un fichier JSON sur tracim, en extrait des données et les formate en markdown
2. il affiche une interface utilisateur permettant de rectifier le markdown si nécessaire
3. il publie le markdown en tant que message sur notre messagerie instantanée (mattermost) à l'appui sur le bouton "publish"

C'est un script python/tkinter, le rendu est le suivant :

Version python/tkinter

La version python/atlas/html a été faite en bricolant l'exemple HelloWorld fourni avec Atlas. Le rendu est le suivant :

Version python/html/atlas

Au final, je vois un cas d'utilisation intéressant : développer des applications internes disponibles clé-en-main pour une équipe. C'est valable si on a des développeurs sous la main et que ces développeurs ne sont pas développeurs web mais qu'ils ont des bases de HTML.

Pourquoi utiliserait-on ce toolkit plutôt qu'un autre dans ce cas-là ?

• parce qu'il a une philosophie de programmation des interactions utilisateur similaire à un toolkit "lourd" tel que TK, QT
• parce qu'il s'exécute sous forme d'application web, donc disponible sur le réseau, pour tous, sans installation.

Développer un tel outil avec des techno web classiques me semble plus compliqué d'accès pour un développeur "non web".

Je vois un cas concret qui m'intéresse à Algoo : metre au point un calculateur de prix. L'outil doit s'appuyer sur des données "fixes" (dispo en backend par exemple : prix/utilisateur/mois, options, etc), il faut une interface +/- interactive, faire une mise en page en HTML est relativement facile d'accès et au final il faut "juste" que l'utilisateur saisisse ses données et clique sur un bouton. Pourquoi je ferais ça avec Atlas et pas en pur JS par exemple ? Parce que je ne dev pas spécialement en JS et je n'ai pas envie de "déranger" un dév Tracim pour ça (d'autant qu'il va vouloir faire un truc aux petits oignons et je ne pourrai pas le faire évoluer facilement). Pourquoi une app web ? parce que l'outil doit être utilisable clé-en-main. Autre intérêt que je vois en python/atlas : possibilité de générer sur le serveur un fichier PDF, texte ou autre lorsque l'utilisateur clique sur "enregistrer le chiffrage" par exemple. Ca pourrait aussi se faire en techno web classique, mais clairement, là, ça va être plus rapide à mettre au point et à bricoler.

Quelques remarques :

• ça s'exécute via un serveur http://faas1.q37.info ça me dérange. Je n'ai pas trouvé dans la doc comme faire tourner le truc en local (pour remplacer un toolkit local, je m'attends à qqchose qui tourne en local)
• ça me paraît nettement plus difficile à debugger que du pur python
• pour quelqu'un qui connait basiquement le HTML, ça me semble très simple d'accès, notamment avec le mécanisme de callback associés à des widgets "HTML"
• ça a l'air très lent
• je suis obligé d'afficher les outils de développement dans Firefox pour que l'écran ne reste pas blanc

Note : l'approche "SPA" n'a pas d'intérêt particulier pour l'utilisateur je pense ; par contre c'est cette approche qui permet une conception basée sur les interactions utilisateur via les callback (comme un toolkit "classique" d'IHM).

Conclusions :

• je suis intéressé par une version documentée du toolkit
• je suis intéressé par "pouvoir faire tourner le code en interne" (sans passer par un serveur extérieur)
• je confirme que ce toolkit a un intérêt ; par contre de ce que j'en comprends je le présenterais comme un "toolkit de développement rapide d'outils internes". Le fait que ce soit du web, que ce soit SPA, ce sont des enjeux techniques mais ce n'est pas ça qui va me convaincre d'utiliser le toolkit.

#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo