Re: Montre ton code

Le schéma demandé relève du détail technique dont l'utilisateur ne devrait pas avoir à se préoccuper.

Quelle est ta cible d'utilisateurs, exactement ?

Je n'ai pas développé ce toolkit en ayant un type d'utilisateur en tête. Maintenant, ce qui me vient à l'esprit, à froid, c'est le cas celui qui veut monter une startup, puisque c'est à la mode.

Beaucoup de startups s'appuient sur un service web. La première préoccupation du startupeur, c'est de convaincre des financeurs. S'il a quelques compétences en matière de développement, ou qu'il a sous la main quelqu'un qui a de telles compétences, quelque que soit le langage, il va pouvoir rapidement développer ou faire développer un prototype de son application grâce au toolkit Atlas.

Le jour où il va aller présenter son idée de startup pour obtenir des financements, il va à son RDV avec son ordinateur portable sous le bras, il passe quelque slides pour présenter son idée, et, au lieu de présenter des captures écrans de ce à quoi va ressembler sa future application, il va lancer le prototype de cette application directement sur son ordinateur portable (sous réserve qu'il soit connecté à internet), et la manipuler sous les yeux des décideurs. Et, s'il le décide, il peut afficher le code QR de l'application, et ainsi les décideurs pourront eux-mêmes manipuler l'application sur leur smartphone/tablette/ordinateur portable. Rien n'est de trop lorsqu'il s'agit de convaincre des investisseurs...

En tant que développeur de métier, le contexte dans lequel mon application est exécutée est une des premières choses que je vais regarder. L’environnement de l’application a toujours un impact, plus ou moins important, sur celle-ci.

Dans le cas d'atlas, qu'est-ce qui se passe si je tente d'accéder à des fichiers distants ? À des fichiers présente sur le réseau local de ma machine ? Est-ce qu'il est possible d'ouvrir des ports réseaux supplémentaires ? Est-ce compatible avec un support des websockets ?

L'idée de base du toolkit Atlas, c'est que les manipulations du DOM qui ne sont généralement réalisables qu'en JavaScript, et donc dans le front-end, soient disponibles dans le back-end, et ce dans le langage utilisé pour programmer ce dernier, quelque soit ce langage. Le code HTML qui est envoyé dans le navigateur peut, sans problème, contenir du code JavaScript. Le toolkit Atlas n'offre que la possibilité de manipuler le DOM à partir du back-end. Tout le reste peut se réaliser de manière classique.

le toolkit Atlas n'en est qu'à ses débuts, et je ne sais pas comment il se positionne par rapport à des solutions de développement web classiques (je n'ai jamais utilisé de telles solutions). C'est pour cela qu'en attendant qu'il soit suffisamment mature, sous réserve que les choix techniques retenus pour ce toolkit le permette, pour rivaliser avec les solutions existantes, je le présente comme une solution de prototypage, en mettant en avant une facilité de déploiement qui, me semble-t-il, n'est offerte par aucune autre solution de développement d'applications web.

Cependant, en mode prototypage, le toolkit Atlas présente certaines limitations, et les fonctionnalités avancées de certaines solutions de développement d'applications web ne sont pas disponibles avec le toolkit Atlas. Mais, d'un autre coté, on a rarement besoin de fonctionnalités avancées pour un prototype. En outre, il est bien entendu possible que certaines de ces fonctionnalités puisse être disponibles dans les futures versions du toolkit...

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