Si, si !

Salut,

Salut !

Tu as toute mon oreille, mais pour commencer, il n'y a pas de code sur la doc (allé jusqu'à la section 4). Un exemple ? Comment ça s'articule ? Regarder un long main.js n'aide pas, et voir des fichiers .xls n'ai pas encourageant.

Le code des exemples se trouvent dans les repository dont on trouve les liens sur la homepage. Cependant, ayant fait peu de Java/JavaScript/PHP, et c'était il y a longtemps, il y a probablement moyen de rendre le code des exemples plus compréhensible. C'est typiquement le genre de retour que j'aimerais avoir de la part de personnes développant dans l'un de ces langages.

J'ai ajouté unes petite section sur la structure d'une application basée sur le toolkit Atlas. Et c'est des fichiers .xsl, pas .xls :-), mais j'y reviendrais plus tard.

Ces infos importantes que je cherchais apparaissent tard (section 2): c'est pour écrire des SPA, il y a un binaire C++, on doit qd même avoir node.js (aïe, mais voyons), l'interface est en fait Électron (...mmh. Autant dire qu'on peut envoyer sur Électron facilement), il y a un client et un serveur.

Je ne voulais pas être trop technique dés la première page ; ceci dit, j'y parle déjà de SPA. Quant au fait qu'il y ai un binaire C++ (en fait, il y en a même plusieurs), c'est juste pour justifier certains choix en terme de packaging, dont l'utilisation de Node.js. En outre, le serveur web est actuellement basé sur Node.js.

Le problème, c'est que je ne connais actuellement pas suffisamment les outils entourant PHP ou Java pour, d'une part, packager le toolkit, surtout les binaires, juste en utilisant les outils propres à chaque langage, et, d'autre part, mettre en place un serveur web sans procédure d'installation compliquée. C'est pour cela que j'utilise Node.js pour le serveur web, et le package manager de Node.js, à savoir NPM, pour packager le toolkit. Mais, à terme, Node.js ne sera plus nécessaire pour les bindings Java et PHP (et les autres langages qui seront pris en charge à l'avenir). Évidemment, pour le binding Node.js, Node.js sera toujours requis, puisque c'est la finalité de ce binding...

Avant d'utiliser Electron, je m'appuyais sur CEF (et même avant cela, pour ce qui n'était encore que les prémisses de ce qui allait devenir le toolkit Atlas, XULRunner), mais Electron est beaucoup plus facile à déployer que CEF, et plus populaire. J'aurais aussi pu utiliser les composants dédiés à l'affichage de contenus web de bibliothèques comme GTK(+)/Qt/wxWidget/..., mais le déploiement aurait aussi posé problème. À terme, Electron sera mis en œuvre de façon à ce que le développeur ne remarquera même pas que c'est ça qui est utilisé. Déjà maintenant, le développeur n'interagit pas directement avec Electron...

Quant à l'architecture client/serveur, c'est ce qu'il y a de plus simple pour faire communiquer Electron ou le serveur web, qui est basé sur Node.js, avec un logiciel Java ou PHP. Bien qu'il soit intéressant de pouvoir garder cette configuration, la communication se fera peut-être, à terme, également via d'autres canaux...

Je n'ai pas compris si on édite les fichiers xls. Perso, e n'ai jamais approché xlst, je t'invite à expliquer un peu plus dans ta doc.

Comme dit, c'est XSL(T), pas XLS(T); rien à voir donc avec le format Microsoft :-).

En fait, j'aurais pu utiliser un autre moteur de template, comme ceux utilisés dans certains framework JavaScript, mais l'avantage avec XSL, c'est que c'est implémenté dans la plupart (totalité?) des navigateurs web graphique (et dans Electron), donc la transformation est réalisée coté client, en n'ayant rien à installer, tout en pouvant être réalisée coté serveur si nécessaire.

Le principe est de créer un arbre (ce qui est facilité avec l'objet Tree du toolkit Atlas) contenant les données à afficher, et de générer le HTML à afficher dans le navigateur/Electron en appliquant une feuille de style XSL sur l'arbre en question. La structure de l'arbre est totalement libre ; on organise les données absolument comme l'on veut. Si les données sont issues d'une base de données, la structure de l'arbre reflète généralement celle de la base de données. Maintenant, bien que XSL ne soit pas très populaire, la documentation sur le sujet ne manque pas, écrites par des personnes bien plus compétentes sur le sujet que moi. Cependant, s'il y a des points précis qui ne sont pas clairs dans les fichiers XSL fournis avec les exemples, je les expliciterais bien volontiers.

Pas clair pour moi: est-ce que le site a été écrit avec ? Y a-t-il une sorte de routeur (pour avoir de belles urls) ? Dans la démo le filtre est "statique", on doit appuyer sur entrée, est-il possible d'en avoir un dynamique ? (type select2, ajax-based)

Le site est basé sur un CMS qui se contente de servir des pages écrites en markdown.

Il n'y a pas de routeur. D'après ce que j'en ai compris, cette notion de routeur est surtout associée à l'architecture MVC, mais comme je n'ai pas approfondi le sujet, ma compréhension de la chose est très parcellaire. En tout cas, je n'en ai pas vu l'utilité, donc cela n'est pas implémenté, tout en n'excluant pas la possibilité d'une implémentation future, le jour ou j'en aurais compris tout les tenants et aboutissants.

Honnêtement, j'ai fait au plus simple, mais avoir un filtre dynamique devrait déjà être possible. Cependant, je réfléchis à une solution ou le filtre ne se déclencherait pas en cours de saisie, mais un court délai après que l'utilisateur ai saisi le dernier caractère.

Dans la démo j'ai cliqué sur Create, j'aurais bien eu un bouton retour (pas d'intégration avec le navigateur ?), j'ai mis du tps à voir Cancel, tout en bas. Dans un TodoMVC généralement on peut marquer une tâche comme faite, pas vu ici.

Je n'ai pas trop compris l'histoire de l'intégration au navigateur. Je suis d'accord que la démo n'est pas très ergonomique, mais mes compétences en HTML et CSS ne me permettent de faire guère mieux (contributeu(rs/ses) bienvenu(e)s...). Mais attention, la démo en ligne n'est pas celle du TodoMVC. À l'époque où j'ai commençais à écrire une démo, je ne connaissais pas le projet TodoMVC. J'en ai donc écris une en m'inspirant vaguement d'un truc que j'ai trouvé sur le web. Je n'ai écrit les versions de l'application TodoMVC que plus tard, pour que les gens puissent avoir un élément de comparaison (ce qui est le but du projet TodoMVC), mais je ne voyais pas l'intérêt de la mettre en ligne, vu qu'elle fait exactement ce que font les version présentes sur le site du projet TodoMVC et dont on peut facilement voir une démonstration en ligne...

Je vais regarder et viens donner des nouvelles dans un moment :)

Merci déjà de ce premier retour, et je suis bien sûr preneur de tout autre à venir...

ps: ah mais oui, le "hide descriptions" est dynamique lui ! J'aurais bien vu un filtre dynamique, de suite ça claque plus.

J'ai spécialement mis cette case à cocher pour que justement on comprenne que la page n'est pas régénérée à chaque action. C'était plus simple à mettre en œuvre que le filtre dynamique, mais je vais réfléchir à l'implémentation de ce dernier.

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