Re: Troll

Cependant, ma techno permet à tout un chacun de modifier l'interface :
- à l'aide d'un simple éditeur de texte, sans avoir mettre en œuvre d'autres outils (compilateur ou autres...),
- essentiellement juste en connaissant HTML et XSLT/XML ; à défaut, il pourra s’adresser à n'importe quel développeur Web digne de ce nom.

Tu optimise pour le mauvais problème.

Le développeur web, il va préférer faire du web. Il a ses outils, sa communauté, ses navigateurs.

Le développeur natif, il va faire du natif.

Et il y a un troisième type de développeur, dont je suis peut-être l'unique représentant aujourd'hui (j'espère que non), qui veut développer du Web, et du natif, tout en maintenant un seul et unique code commun aux deux (ce qui va faire l'objet d'un prochain journal, comme signalé dans celui-ci).

Le boite qui veut modifier un soft, elle a des développeurs en interne pour faire ca, ou elle sous traite.
Le fait que ca soit modifiable avec un simple éditeur de texte ne change rien au fait que le tooling est très important. Debugger/view inspector/logger etc. Tu enlève le compilo de la chaîne, cool, mais on a toujours besoin de ces autres outils. Au final, tu te retrouves avec le même problème sur le bras (cf mon point sur les compromis, le tien est tres mauvais ici).

Outils qui sont familiers à n'importe quel développeur Web. Donc, si l'utilisateur ne veut pas se coltiner ces outils pour la modification de l'interface, il trouvera facilement quelqu'un pour le faire à sa place. En tout cas, plus facilement qu'avec une application native classique sur MacOS, iOS, Windows...

Quel est l'intérêt de déployer une appli native basée sur des technos web, quand on a un browsers installé sur toutes les machines, ce qui élimine entièrement le problème du deployment/packaging etc? (À nouveau les compromis, tu te retrouves avec le pire des 2 mondes si tu part sur une techno hybride).

De pouvoir déployer la même application indifféremment dans sa version Web et/ou sa version native, sans rien modifier à son code. Bon, après, reste le vieux débat Web vs natif, mais qui, dans le cadre de mon appli. est sans intérêt, puisqu'on la déploie dans la forme que l'on veut.

Dit autrement, tu résouds un problème qui n'existe pas.
Les customisations qui ne sont que purement cosmétique sont par définitions triviales, et donc à très faible valeur ajoutée. Optimiser pour ce cas est une perte de temps.
Les customisations non triviales vont requérir des ingénieurs (vs bien falloir écrire du code pour gérer telle ou telle fonctionnalité différemment), qui maîtrisent donc la technologie et qui n'auront aucun problème à compiler une appli.

L'interface de mon appli. est en HTML5. J'offre à l'utilisateur la possibilité de modifier ce code HTML5 à volonté sans avoir à solliciter le développeur de l'application, et, au pire, mais ce n'est pas indispensable, en sollicitant le développeur Web de son choix. C'est tout. Maintenant, il en fait usage ou non, c'est son problème ; simplement, la possibilité existe.

A priori, mais je n'ai pas encore approfondi le sujet, cela devrait permettre de modifier une application pour, par exemple, l'adapter à l'usage des mal/non-voyants

L'accessibilité va plus loin qu'un simple problème de contraste.

Jette un œil à ce qu'ios/OS X font dans ce domaine si tu me crois pas. Ca demande systématiquement beaucoup de taff, dans la conception même de l'appli, et dans son implémentation. Même sous iOS qui premache 90% du boulot pour toi, tu te retrouves à devoir écrire du code custom à droite à gauche. C'est pas quelque chose que tu greffes après coup en changeant un peu les vues.

Soit dit en passant, ca te fait pas un peu peur de ne pas avoir approfondi le sujet? Disons que c'est un point central de ta technos, comment peut tu prétendre avoir fait les bon choix si tu n'as pas d'idée précise des cas d'utilisation?

Non, ce n'est pas un point central, c'est juste un des avantages. Et ce que je n'ai pas approfondi, ce sont les possibilités de HTML dans ce domaine. Si elles ne sont pas encore suffisantes, il y a de fortes chances que cela se développe par la suite. Le cas échéant, ça sera à la portée de n'importe quel développeur Web d'adapter l'appli. Mais, encore une fois, cela dépend de HTML, pas de ma techno.

A l'origine, je générais directement le .h, mais, en passant par le XML, cela ouvrait la possibilité de générer l'API dans un autre langage, en utilisant un autre fichier XSL.

Ce que je dit, c'est que l'api en question, c'est du code. Écrit la en code directement, plutôt que de la decrire en xml pour ensuite générer du code. T'as rien à gagner à l'écrire en xml, c'est infiniment plus verbeux et casse gueule.
La philosophie sous jacente à ce genre de technos, c'est que ca permettait de générer des stubs client et serveur automatiquement. Sauf que depuis, on s'est rendu compte que c'est vachement plus simple et pratique de juste écrire le code. Les stubs ne servent à quasiment rien, et dans les rares cas ou ils servent, t'as plus vite fait de les générer à partir de l'interface écrite en code. Cf par exemple ce que fait Jersey qui te génère ton wadl à partir de l'appli.

L'API en question contient du code, mais pas le code du backend. En gros, elle expose les objets gérés par le backend sous forme d'objets C++, et elle sérialise simplement les valeurs des différents paramètres des différentes méthodes de ces objets pour qu'ils puissent transiter via le canal de communication avec le backend. Et ça, c'est du code (削除) chi (削除ここまで) (削除) emm (削除ここまで) pénible à écrire, donc je préfère que l'ordinateur le fasse à ma place (c'est l'un des buts de l'informatique, non ?). Il n'y a pas l'ombre du soupçon de code du backend dans cet API, ni d'ailleurs dans le XML qui est utilisé pour la générer. J'ai mis un lien dans le journal sur un fichier contenant une telle API, ainsi que sur le fichier XML correspondant ; tu pourras t'en persuader toi-même.

Bon, j'ai encore regardé sur le Web de quoi il s'agissait, et je ne vois vraiment pas en quoi cela s'applique à ce projet. Pourrais-tu fournir une définition de ce concept, pour être sûr que l'on parle de la même chose, et m'indiquer un exemple de ce qui, dans mes technos, te paraît y correspondre ?

Tu passes beaucoup de temps à construire une plateforme qui émule de façon très pauvre la plateforme sur laquelle elle tourne.
Le concept de backend par exemple: pourquoi introduire un tel système? Ceux qui veulent parler à un backend réseau le feront plus vite et efficacement avec une api rest, tout en ayant une plus grande latitude de choix technologiques.
Le html5: les développeurs auront plus vite faite de coder pour un navigateur plutôt que d'utiliser ta version. Au final, tu construit une plateforme qui émule la plateforme sur laquelle elle tourne, et n'apporte pas grand chose, à part des contraintes.

Ma plateforme n'émule rien du tout. Une appli. native basée sur cette plateforme est, du point de vue de l'interface, une appli. Web, mais débarrassée de tous ce qui est relatif au réseau. Son interface est rendu par Chromium, mais dans une version débarrassée de toute l'interface nécessaire à la navigation Web. Et, coté traitement, on a tous les avantages du natif, c'est-à-dire qu'il n'est nullement besoin de passer par une couche REST ; on a accès directement au backend. Et cette plateforme permet de déployer la même appli en tant que qu’application Web, sans rien changer au code, et donc toujours sans avoir à recourir à une surcouche REST.

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