JavaFX

[Frederic Nikitin]

Salut aux castcodeurs,

Si JavaFX n'est pas totalement mort et s'il y a un peu d'intérêt de la communauté, je pense qu'il serait intéressant d'en faire un épisode à part entière.

Si JavaFX est mort, je pense qu'il serait important de faire sa rubrique nécro.

Merci d’avance :)

Fred

[Remi Forax]

Tu veux en parler, ou tu as quelqu'un à proposer ??

Rémi

---

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Frederic Nikitin]

Ni l'un ni l'autre.

Je suis un fidèle auditeur des castcodeurs ; je me disais simplement que ce serait sympa d'avoir parfois des news de JavaFX

et encore mieux un épisode avec les gens de l'industrie qui utilise cette technologie et connaitre leur retour d'expérience.

A un moment ou un autre il a fallu que je choisisse une technologie pour developer ma desktop app et j'ai choisi JavaFX car

il m'avait semblé que son inclusion dans le core jdk était un gage de perennité.

Mais à la lecture de quelques blogs, notamment les mécontents face aux problèmes de performance et à l'inertie et le désinteressement 

dont semble faire preuve oracle en matière d'investissement dev sur cette techno, je me demande maintenant si mon choix initial était judicieux.

Fred

[Patrice Trognon]

il paraît que Swing est mort mais j’ai encore fait un projet dessus y’a deux ans :)

Pat

[Emmanuel Bernard]

Il nous faudrait quelqu'un effectivement. 

[ehsavoie]

Je n'ai vu aucune annonce comme quoi c’était donné à la fondation Eclipse (comme Hudson) donc ça doit être encore vivant ;-)

#dredi

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

[Laurent Forêt]

Attention Emmanuel, de là à dire que Netbeans est mort pcq'il a été donné à Apache, il n'y a qu'un pas. Carton jaune ;)!

Laurent

[ehsavoie]

Ah non justement à Apache ce n'est pas mort cf. Tomcat ;o)

Et Apache c'est le monde de la communauté pas celui des entreprises :p

#dredi bis

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

[Fred Bricon]

***cough*** Apache OpenOffice ***cough***

#dredi ter

"Have you tried turning it off and on again" - The IT Crowd

And if that fails, then http://goo.gl/tnBgH5

[Sebastien Bordes]

C'est vivant mais peu utilisé en France, plus en Allemagne/Suisse comme beaucoup de client lourd en Java (comme Eclipse pour ne pas le nommer).

Le problème n'est pas le manque d'investissement de la part d'Oracle, (lors des premiers JavaOne après le lancement de JavaFX 2, 2.1, 2.2 puis 8 il y avait plus de 60 talks sur ce sujet), c'est plutôt leur manque de suivi avec le retournement d'Oracle vers l'IOT plus prometteur en ROI.

Du coup les décideurs peuvent être frileux pour partir sur cette techno et voire carrément opter pour faire la pire des choses à imaginer; à savoir partir chez kr0$oft... (xp inside).

Les écoles sont encore restés bloqués sur Swing, car refaire les cours+TP c'est long....

Ce qui est sûr,

JavaFX 8 c'est bien mieux que Swing en tout point.
JavaFX 8 n'a pas à rougir face aux autres toolkit graphiques, WPF, QT et ...??
JavaFX 9 sera modularisé façon Jigsaw, ca sera d'ailleurs la seule évolution notable.
JavaFX sera présent dans les JRE/JDK jusqu'à ce q'un successeur arrive ou qu'Oracle dise stop au toolkit graphique en Java... bien qu'il pourra survivre via l'OpenJFX

Bref ca bouge encore et il y a eu des talks récents pour montrer des applications de la vraie vie faite en JavaFX.

Seb

[Patrice Trognon]

Je me permet de rebondir sur ton propos par rapport a JavaFX car du coup cela soulève des questions.

Je fais pas mal de code d’IHM dans différentes technos, du Swing, du Qt et du Cocoa sur OS X, grosso modo quelque soit

la techno je constate qu’il y a toujours un code bien lourd a devoir pondre c’est tout ce qui concerne la partie IHM, certains

vont plus ou moins loin dans les outils qu’ils fournissent, Qt Creator pour Qt, Storybord pour Cocoa, mais quelque soit leur

niveau de maturité je trouve que ce code d’IHM casse pied a écrire finalement tu n’y coupe pas.

Dans une application finalement cela finit par représenter une charge de dev loin d’être négligeable par rapport au code métier.

A titre perso je trouve que (Storyboard >= Qt Creator ) > Swing, Storyboard et QtCreator présentant un sacré niveau de maturité

permettant de diminuer la taille du code d’IHM a produire, mais il reste très présent, alors que Swing ne propose : rien !

(les quelques trucs de design d’ihm swing que j’ai pu tester pondaient tous un bon gros code de daube a reprendre du coup je fais

tout a la main).

Pour en revenir a JavaFX, auquel je ne suis jamais passé mais ça je vais revenir dessus après, qu’est est t’il de son coté sur ce point ?

qu’en est il du coté des APIs tierce en JavaFX, des bibliothèques pour :

tracé des graphs (camembert, en bar, 2d, 3d, …)

des graphs a la graphviz avec des boiboites, des flèches entre les boiboites, etc ?

Ah oui, en ce qui concerne le coté obscur, leur outil de mapping entre l'IHM et le code MFC était quand même une sacrée tuerie :) 

(mais ca c’est juste en passant parce qu’on est dredi).

Pat

[Sebastien Bordes]

Macromedia a lancé (relancé?) la mode des IHM basé XML avec leur format MXML utilisant la technologie Flex basé sur un moteur Flash (avec le language ActionScript).

Ensuite c'est devenu tendance, les xml pour faire une ihm déclartive c'est top....

Donc a eu droit dans le désordre à du xaml (kr0$oft .net/wpf/Silverlight ....) a du fxml pour JavaFX en passant par du XWT côté Eclipserie.

Perso j'aime pas ! car ca fonctionne bien que pour les choses simples, quand on fait des gros machins ca se complique et l'outillage peut faire défaut selon la techno.

Donc en JavaFX on a du FXML éditable via SceneBuilder outil developpé par Oracle et cédé à la communauté pour le maintenir en l'occurence c'est Gluon qui s'y colle (les gens qui font/essayent du JavaFX mobile).

L'astuce du fxml c'est que ca a été pensé dès le début donc on retrouve toutes les classes de l'API comme tag xml et toutes leurs propriétés comme attribut xml.
Le petit défaut que j'y trouve c'est le pixel perfect design, faut être un as de la souris ou switcher avec la vue propriété.

Ensuite au runtime le fxml est parsé pour charger le node racine et tout devient transparent.

Il est tout à fait possible de mixer du fxml avec du .java.

Concernant les primitives graphiques; le toolkit propose les widgets de base, des widget évolués (table, tree, liste) utilisant une fenêtre glissante, des Shapes (autre carré,cercle, line etc...) et aussi un Canvas permettant de créer ces primitives par appel de méthode: voici une démo un peu vieillote mais présentant la théorie http://jrebirth.org/apps/Breizhcamp.html

Faire des boiboites avec des fleches est assez trivial mais après il vaut mieux utiliser un petit cadriciel applicatif pour structurer le tout, il y en a une petite dizaine, j'ai récemment fait une prez interne à ce sujet (à la demande je peux eventuellement la partager après "nettoyage").

Concernant le MFC que je connais pas bien, c'est quand même assez lourdingue à coder, c'est justement le legacy qui est en train d'être évacué. Même WPF semble plus simple (enfin d'après les experts...).

Perso je milite pour JavaFX mais c'est fatiguant de courrir après les moulins à vent... 

 

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

Sébastien Bordes s...@jrebirth.org - jrebirth.org - blog

[Cédric Beust ♔]

2017-04-07 7:22 GMT-07:00 Sebastien Bordes <sebastie...@gmail.com>:

c'est Gluon qui s'y colle (les gens qui font/essayent du JavaFX mobile).

JavaFX mobile... En 2017, il y a encore des gens qui pensent que c'est une bonne idée.

Tragique.

-- 

Cédric

[Patrice Trognon]

ok ok,

en fait à mon sens c’est le code IHM qui est lourdingue à coder, quelque soit la techno.

Ces deux dernières années j’ai eu deux fois la même question à laquelle apporter une réponse : 

je veux un logiciel qui fonctionne en offline only, avec une base locale, et portable OS X / Windows / Linux.

La premiere fois ma réponse a été Swing avec hsqldb, ça a très bien fonctionné.

La seconde fois ma réponse a été QtCreator avec SQLITE.

Une réponse possible aurait pu être JavaFX mais quand on veut être profitable on va vers ce qu’on connait si aucune

techno n’est imposée.

Dans les deux cas j’ai constaté que le code IHM finissait par être assez lourd à maintenir et ou à faire évoluer, par contre

j’ai été surpris par la productivité avec Qt/C++, leurs classes permettent vraiment un codage de haut niveau avec une très

grande efficacité puisque j’ai estimé que je n’aurais pas été plus rapide avec Java.

Mais du coup je reviens sur JavaFX, à vous lire il est moribond, comme on constate que Swing n’a jamais été abandonné

est il encore temps de passer à JavaFX ? est ce que ça peut valoir le coup ou finalement autant continuer avec mon swing

que je code quasiment sans y penser ?

Pat

[Sebastien Bordes]

C'est le but de leur startup: http://gluonhq.com après je ne peux pas en dire plus je n'ai plus trop suivi les évolutions.

--
Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Patrice Trognon]

ouais encore et toujours l’arlésienne du RAD, ça existera toujours, et il y aura toujours des devs pour se prendre la porte dans la figure en voulant aller plus loin que ce que l’outil permet ….

ca fait 25 ans que je suis dans le dev, 25 ans que j’entend la même chanson, franchement maintenant ça me faire rire.

Finalement maintenant je suis pour ces outils, ils finissent en général par être un apporteur d’affaire indirect pour moi :)

Pat

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.

[Sebastien Bordes]

Quel framework/Design pattern as-tu utilisé avec QT ? juste le MVC qml+controller+bean ?

L'utilisation d'un cadriciel peut grandement simplifier les choses pour les interactions et la modularisation, la partie déclarative restant ce qu'elle est....

Tu aurais pu choisir JavaFX à la place de Swing et en en une semaine tu aurais été OP. Il y a  6 ans je vouslais me remettre à Swing après du Flex/Silverlight et du web, quand j'ai vu l'API beta (à l'epoque, 2011) j'ai lâché de suite Swing (je n'ai du le reprendre que pour les TPs...).

En plus côté performance JavaFX c'est magique (comparé à Swing attention pas de troll).

Alors pourquoi Swing est encore présent ? tout simplement à casue du legacy, tout réécrire ca coute des pépètes !! il faut pouvoir le jsutifier !!! (C'est le cas de NetBeans et d'IntelliJIdea)

--

Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

[Patrice Trognon]

Le 7 avr. 2017 à 16:52, Sebastien Bordes <sebastie...@gmail.com> a écrit :

Quel framework/Design pattern as-tu utilisé avec QT ? juste le MVC qml+controller+bean ?

Oui, du coup en devant écrire ses classes de model.

L'utilisation d'un cadriciel peut grandement simplifier les choses pour les interactions et la modularisation, la partie déclarative restant ce qu'elle est....

Tu aurais pu choisir JavaFX à la place de Swing et en en une semaine tu aurais été OP. Il y a  6 ans je vouslais me remettre à Swing après du Flex/Silverlight et du web, quand j'ai vu l'API beta (à l'epoque, 2011) j'ai lâché de suite Swing (je n'ai du le reprendre que pour les TPs...).

En plus côté performance JavaFX c'est magique (comparé à Swing attention pas de troll).

Ah mais Swing est tres lourd a apprendre, ce n’est vraiment pas simple, a une époque je codais en JGraph et je m’etais bien arraché les cheveux pour rentrer dans le truc.

Alors pourquoi Swing est encore présent ? tout simplement à casue du legacy, tout réécrire ca coute des pépètes !! il faut pouvoir le jsutifier !!! (C'est le cas de NetBeans et d’IntelliJIdea)

Bon donc a te lire rentrer dans un JavaFX c’est une semaine et ca vaut le coup pour le plaisir :)

Je note, mais la c’est à Scala que je dois me mettre et je souffre :(

Pat

[Mickael Istria]

On 04/07/2017 03:32 PM, Sebastien Bordes wrote:

C'est vivant mais peu utilisé en France, plus en Allemagne/Suisse comme beaucoup de client lourd en Java (comme Eclipse pour ne pas le nommer).

Je te propose de venir a EclipseCon France en juin pour voir qu'il y a en fait beaucoup de devs Eclipse RCP et d'entreprise qui ont Eclipse dans leur strategie en France ;)

Les écoles sont encore restés bloqués sur Swing, car refaire les cours+TP c'est long....

Il y a pas aussi une histoire qu'OpenJDK ne fournit pas JavaFX par defaut pour des raisons de licenses? Il me semble que ca nous a bloque sur certaines parties de JBoss Tools par le passe.
Du coup, si ca force l'utilisation d'Oracle JRE pour faire du JavaFX, c'est une contrainte que beaucoup de gens preferent eviter.

--
Mickael Istria
Eclipse developer for Red Hat Developers
My blog - My Tweets

[Sebastien Bordes]

Mickael, j'en fais partie; les Eclipseries c'est mon quotidien !!

Ma phrase est en deux morceaux:

JavaFX c'est vivant mais peu utilisé en France, plus en Allemagne/Suisse

JavaFX est plus présent en Allemagne/Suisse comme beaucoup de client lourd en Java (comme Eclipse pour ne pas le nommer).

Même pour Eclipse la commauté Allemande est plus importante que la Francaise à moins que j'ai raté un épisode.... me faudrait-il une piqure de rappel

J'ai toujours installé la jdk d'oracle sous linux après le même problème se pose sous windows non ? C'est juste problématique pour les solutions packagés.

--

Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.

Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

[Mickael Istria]

On 04/07/2017 05:18 PM, Sebastien Bordes wrote:

Même pour Eclipse la commauté Allemande est plus importante que la Francaise à moins que j'ai raté un épisode.... me faudrait-il une piqure de rappel

Ouais surement. Ceci dit, je serais curieux de voir des stats.
L'EclipseCon Allemagne est plus grosse, mais elle deplace plus de monde. Les DemoCamps allemands sont souvent un peu plus gros, mais c'est pas une difference enorme. Au final, sur les projets sur lesquels je bosse, la predominance de contributeurs Allemands et Suisses n'est pas si flagrante.
Mais bon, on est tous citoyens du monde, donc ca change pas grand chose!

J'ai toujours installé la jdk d'oracle sous linux après le même problème se pose sous windows non ? C'est juste problématique pour les solutions packagés.

C'est en effet possible, mais ca revient a une autre discussion sur les JREs. Si tu veux du support long et pas trop cher, il vaut mieux eviter Oracle et preferer OpenJDK et donc -jusqu'alors- eviter JavaFX...

[Sebastien Bordes]

Oui c'est pour cela que certaines boites (snif) preferent migrer vers .net car le support kr0$oft est plus rassurant que celui d'Oracle :( voire d' Eclipse sans vouloir troller mais chez nous ce mot est assimilé à gros machin pour de multiples raisons, bonnes et mauvaises...

--

Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[thierry.w...@gmail.com]

Bonjour à tous,

Personnellement j'ai découvert JavaFX 2 à DevoxxFR il y a quelques années et je suis tombé dans le jus. La première mouture était orientée RIA, très (trop?) inspirée de Flash/Flex. En effet, la vue c'était du scripting que l'on aime ou pas. Aussi, les notions étaient les mêmes: timeline, key frames, etc. Leur application phare de l'époque: un player musical web. Le gros inconvénient de la première mouture? L'impossibilité d'utiliser des JARs déjà existant: oubliez votre parser JSON, votre connecteur JDBC, etc. Un comble pour des développeurs Java.

En passant à JFX 2, Oracle est revenu auprès des développeurs Java pour refactorer complètement JavaFX qui est depuis une véritable alternative à Swing (pour moi ça ne l'était pas avant). On retrouve toutes nos librairies, et leur application phare était maintenant SceneBuilder (cédée depuis à la communauté OSS) permettant de créer ses IHMs par glisser/déposer.
Comme évoqué plus haut, la vue est du FXML, couplé CSS JavaFX. Ca a du pour et du contre. L'avantage certain c'est la génération du FXML par des outils. Comme il s'agit de respecter la DTD, SceneBuilder ne génère pas du code complètement incompréhensible, comme le faisait à l'époque eclipse (et ses plugins EMF, GMF et cie) et NetBeans (qui interdisait l'édition du code de l'IHM généré purement et simplement). L'avantage aussi c'est que c'est compréhensible par "n'importe" qui, pas nécessairement un barbu Java. Et enfin, le CSS permet de styliser très simplement l'application dans la majorité des cas (ce qui permet aussi de déléguer cette tâche de styling à un designer, assez simplement en principe). Après le couplage Java reste utile dans certains cas.

Ce que l'on mentionne (trop) peu selon moi, c'est le packaging natif: générer un bundle spécifique à chaque plateforme embarquant un JRE. Cela évite aux utilisateur finaux d'avoir à télécharger un JRE et donc on s'assure de la version du JRE utilisée. En revanche la taille du paquetage final est bien plus importante. (On espère que Java 9 va aider dans tout cela).

C'est qu'en France, le sujet a du mal à prendre, bien que nos amis du FinistJUG sont toujours intéressés par le sujet. Pourtant c'est aussi utilisé par la NASA, dans des boîtes allemandes et suisse. Le plugin asciidoctor d'IDEA est également en JavaFX. En France on préfère le web :)

Personnellement pour faire des présentations sur JavaFX à des conférences et développer SlideshowFX et jstackfx en projet OSS, et d'autres en interne depuis plus de cing ans, j'en suis satisfait :)

Donc si LCC cherche une personne, on peut tenter de planifier cela :)

Thierry
@twasyl

--

Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.

Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

Sébastien Bordes s...@jrebirth.org - jrebirth.org - blog

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.

Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

Sébastien Bordes s...@jrebirth.org - jrebirth.org - blog

[Julien Gaucher]

Oui enfin le support de Wpf est pas super clair non plus.

Microsoft ( comme beaucoup d'autres ) semblent doucement mais sûrement se tourner vers des

Techno comme électron j'ai l'impression.

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.

[Sebastien Bordes]

En JavaFX, ton IHM est un graphe d'objet acyclique (comme dans les autres toolkits) orienté utilisant 4 notions:

• Stage => fenêtre offerte par l'OS
• Scene => le lieu de l'action présente dans chaque Stage
• Node => Element visuel
• Parent => Element visuel contenant des Node

Tu manipule ce graphe dans le thread graphique en live ou dans un autre thread si la scene n'est pas affiché, et banco.

On rajoute des Animations des Effets et des CSS, un moteur de rendu utilisant le GPU (D3D ou openGL) pour faire des choses jolies et moderne

Pour completer tu choisis le cadriciel applicatif qui va bien pour te simplifier la vie selon tes convictions personnelles (tu peux t'inspirer de la JSR 377 voire 296 pour les nostalgiques) et gaz!

Si tu as déjà dompté un toolkit graphique 1 semaine c'est même trop ! Après comme partout il y a toujours des petits subtilités (dernièrement il y en a une en SWT qui m'a bien gonflé, la selection auto du premier element d'un Tree)

Bon code.

[ehsavoie]

Sinon il y a NetBeans RCP pour ceux qui font encore du Swing ;)

C'est utilisé par la NASA (aussi), par Boeing , l'OTAN et pas mal de boites (même à Grenoble terre d'Eclipse).
Ça fournit un ensemble de widgets d'assez haut niveau et tu peux tout faire dans l'IDE.

Y a aussi DukeScript qui propose une interface multidevice mais j'ai fait que les premières démos.

Emmanuel

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

[Cédric Beust ♔]

2017-04-07 7:45 GMT-07:00 Patrice Trognon <ptro...@gmail.com>:

La premiere fois ma réponse a été Swing avec hsqldb, ça a très bien fonctionné.

La seconde fois ma réponse a été QtCreator avec SQLITE.

Une réponse possible aurait pu être JavaFX mais quand on veut être profitable on va vers ce qu’on connait si aucune

techno n’est imposée.

Une autre réponse possible aurait été la RCP d'Eclipse, qui s'est beaucoup améliorée ces dernières années et continue d'être très active et versatile.

-- 

Cédric

[Emmanuel Lécharny]

Et combiné à RAP, ça permet même de développer des applis web sans se
poser de questions (tu développes ton appli RCP, tu changes delib, et
bam, ça marche via u browser comme en client lourd). C'est assez
bluffant : http://www.eclipse.org/rap/demos/

Après, Eclipse RCP, ça prend pas 5 mins pour coder une appli non plus..

--
Emmanuel Lecharny

Symas.com
directory.apache.org

[Frédéric Camblor]

<troll>

Gluon, c'est le toolkit utilisé sur l'app Devoxx pour générer une application scheduling de 100MB sur l'app store ?

Ah bah oui, sur iOS, il n'y a pas de JRE natif donc faut bien en embedder un dans son appli mobile pour que Java fonctionne...

</troll>

... au secours.

Frédéric Camblor  

BDX.io retired creator

Restx commiter

2017-04-07 16:46 GMT+02:00 Sebastien Bordes <sebastie...@gmail.com>:

C'est le but de leur startup: http://gluonhq.com après je ne peux pas en dire plus je n'ai plus trop suivi les évolutions.

Le 7 avril 2017 à 16:41, Cédric Beust ♔ <ced...@beust.com> a écrit :

2017-04-07 7:22 GMT-07:00 Sebastien Bordes <sebastie...@gmail.com>:

c'est Gluon qui s'y colle (les gens qui font/essayent du JavaFX mobile).

JavaFX mobile... En 2017, il y a encore des gens qui pensent que c'est une bonne idée.

Tragique.

-- 

Cédric

--
Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

Sébastien Bordes s...@jrebirth.org - jrebirth.org - blog

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

[Sebastien Bordes]

Chez Gluon il proposait 2 options:
_ utiliser la version iOS de l'OpenJDK
_ transpiler le code en utilisant roboVM (le code de l'appli etant donc native)

L'an dernier RoboVM a stoppé les dev : https://robovm.com/robovm-winding-down

Donc l'appli Devoxx malgré sa taille prouve que Java sur iOS c'est possible.... sans doute un petit coup de pub

Si GluonHQ ne met pas la clé sous la porte ca voudra dire qu'il y avait un marché répondant à un besoin pour ce genre de tambouilles même si technologiquement ce n'est pas l'idéal.

On verra bien, en tous cas pour l'instant ils continuent leur chemin en recevant régulièrement des arwards au JavaOne (petit coup de pouce d'Oracle qui leur a lachement délégué cette bataille)

[Sebastien Bordes]

Juste pour nourrir le troll.

https://www.developpez.com/actu/93818/La-communaute-OpenJDK-lance-Mobile-Project-pour-faciliter-le-developpement-sur-iOS-Android-et-Windows-Phone/
http://openjdk.java.net/projects/mobile/

:eot

[sebrau...@gmail.com]

On ne peut en effet pas faire tous les types d'IHM avec des technos web et on aura sûrement toujours besoin d'app lourdes pour gérer certaines problématiques moins courantes (ex. gestion de plusieurs écrans, gestion de flux de données temps-réel importants...).

On fait du JavaFX depuis java 7 et la situation s'est quand même bien améliorée. On a maintenant un framework relativement mature sans avoir recours à des cadriciels externes. Les property javaFX fonctionnent pas trop mal pour des modèles de données IHM et s'intègrent très bien avec des bibliothèques "reactives" comme RxJava. Certains collègues ont fait des composants avec AngularJS que l'on embarque dans des webviews mais je ne trouve pas qu'ils soient plus productifs.

Par contre, il reste à mon avis 2 points noirs assez importants :
- la lenteur des releases du JDK qui me semble incompatible des évolutions intrinsèques à un framework IHM
- l'incapacité de gérer ses propres contextes opengl (ex. avec jogl ou lwjgl)

Sébastien

[Sebastien Bordes]

Sébastien,

Quand tu dis que la situation s'est bien améliorée depuis Java7 tu penses à quoi ?

De même comment gérer vous la programmation concurrente et l'enchainement d'actions complexes, la communication asynchrone ? N'avez-vous pas développé en interne une 'tite surcouche maison ?

En parlant de Reactive Programming, quelle lib avez-vous utilisé, juste RxJava ou l'une des des autres dédiés à JavaFX sachant que l'une d'elle est synchrone dans le JAT (JavaFX Application Thread) ? Quelles sont vos REX ?

Seb

--
Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[sebrau...@gmail.com]

Sans parler de l'intégration de JavaFX au classpath, on peut citer l'apparition du TreeTableView, du TextFlow ou même des boites de dialogue en 8u40.

La seule surcouche maison que l'on a, mais qui n'est pas obligatoire, permet de gérer l'injection dans les node.

Nous utilisons uniquement RxJava avec du code qui ressemble à :

monService.getStream() //
    .observeOn(JfxScheduler.onJfx()) //
    .subscribe(this.someJfxAction);

si on a du code swing legacy, on peut même facilement enchaîner les actions :

monService.getStream() //
    .observeOn(Swingscheduler.onSwing) //
    .doOnNext(this::someSwingAction) //
    .observeOn(JfxScheduler.onJfx()) //
    .subscribe(this::someJfxAction);

Sur les property JavaFX, l'utilisation des opérateurs Rx combineLatest ou withLatestFrom permet aussi de simplifier pas mal de code IHM.

[Sebastien Bordes]

En fait je faisait allusion à cette phrase

> On a maintenant un framework relativement mature sans avoir recours à des cadriciels externes.

Les TextFlow, TreeTable et DialogBox ne sont pas non plus des révolutions mais si c'est très utile, je suis curieux de savoir comme scale les applications qui justement n'utilisent pas de cadricel applicatif (au sens JSR377).

Je ne comprend pas comment le côté reactive permet de se passer d' Application Framework

Il y a beaucoup d'aspects qui sont utiles à une "grosse" application:

• dependency injection via JSR330
• common application structure
• application life-cycle
• localized resources   
  
• resource injection   
  
• localized configuration   
  
• decouple state from UI (binding)   
  
• persistence session state (preferences)   
  
• action management   
  
• component life-cycle   
  
• light-weight event bus   
  
• honor threading concerns (specific to UI toolkit)
• application extensibility via plugins (implies modularity)

Autre point est ce que ca ce debug bien ces reactive stream ? J'ai recemment eu un souci avec un stream().forEach impossible a debugger mais résolu en le réecrivant avec une boucle foreach.

Concretement en francais ca fait quoi les 2 bouts de code et comment on chaine ca dans une application, chaque action utilisateur déclenche un stream ?, comment gérer vous les appels servers asynchrones ? comment gérez-vous la modularisation et la réutilisabilité

J'ai l'impression que le Reactive est une autre philosophie de codage mais qu'il manque un bout pour structurer son application, brej je ne demande qu'à être convaincu :)

Merci

--

Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Remi Forax]

De: "Sebastien Bordes" <sebastie...@gmail.com>
À: lescast...@googlegroups.com
Envoyé: Vendredi 21 Avril 2017 11:19:44
Objet: Re: [LCC] JavaFX

En fait je faisait allusion à cette phrase
> On a maintenant un framework relativement mature sans avoir recours à des cadriciels externes.

Les TextFlow, TreeTable et DialogBox ne sont pas non plus des révolutions mais si c'est très utile, je suis curieux de savoir comme scale les applications qui justement n'utilisent pas de cadricel applicatif (au sens JSR377).

Je ne comprend pas comment le côté reactive permet de se passer d' Application Framework

Il y a beaucoup d'aspects qui sont utiles à une "grosse" application:

• dependency injection via JSR330
• common application structure
• application life-cycle
• localized resources   
  
• resource injection   
  
• localized configuration   
  
• decouple state from UI (binding)   
  
• persistence session state (preferences)   
  
• action management   
  
• component life-cycle   
  
• light-weight event bus   
  
• honor threading concerns (specific to UI toolkit)
• application extensibility via plugins (implies modularity)

Autre point est ce que ca ce debug bien ces reactive stream ? J'ai recemment eu un souci avec un stream().forEach impossible a debugger mais résolu en le réecrivant avec une boucle foreach.

Tu as utilisé Stream.peek ?

http://download.java.net/java/jdk9/docs/api/java/util/stream/Stream.html#peek-java.util.function.Consumer-

Concretement en francais ca fait quoi les 2 bouts de code et comment on chaine ca dans une application, chaque action utilisateur déclenche un stream ?, comment gérer vous les appels servers asynchrones ? comment gérez-vous la modularisation et la réutilisabilité

J'ai l'impression que le Reactive est une autre philosophie de codage mais qu'il manque un bout pour structurer son application, brej je ne demande qu'à être convaincu :)

Merci

Une API réactive te permet de faire des appels asynchrones sans avoir une callback dans une callback dans une callback.

Etre asynchrone est pas forcément important partout, c'est important si tu appels différents services (pense service REST) et que tu ne controles pas la latence de la communication.

Le problème d'une API reactive est que tu dois être Réactive de bout en bout, donc ton accès à la BDD doit être reactive, ton access HTTP ou message queue doit être reactive, ton server frontal web doit être réactive, etc,

c'est du au faite que ton algo de back pressure, (le truc qui demande au fournisseur de donnée d'aller moins vite car le consommateurs est lent) doit connaitre les producteurs et les consommateurs.

En résumé, faire une appli CRUD où tu controles la BDD à pas beaucoup d'intérêt en reactive, par contre, la même appli mais qui va taper sur une BDD distance chez un fournisseur, là ça vaut le coût.

Les APIs réactives ne sont pas la seule façon de faire des appels asynchrones, le mecanisme async/await et les coroutines (les goroutines par exemple) permettent aussi de résoudre ce problème avec un code qui ressemble plus à des appels bloquant, les modèles à base d'évènements (par exemple la gestion des évènements de elm) est une autre façon.

Rémi

Le 20 avril 2017 à 20:14, <sebrau...@gmail.com> a écrit :

Sans parler de l'intégration de JavaFX au classpath, on peut citer l'apparition du TreeTableView, du TextFlow ou même des boites de dialogue en 8u40.

La seule surcouche maison que l'on a, mais qui n'est pas obligatoire, permet de gérer l'injection dans les node.

Nous utilisons uniquement RxJava avec du code qui ressemble à :

monService.getStream() //
    .observeOn(JfxScheduler.onJfx()) //
    .subscribe(this.someJfxAction);

si on a du code swing legacy, on peut même facilement enchaîner les actions :

monService.getStream() //
    .observeOn(Swingscheduler.onSwing) //
    .doOnNext(this::someSwingAction) //
    .observeOn(JfxScheduler.onJfx()) //
    .subscribe(this::someJfxAction);

Sur les property JavaFX, l'utilisation des opérateurs Rx combineLatest ou withLatestFrom permet aussi de simplifier pas mal de code IHM.

--
Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.

Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

Sébastien Bordes s...@jrebirth.org - jrebirth.org - blog

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.

[Sebastien Bordes]

Oui justement c'est le "bout en bout" qui me fait peur pour une grosse application  JavaFX.

La lib ReactFX fait du reactive synchrone dans le thread graphique et je me demande si cela ne peut pas être source de lag ou de freeze si un clic utilisateur lance un appel distant, à l'inverse si on utilise des streams multi-threadé (comme dans RxJava et peut-être RxJavaFX) comment se fait le join dans le thread graphique (en utilisant JfxScheduler.onJfx()?)



De nombreux cadriciel n'utilisent que des lambdas avec le Platform.runLater et Cie, d'autres proposent des action/commandes associés à un thread voire une surcouche au Service de JavaFX qui définit des Task (c'est ce que fait JRebirth en assignant une méthode d'une classe (= 1 composant) à une Task executé dans un thread pool).

Donc ma question est de savoir comment on gère tout ces streams dans l'architecture de l'application sans cadriciel supplémentaire. C'est comme le fameux AfterburnerFx quitient en 4 classes et 1000 lignes ca marche bien ;mais ca répond pas à tous les besoins évoqués plus haut.




Au sujet du peek je n'ai jamais essayé merci pour l'info je tenterai le coup la prochaine fois !





Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

Sébastien Bordes s...@jrebirth.org - jrebirth.org - blog

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.

Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Cédric Beust ♔]

2017-04-21 4:19 GMT-07:00 Remi Forax <fo...@univ-mlv.fr>:

Le problème d'une API reactive est que tu dois être Réactive de bout en bout, donc ton accès à la BDD doit être reactive, ton access HTTP ou message queue doit être reactive, ton server frontal web doit être réactive, etc,

Je ne vois pas pourquoi. Tu peux introduire ça très graduellement dans ton application.

Il y a quelque temps, c'est exactement ce que j'ai fait dans une appli Android assez complexe. J'ai commencé par introduire Rx dans la couche réseau. L'appli communiquait avec le serveur avec à la fois JSON et des protobufs, donc j'ai changé la couche à ce niveau pour émettre des paquets façon Rx au lieu de l'approche traditionnelle.

Ça a très bien marché, donc l'étape suivante, ça a été de remplacer des aspects de l'interface graphique avec Rx. La aussi, très bon résultats et des simplifications de logique vraiment convaincantes (comme par exemple gérer un Text Field qui fait de la complétion automatique de texte, appels réseau, filtrage de caractères, etc...).

Bref. Rx, tu peux vraiment l'introduire très progressivement dans ton code, et c'est en partie la raison de son succès.

-- 

Cédric

[Cédric Beust ♔]

2017-04-21 4:19 GMT-07:00 Remi Forax <fo...@univ-mlv.fr>:

les coroutines (les goroutines par exemple)

À noter aussi: Kotlin supporte les coroutines et je trouve leur approche très élégante.

​

-- 

Cédric

[sebrau...@gmail.com]

Le vendredi 21 avril 2017 11:19:46 UTC+2, Sebastien Bordes a écrit :

En fait je faisait allusion à cette phrase
> On a maintenant un framework relativement mature sans avoir recours à des cadriciels externes.

Les TextFlow, TreeTable et DialogBox ne sont pas non plus des révolutions mais si c'est très utile, je suis curieux de savoir comme scale les applications qui justement n'utilisent pas de cadricel applicatif (au sens JSR377).

Je ne comprend pas comment le côté reactive permet de se passer d' Application Framework

Ce n'est pas le côté reactive qui permet de se passer de framework applicatif mais plutôt le fait que JavaFX est déjà un framework en lui-même et, en utilisant quelques bibliothèques à côté, on ne ressent pas le besoin d'en avoir un.

 

Il y a beaucoup d'aspects qui sont utiles à une "grosse" application:

• dependency injection via JSR330

 Notre choix s'est porté sur Guice en utilisant bien javax.inject dans nos composants.

• common application structure
• application life-cycle

Pas de besoin particulier à part la gestion de l'injection par étape pour avoir une belle barre de progression.

• localized resources   
  
• resource injection   
  
• localized configuration
  

On utilise de classiques ResourceBundle java.

• decouple state from UI (binding)   
  

Intégré à JavaFX

• persistence session state (preferences)   
  

Preferences Java avec une chtite API Rx pour le côté flux d'évènements et faire un peu de composition avec, par exemple, des flux issus de properties javaFx).

• action management   
  
• component life-cycle   
  

Pas eu de besoins sur cet aspect.

• light-weight event bus   
  

On évite les bus génériques et on a plutôt tendance à préférer plusieurs PublishSubject de RxJava encapsulés dans des classes explicites.

• honor threading concerns (specific to UI toolkit)

Scheduler Rx cf message précédent

• application extensibility via plugins (implies modularity)

On gère ce besoin au niveau de l'injection.

Autre point est ce que ca ce debug bien ces reactive stream ? J'ai recemment eu un souci avec un stream().forEach impossible a debugger mais résolu en le réecrivant avec une boucle foreach.

Concretement en francais ca fait quoi les 2 bouts de code et comment on chaine ca dans une application, chaque action utilisateur déclenche un stream ?

Tout dépend de ce que fait l'action utilisateur. Si ça reste dans l'UI, il se peut que l'action modifie simplement le modèle de la vue. Dès qu'il y a un appel distant, ou même à une requête en base qui est bien un appel distant, on déclenche bien un flux même si le terme en anglais est "subscribe".
 

, comment gérer vous les appels servers asynchrones ?

Si on prend le code précédent, qui pourrait être dans un handler de bouton :
- le subscribe est bien fait après le clic
- le service va renvoyer des éléments de réponse dans le flux qui seront gérés dans le thread JavaFX dans la méthode someJfxAction
 

[Sebastien Bordes]

Donc pour résumer vous utilisez du JavaFX raw + RxJava + Guice, donc vous utilisez des cadriciels externes assez structurant dans la façon de coder.

Concernant le découpage de votre application utilisez-vous du fxml+controller ou une Macro classe dans laquelle vous gérer l'arbre graphique et tous vos streams Rx.

De même combien de vues différentes avez-vous ? pour combien d'instances en mémoire ?

Merci pour tes réponses.

--
Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Remi Forax]

Je viens de voir Andrei à Mix-it :)
Il avait un super talk sur les coroutine au JVM Summit l'année dernière.

Je sais pas si tu as vu que l'approche utilisée était déjà celle de C#, transformation par le compilo en state machine mais quand JetBrain à expliquer que
- l'on pouvait abstraire l'interface qui wrap un résultat
- que l'on peut coder async et await purement en lib,
Microsoft a immédiatement ajouter ces fonctionnalités dans C# 7.

En Java, l'idée est d'avoir le support dans la VM, mais pas avant Java 12, d'ici là on sera en 2026.

Rémi

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Remi Forax]

Merci de me rappeler qu'il y a pas que le côté serveur dans la vie, j'oublie rapidement.

Donc je reformule, côté serveur, si tu veux pas épuiser rapidement ton pool de worker threads tu va rapidement utiliser le mécanisme de back pressure qui te demande d'utiliser l'approche réactive de bout en bout.

Côté client, à part quand tu utilises un AsyncTask/SwingWorker, où ralentir le download de donnée de services car l'affichage est lent / l'utilisateur a pas scroller peut avoir un intérêt, tu as plutôt un utilisateur et pas un millier de client, donc oui, tu peux faire les trucs de façon plus incrementale.

Rémi

[sebrau...@gmail.com]

Donc pour résumer vous utilisez du JavaFX raw + RxJava + Guice, donc vous utilisez des cadriciels externes assez structurant dans la façon de coder.

J'ai l'habitude de dire que ce sont des bibliothèques et pas des cadriciels mais c'est juste une question habituelle de vocabulaire :-) et je pense que l'on se comprend.

Concernant le découpage de votre application utilisez-vous du fxml+controller ou une Macro classe dans laquelle vous gérer l'arbre graphique et tous vos streams Rx.

On utilise principalement du fxml + controler avec parfois uniquement du code quand le fxml se fait trop lent ou n'est simplement pas adapté.
 

De même combien de vues différentes avez-vous ? pour combien d'instances en mémoire ?

On doit avoir de l'ordre de la centaine de nœuds avec moins du milliers d'instances. Je vérifierais le nombre d'instances quand j'aurais le temps de lancer l'app.
 

[Henri Tremblay]

Cadriciel a toujours raison :-)

http://www.granddictionnaire.com/ficheOqlf.aspx?Id_Fiche=8872480

Et quelques synonymes

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

[Sebastien Bordes]

La dernière fois que j'ai utilisé le mot cadriciel pendant une réunion on m'a demandé si j'étais québecois ... ;)

L'avant dernière fois, on m'a dit: "Hein ?! qu'est ce que c'est ?" ...

Sébastien, merci pour tes réponses, je suis d'accord avec ta terminologie mais on peut sans doute affirmer que ce petit ensemble de bibliothèques (et la glue qui va autour)  forme un cadriciel de facto car il conditionne la structure du code de l'application.

Concernant la volumétrie, il est vrai qu'un cadriciel applicatif est encore plus utile pour une application  de plusieurs centaines de noeuds avec plusieurs centaines de milliers voire millions d'instances. Das le monde du modeling, on parle d'objets sémantiques (=POJO); pouvant se compter en millions dans des projets industriels; et d'objets graphiques étant une vue configurée de l'objet sémantique.

Du coup il est important de bien géré la mémoire pour pouvoir relacher tout ce qui n'est plus afficher quand le heap plafonne, de même la répartition dela charge sur plusieurs thread avec du code réutilisable permet de favorisé la modularité et la factorisation du code.

C'est à mon sens toute la puissance ce certains cadriciel applicatif, même si on peut les utiliser pour de plus petit projets afin de bénéficier de leur structure.

Le 25 avril 2017 à 04:05, Henri Tremblay <henri.t...@gmail.com> a écrit :

Cadriciel a toujours raison :-)

http://www.granddictionnaire.com/ficheOqlf.aspx?Id_Fiche=8872480

Et quelques synonymes

2017-04-24 17:43 GMT-04:00 <sebrau...@gmail.com>:

Donc pour résumer vous utilisez du JavaFX raw + RxJava + Guice, donc vous utilisez des cadriciels externes assez structurant dans la façon de coder.

J'ai l'habitude de dire que ce sont des bibliothèques et pas des cadriciels mais c'est juste une question habituelle de vocabulaire :-) et je pense que l'on se comprend.

Concernant le découpage de votre application utilisez-vous du fxml+controller ou une Macro classe dans laquelle vous gérer l'arbre graphique et tous vos streams Rx.

On utilise principalement du fxml + controler avec parfois uniquement du code quand le fxml se fait trop lent ou n'est simplement pas adapté.
 

De même combien de vues différentes avez-vous ? pour combien d'instances en mémoire ?

On doit avoir de l'ordre de la centaine de nœuds avec moins du milliers d'instances. Je vérifierais le nombre d'instances quand j'aurais le temps de lancer l'app.
 

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.

Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/lescastcodeurs/TnLYrScJOrs/unsubscribe.

Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescastcodeurs@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.