Re: Troll

Ok, donc visiblement, on parle de simple définition d'ui en déclaratif? Tu fais pas de bindings (e.g. Définir dans le xml que ce champ reçoit le contenu de la variable foo du contrôleur)?

Ben, au final, le code derrière l'UI, c'est simplement du bête HTML5, similaire à ce qu'on trouve dans la plupart des pages Web ; il est simplement mis en forme à l'aide de XSLT... CEF, c'est, grosso-modo, le navigateur Chromium, mais sans les éléments d'interface qui en font un navigateur Web, c'est-à-dire juste le moteur de rendu. Tout aussi grosso-modo, CEF est à Chromium ce que XULRunner est à Firefox (bon, je ne sais si ça va parler à beaucoup de monde, ça). Mon appli donne à CEF (donc Chromium) du XML et du XSL, et CEF se charge de transformer ça en HTML, dont il assure également le rendu.

Effectivement, la plupart des technos ont une forme de compilation, ça évite de se taper le surcoût de parser du xml à la volée pour qq chose qui n'est pas censé être changé après le packaging de l'appli. L'exception, de mémoire, c'est le truc de Facebook, components il me semble, et eux ont un besoin bien précis (j'y reviendrais).

Si rares sont ceux qui le font c'est parce que le besoin est faible. Changer un storyboard et relancer l'appli sous iOS, c'est moins d'une seconde. Tu changes juste une ressource qui est rapide à compiler, tu touches pas le code, ça va vite.
Pour ceux qui veulent modifier l'ui d'un logiciel libre, c'est d'une part assez rare, et d'autre part généralement un peu plus compliqué que juste changer le layout. Optimiser pour la simplicité de compilation n'est pas un bon calcul.

Je ne comprend pas trop ta dernière phrase. 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.

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, sans pour cela avoir à impliquer le développeur de l'application. Je pense que pour faire la même chose avec les autres technos citées dans ce journal, il faudrait l'intervention d'un développeur. Accessoirement, cela permet facilement au développeur de déléguer la réalisation du design de l'interface, vu qu'il ne manque pas de personnes ayant les compétences nécessaires (développeurs Web). Personnellement, n'ayant aucune affinité particulière avec HTML et consorts (CSS, JS...), c'est quelque chose qui m'arrange bien.

Bon, quand je parle de l'utilisateur, il peut aussi s'agir d'une entreprise qui adapte l’interface du logiciel à sa charte graphique, par exemple...

Ce qu'il se passe pour Facebook est qu'ils ont une appli gigantesque, dont le contenu change en permanence et en temps réel, maintenue par des dizaines de personnes et releasee tous les 15 jours. la modifier sans tout peter est très dur. Le feed se met à jour constamment et affiche les likes/commentaires etc en temps reel.

Le modèle traditionnel "modifie la vue pour afficher les données" marche mal, parce qu'il ya trop d'état différents pour chaque vue, et donc calculer le diff est dur.
Leur solution à ce problème, c'est de partir sur un modèle 100% événementiel/stateless. C'est plus simple de tout balancer et de rerendre les vues quand les notifications de changement de données arrivent. Charge à la team du framework de recycler les vue pour que ca rende toujours à 60fps sans bouffer toute la ram du device.
Le fait que les vues se recharges automatiquement à chaud est juste un effet de bord sympa, c'est tout, c'est pas un but en soi.

En effet. J'ai cité cela pour juste souligner la facilité avec laquelle on peut modifier l'interface.

Bref, assez parlé de Facebook, retournons à xdh chose.
- quel problème xdh-chose essaye de résoudre?
- en quoi ce problème est pertinent?
- en quoi la solution de xdh améliore l'état actuel?

Je pense que tu parle des attributs data-xdh-.... Ça n'est pas censé résoudre un problème en particulier, c'est juste mon approche pour gérer :
- pour les data-xdh-onevent(s), la mise en place des gestionnaire d’événements,
- pour les xdh-data-cast(s), l'accessibilité (je ne trouve pas de terme adéquat pour désigner le fait qu'un élément soit hidden/disabled...).

Il y a également les data-xdh-widget, mais qui ne sont pas (encore) utilisés dans cette appli, et qui sont dédiés à la gestion des widgets basés sur jquery, qui semblent assez répandus.

Tout ça permet de confier au logiciel la mise en place du code JS généralement mis en œuvre pour ces usages.

Un des concepts de base en ingénierie est qu'on ne résoud jamais vraiment un problème. On transforme un problème en un autre, mais cet autre problème vient avec ses inconvénients. Si les nouveaux inconvénients sont moins nombreux/courants/ennuyeux que ceux qu'on avait a la base, on a gagné. En d'autres termes, on fait des compromis.
Un compilateur rend plus simple l'écriture de code, par exemple, mais le langage vient avec ses tares, et cache le fonctionnement sous jacent de la machine. En pratique, c'est un gain net.

Étant le développeur de cette appli, je m'abstiendrais de me prononcer sur ce point ; on pourrait m'accuser de manquer d'objectivité :-).

J'ai du mal, personnellement, à voir le gain sur le compromis que tu fais ici. Tu gagnes sur le code, mais tu te retrouves avec plus de 1000 lignes de xml aride pour une appli triviale. ça coûte cher le setup de l'appli, même les monstres à là spring font tout ce qu'ils peuvent pour réduire ca le plus possible (et eux font beaucoup plus que toi avec ce setup).

Là je pense que tu parle des fichiers de configuration (les .xcfg). Le problème vient du packaging. En réalité, mes fichiers de configurations sont plus simples que ceux qui sont fournis dans les packages (comme on peut le voir en regardant les version hébergées dans le repository mercurial dont l'adresse est donné dans le journal), car ils s'appuient sur un préprocesseur XML, ce qui permet d'utiliser des macros, et de répartir le contenu sur plusieurs fichiers. La version packagée est celle après application du préprocesseur XML ; c'est comme si on livrait les sources d'un programme C/C++ après les avoir passés par le préprocesseur C. C'est certainement quelque chose qui devrait être amélioré, mais ce n'est pas évident à réaliser. Ceci dit, ça reste du XML, mais il ne sert qu'à remplir une registry interne. On peut parfaitement envisager de remplir cette registry à l'aide d'un autre format, comme JSON par exemple...

Le xml est particulièrement aride à lire, très long, tres verbeux et ca se répète énormément. Ça fait 15-20 ans qu'on sait que les UI déclaratives, c'est cool, mais il faut un éditeur riche pour que ça marche. Ça va plus vite à écrire, et ça permet d'avoir une vue de l'ensemble.
Le xml pour générer les stubs back/front end, on sait depuis soap que c'est une très mauvaise idée. C'est vilain, verbeux et ca résoud quasiment aucun problème, ca en rajoute juste.
Dans l'autre sens, ça marche mieux (par exemple ce que fait jaxrs avec les wadl). La tendance "xml pour générer des stubs" avait le vent en poupe ya 15 ans, tout le monde en revenu parce que c'est un enfer à maintenir et ca ne résoud pas vraiment de problème. C'est plus simple/lisible/naturel d'écrire une interface en code directement.

Pour le XML relatif à l'interface, et celui des fichiers de configuration, j'espère que mes réponses ci-dessus sont assez claires (sinon, ne pas hésiter de me demander des précisions). Pour celui concernant l'API des backend, il s'agit juste d'un fichier intermédiaire, qui n'est pas utilisé lors de l'exécution de l'application. 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.

Bref, désolé de tailler un costard, mais j'ai beaucoup de ma à voir un intérêt au framework, et à mon avis, ce genre d'approche diminue la qualité plus qu'autre chose.

Inutile d'être désolé. Pour l'instant, tout ce que j'ai lu concernant les autres technos me renforce dans mon opinion que les miennes sont parfaitement viables et légitimes, en théorie du moins. Et c'est justement l'un des buts de l'appli présentée dans ce journal de les mettre à l'épreuve de la pratique.

Aussi, pour ne pas perdre trop de temps avec ça, j'ai établis quelques règles de nommage ; malheureusement, ces règles donnent des noms parfois un peu abscons, mais c’est le prix à payer si l'on veut des noms pas trop longs.

Et bien changes les règles. Rajoutes des voyelles, ça coûte pas plus cher et ça fait des mots lisibles et prononçables.

Là encore, c'est un problème de packaging. Si l'application était correctement packagé, l'utilisateur ne serait jamais exposé à ces noms ; il aurait juste à cliquer sur l'une ou l'autre icône, auxquelles on pourrait donner un nom plus expressif. Mais, vu l'état de l'application, il me semble plus important de me concentrer sur le fond que sur la forme...

Le commentaire sur l'inner platform effect se rapportait au framework, pas aux noms :)

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 ?

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