Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
L'état de l'art est qu'on a pas besoin de fournir la JVM en bundle avec l'application. SWT, si. Et on ne peut pas juste mettre les jars pour tous les OS, ça ne marche pas. Ça oblige à faire de la gestion d'installation dont on se passe en général très bien en Java.
Il le fait déjà depuis des années (cf. autoboxing de Java 5, avec des appels cachés à Xxx.valueOf et .xxxValue)Envoyé par sekaijin
Tout en Java passe toujours par valeurs :-) et quand on manipule une référence, oui c'est la valeur de la référence qui est passée. Mais dire que les primitifs passent par valeur et les objets par référence est un raccourci un peu hum... réducteur...
Oui, le web c'est la jungle... Mais une fois qu'on s'est mis à l'aise avec les outils à disposition, il suffit d'oublier ceux qui ne nous plaisent pas... Alors ok, au début c'est compliqué et la learning curve est mauvaise. Mais c'est comme tout, une fois appris, ça devient facile.
Java, c'est clairement un langage de professionnels qui vont l'utiliser pendant des années. Alors ça me dérange pas de galérer 6 mois puis d'en tirer des bénéfices pendant 20 ou 30 ans, avec des petits refresh tous les 6 mois
Le parallèle avec la JVM est osé, ce serait un peu comme si tu développais une application windows et tu demandais au client d'installer l'OSUn peu comme la JVM en fait
Quand on développe un soft, on ne fournit pas la jvm, on demande une version minimum tout au plus
Je comprends pas trop. SWT ne demande pas a l'utilisateur d'installer des trucs en plus, c'est juste des jars...Le parallèle avec la JVM est osé, ce serait un peu comme si tu développais une application windows et tu demandais au client d'installer l'OS
Des jars qui ne sont pas les mêmes d'un OS à l'autre, ni d'un bus à l'autre depuis x64.
L'Etat de Java : où en est la technologie en 2014 ? (part. 2)
L'Etat de Java : où en est la technologie en 2014 ?
2ème partie de l'entretien avec le CTO France, le responsable du pôle JAVA et un expert de DigitasLBi
Après la première partie publiée la semaine dernière, voici comme promis la deuxième de cet entretien avec Arnaud Defrenne (CTO France), Romaric Le Bever (responsable du pôle JAVA) et Cedrik Lime (expert Java) de DigitasLBi.
Pour rappel, il nous a paru intéressant de dresser cet « État de Java », sur le modèle de l'« État de l'Union » en politique, au regard du flux continu de news et de « trolls » qui alimentent les gazettes et qui, à la longue, aveuglent.
Pourquoi avec DigitasLBi ? D’abord, parce que DigitasLBi – un réseau d'agences de « digitalisation & d'innovation technologique » (6.000 experts dont 300 en France) qui gère des projets globaux pour des marques comme Nissan, eBay, American Express ou La Poste - n’est lié à aucun éditeur (voir aussi : sa page sur Developpez.com)
Ensuite, parce que cette agence d’un nouveau genre se place à la croisée d’une multitude de chemins (beaucoup plus que les ESN) : communication numérique, design d’UI, développement (de Java au HTML, CSS, JS en passant par .NET ou l’embarqué). Enfin - et surtout - parce que son pôle Java/JEE est un nid d'expertises.
Dans la première partie nous avions abordé avec eux la popularité du langage, sa sécurité, Java 7 et Java 8, et le virage vers l’embarqué. Dans cette deuxième partie il est question de JaaS, de Java One, de Frameworks, de GlassFish, du marché de l’emploi ou encore d’Android.
N'hésitez pas à nous faire part de vos propres points de vue d’experts et à interagir avec eux (nous savons de source sûre qu'ils gardent un œil sur Developpez.com).
Developpez.com : Une des grandes annonces de cette année au Java One a été l’arrivée d’un JaaS (Java as a Service), pouvez-vous nous déchiffrer de quoi il s’agit ?
DigitasLBi : Le JaaS est “simplement” la possibilité d’utiliser un seul et unique serveur d’application en mode multi-tenant (i.e. pour plusieurs clients), avec une parfaite isolation entre les clients. C’est également la possibilité pour une application unique de servir plusieurs clients, toujours avec une parfaite isolation.
Je pense que cette annonce est surtout destinée à certains hébergeurs comme OpenShift ou CloudFoundry. Les éditeurs de logiciels multi-tenant n’ont pas attendu Oracle pour sortir leur produit !
Nous préférons quant à nous dédier une JVM par application pour des raisons de facilité d’administration (nos applications sont très souvent spécifiques client).
L’autre annonce majeure de JavaOne a été la libération du code de JavaFX, ainsi qu’une amélioration très substantielle de ce dernier, même si nous n’utilisons pas cette technologie dans nos métiers à DigitasLBi.
Developpez.com : Autre annonce phare de ce Java One : Avatar devient open-source. Pouvez-vous nous en dire plus sur ce projet - qui mélange Java, JavaScript, HTML 5, CSS et NoSQL - et sur son intérêt pour les développeurs ?
DigitasLBi : Nous sommes bien évidemment très intéressés par tout projet “révolutionnaire” qui permet d’adresser la problématique complexe des interfaces riches. Nous attendons néanmoins de voir si Avatar fera ses preuves ; jusqu’à maintenant on ne peut pas dire que JavaFX soit un succès retentissant…
Developpez.com : Le serveur d’application GlassFish va connaitre une mise à jour (4.1) l’année prochaine et une version 5 est annoncée. Mais son support commercial est arrêté et Oracle recommande de préparer une migration vers WebLogic Server. Ce qui n’a pas manqué de créer des polémiques. Comment analysez-vous la chose ? GlassFish est-il mort ?
DigitasLBi : GlassFish est l’implémentation de référence de Java EE. En tant que tel, il est intéressant de le suivre pour voir où la norme va.
Maintenant, Oracle a un problème de duplication de ressources avec un nombre fantastique de serveurs d’applications : WebLogic, OC4J, GlassFish… du ménage s’impose !
Je pense qu’Oracle voudra conserver en interne l’implémentation de référence Java EE, et conservera donc WebLogic en produit commercial, et GlassFish en “référence pure”.
Developpez.com : Il y a deux ans, on a vu une multiplication des frameworks Java. Qu’en est-il aujourd’hui ? Quelles sont ceux qui méritent que l’on s’intéresse à eux de près (Spring, Leonardi, Hibernate…) ?
DigitasLBi : Aujourd’hui, nous avons dépassé l’étape framework. Bien sûr, ceux-ci sont toujours aussi importants pour accélérer les développements, mais nous assistons maintenant au développement du Service. Voyez par exemple le formidable essor d’Hadoop (et ses nombreux dérivés) ou plus récemment d’ElasticSearch.
À contrario, le formidable bouillonnement autour des frameworks web d’il y a 2-3 ans (Tapestry, Wicket, Struts 2, Stripes, Spring MVC, GWT, JSF, Play, Click, &c) est maintenant froid : tous ou presque continuent d’être développés, mais la compétition n’est plus là.
Il y a 5 ans, nous développions des outils de recherche au-dessus de Lucène (framework) ; maintenant nous déléguons à ElasticSearch (produit / service), tout en profitant de ses formidables fonctionnalités.
Cela complexifie un peu l’architecture de déploiement et d’exploitation, mais cela permet une vision plus macro des problématiques de type Big Data.
Developpez.com : L’année dernière, un de ces frameworks, justement, a été au cœur de l’actualité. Il s’agit de Spring. Oracle ne semble pas l’apprécier. La version 4.0 de Spring est sortie cette année, avec le support, déjà, de fonctionnalités de Java 8. Comment analysez-vous cette « rivalité » ? Et les atouts de Spring par rapport à JEE ?
DigitasLBi : Spring et Java EE ont historiquement toujours été des rivaux, Spring étant à l’origine né de la difficulté d’intégration et d’utilisation des technologies Java EE.
Depuis, les deux protagonistes ont énormément évolués, et chez DigitasLbi nous pensons que les deux “stacks” sont facilement exploitables par les développeurs. C’est maintenant plus une question d’habitude et de connaissances en interne.
Developpez.com : Côté marché de l’emploi, Java fait-il partie des compétences que vous recherchez le plus ou la montée en puissance d’autres langages (HTML 5, JS, Objetcive-C, etc.) l’a-t-il relayé en deuxième rang de vos priorités de recrutement ?
DigitasLBi : C’est une des compétences que nous recherchons le plus. Mais HTML 5 et JavaScript arrivent juste après. Plus généralement, nous pensons que l’informatique est un très bon débouché, le marketing Digital en particulier. Et Java aussi !
Chez DigitasLBi en tout cas nous pensons proposer des carrières passionnantes sur la durée, avec la chance de se trouver au cœur de la transformation numérique des marques qui s’adressent à nous pour repenser les opportunités de contact avec les consommateurs numériques. Cela ouvre de nombreux métiers. Et nombreux sont les développeurs qui restent longtemps chez nous et qui évoluent vers plus de management, de marketing , de commercial, ou plus d’expertises.
Developpez.com : Dans le mobile, Java est connu pour être LA technologie derrière Android. Depuis le rachat de Sun par Oracle, un procès fleuve est en train de se dérouler. En tant qu’expert Java, avez-vous un pronostic sur son issue et/ou sur l’avenir d’Android ?
DigitasLBi : Non pas de pronostique sur le résultat légal !
Mais nous pensons qu’il y a un enjeu évident que certains systèmes d’exploitation et langage qui sont les plus utilisés dans le monde entier sur tous les terminaux puisse rester de libre d’usage pour tous.
De ce point de vue quand les grands éditeurs rachètent ou éditent des solutions open-source, on voit que leur aide est précieuse pour financer les projets… mais on s’expose toujours tôt ou tard à un risque de conflit d’intérêts. Une fois qu’une technologie est largement utilisée par tous, on ne peut qu'espérer que son statut ne change pas, ce qui aurait pour conséquence désastreuse de rendre illégale toutes les applications qui l’utilisent !
Developpez.com : Un article de Développez.com titrait récemment : « Un développeur PHP n'est pas moins compétent qu'un développeur Java ou C++ ». @Cédrik, je sais qu’il vous a fait sourire. Pourquoi ?
DigitasLBi : Nous ne faisons aucune différence en effet et cherchons avant tout des talents pour poursuivre notre développement, dans chaque langage. Mais les développeurs ont des égos et aiment la compétition. Et c’est une bonne chose !
Publications techniques et offres d’emplois de DigitasLBi sur Developpez.com
Cet article (qui titre a propos des IDE plutot que du runtime mais qui ne parle pas que de ca) revient pas mal sur le debat Spring vs JEE. http://martijndashorst.com/blog/2014...ive-first-day/
La morale, c'est que maintenant, il est parfois (souvent?) plus complique d'integrer Spring dans un Tomcat et d'ajouter plein de libs en fonction des besoins, que d'utiliser un serveur JEE qui fournit deja tout dans un bon etat de fonctionnement.
Je suis un peu déçu par la seconde partie car elle ne contient pas grand chose comme info (plus des opinions que des remises à plat d'informations).
La première partie m'a nettement plus plu.
Je rejoins le point de vue de DigitasLBi.Developpez.com : Un article de Développez.com titrait récemment : « Un développeur PHP n'est pas moins compétent qu'un développeur Java ou C++ ». @Cédrik, je sais qu’il vous a fait sourire. Pourquoi ?
DigitasLBi : Nous ne faisons aucune différence en effet et cherchons avant tout des talents pour poursuivre notre développement, dans chaque langage. Mais les développeurs ont des égos et aiment la compétition. Et c’est une bonne chose !
Un bon développeur est avant tout doué en algorithmie et en conception.
Ensuite, l'expérience sur un langage fait le reste (connaissance des librairies et gestion de la mémoire propre à chaque langage).
Chaque langage a ses atouts, tout dépend ce que l'on veut faire.
Si on veut faire du calcul scientifique avec de la virgule flottante à tout va, on ne fait pas de Java.
Si on veut faire web, on ne fait pas de l'ADA.
Je crois que le fait de penser que c'est principalement ça qui pousserait un développeur à migrer de Swing ou Swt vers JavaFX serait une erreur, ce n'est pas juste une question d'animation, d'effets et de 3D.
JavaFX est une api construit à partir de zéro et une architecture bien pensée, et j'aurais aimé souligner qu'en JavaFX on retrouve:
- Une très bonne api de gestion des beans et simple à utiliser, qui permet la gestion facile de l'aspect dynamique des interfaces et la mise à jour des données avec le concept du binding, Tout contrôle qui s'affiche devant vous, c'est que derrière il y a un ensemble de propriétés(beans) qui définissent son comportement, chaque propriété peut être bindé avec un autre pour synchroniser ou non les modifications, comme il peut être la cible d'un événement et on peut écouter son changement de façon synchrone ou asynchrone selon notre choix. Sans pour autant nier la faisabilité de cela en Awt/Swing et Java2D, ou SWT mais je parle d'une architecture bien pensée à l'avance et simple à manier. Et pourquoi réinventer difficilement la roue alors qu'il y a ce qui est déjà servi et bien conçu.
- JavaFX est la meilleur API Java en matière de simplification à la conception d'applications suivant le pattern MVC, certains voient que le support de MVC en Swing pour manque de cohérence dans certains cas.
- Comment faites-vous pour personnaliser le Look&Feel de vos interfaces en SWT et en Swing? et avec quel coût? et pour quel résultat? Alors qu'en JavaFX vous programmer vos interfaces en toute tranquillité et après avec les feuilles de styles CSS vous faites tout ce que vous voulez en matière de style.
- Le langage FXML que vous pouvez adopter si vous voulez, et l'outils Scene Builder qui permet de concevoir rapidement l'UI en FXML et personnaliser après avec les CSS. Et tout est conçu à l'avance pour aller avec le pattern MVC.
- Alors les fan de gestion de contenu multimédia, ils vont trouvent ce qu'ils veulent, de même que les développeur de Jeux 3D, mais surtout le fait que JavaFX soit écrit à partir de zéro, de la base profonde, ça lui permet d'exploiter des nouvelles technologies graphiques des puissantes cartes graphiques modernes qui embarquent le GPU avec, ainsi ça offre une nouvelle expérience.
- Interopérabilité avec Swing et SWT, après la sortie de JavaFX 2.0, l'équipe JavaFX avait développé JFXPanel et FXCanvas pour permettre d'intégration de JavaFX respectivement dans Swing et SWT, ceci afin de permettre l’extension des interfaces existantes ou cas où on veut ajouter, des composants avec des effets ou des transitions à des interfaces existantes vu que cela n'était pas possible, après maintenant ils ont développé SwingNode pour intégrer Swing dans une application JavaFX existence, et récemment j'ai vu un article quelqu'un qui expliquait comment intégrer Swing,SWT,et JavaFX ensemble et les forcer à s’exécuter dans le thread JavaFX.
- .......
Personne ne nie que un API comme Swing est très riche et il y a quelques composants en Swing qui ne sont pas encore développés en JavaFX, mais tout reste que JavaFX possède aussi des contrôles qui n'existent pas en Swing comme les Chart par défaut, ou recensement plusieurs contrôles, il y a même le contrôle qui ressemble carrément à une feuille de calcul comme Excel et beaucoup d'autres. Et l'interopérabilité permet de combler tout vide quel qu'il soit.
Nous sommes devant HTML5 et on ne peut rester les mains croisés si un besoin de performance ou autre se pressentent, et qu'on se trouve qu'on ne peut pas faire exactement en natif ce que HTML5 fait dans le web, pour la pure et simple raison qu'on n'arriverait pas à réaliser cela avec Swing ou SWT. Bienvenue JavaFX!!
J'ai bien aimé le fait de voir que depuis la sortie de Windows 8, un développeur a pu reproduire le style Moderne UI en JavaFX rien qu'avec les css comme vous voyez dans ces images:
C'est du JavaFX personnalisé avec css en Fait.
Pièce jointe 138533
J'aurais une question à poser sur Java FX.
Existe-il un designer comme Microsoft blend en .net qui gère les styles , les storyboards ( GPU accéléré) etc...
sans pondre du code et en permettant une prévisualisation des animations sans compilation.
En Xaml on a la notion de template (en plus des styles) pour changer notamment la structure d'un contrôle simplement
( exemple remplacer une progressBar par un thermométre dont la température progresse de manière animée)
Le css +fxml permet-t-il de gérer simplement ça ?
Pour ce qui est de la génération de styles css et de code pour les animations on utilise FX Experience Tools et on visualise ce qui ça donner sans être obliger de pondre du code.
De même, avec certaines limite, pour ce qui est de la modification de l'apparence et l'ajout des effets(reflexion, trensparence, ombre..) et la prévisualisation des styles en Css on utilise JavaFX Scene Builder, mais Scene Builder ne génère pas de code css à votre place mais il applique ces modifications sur le fxml, mais il permet aussi avec autocompletion(v2.0) de choisir vous même les styles css que vous voulez appliquez, ou intégrer un fichier existant et visualiser le comportement sans être obligé de faire de la compilation.
Alors je vais essayer de vous expliquer une chose très importante existante en JavaFX et l'approche qui permet de réaliser facilement ce que vous dites. D'abord en JavaFX on a la notion de Skin qui est une classe qui communique avec un Behaveor et le Control, pour former le controle en sa totalité. Ainsi, il faut comprendre qu'en JavaFX chaque contrôle obéit au modèle MVC : le M:Model est représenté par le Control en soi, la classe qui s'en charge de garder l'état du control en détenant l'ensemble des propriétés du control, les propriétés sont des beans comme j'ai expliqué au premier message, et le V:view : c'est le Skin, la classe qui gère la partie Look&Feel du control, ainsi on sépare la partie look&Feel du Control avec les interaction de l'utilisateur. Et enfin le Behaveor qui n'est autre que le C: controlleur, c'est celle qui encapsule l'ensemble des interactions de l'utilisateur(clique de la souris, taper sur clavier, bouger le molette de la souris....)
Ainsi, l'habillage du control peut facilement être modifié en modifiant la variable skin sans que qu'on modifie ni son comportement ni son état, déjà les css s'applique à la classe SkinBase.
Ainsi, la logique fonctionnel d'un control est totalement séparée à son apparence, alors selon moi je ne vois pas encore le besoin de définir spécialement de Template dans le moment où chaque control tout son habillage est paramétrable et les propriétés(modèle) (sont des beans) qui peuvent êtres modifiés, écouter des événements et toutes les modifications se synchronisent entre tout, et on peut faire du binding partout et faire des animations personnalisé(pas les transitions par défaut) qui vont modifier les propriétés et le control agit en "temps réel". Et les CSS supportent les contrôles personnalisés et on peut créer des StealableProperties afin de permettre de styler les propriétés via CSS.
Alors pour l'exemple que tu as donné d'un progresse bar transformé en en thérmomètre cela est facilement faisable en JavaFX comme j'a dis l’apparence peut facilement changer et la logique fonctionnel du control reste le même et on peut ajouter des animations. Je vais te montrer un exemple d'application où on voit des contrôles par défaut, et vu que que tous les controles sont skinnables, alors dans la démo les controles sont skinné pour donner une apparence voulu mais derrière on a des controles connus et existant dans l'api JavaFX, regarde la vidéo suivante et tu peux retrouver le code source ici
Tout reste qu'avec JavaFX8 la notion de Skin à un peu évolué, bien développé et a subit quelques modifications, (on attend la version finale en Mars), déjà l'API SkinBase était privé c'est récemment qu'il est rendu publique pour permettre de créer des contrôles customisés et le BehavorBase reste encore privé. Mais la nouveauté avec JavaFX8 c'est qu'il est désormais possible de créer toute une classe à part avec nouveau Look&Feel qui implémente l'interface Skin et le spécifier dans le fichier css comme suit:
A noter que les attribuits css de JavaFX ne sont pas forcement ceux de html5.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4.custom-control { -fx-skin: com.javafx.customControl.skin.CustomControlSkin; }
EDIT: Je n'ai aucune expérience en Xaml mais je me suis basé sur ce que tu as dis et l'exemple que tu as donné
très belle réponse , je vais essayer de voir ce que ça donne, j'avais déja essayer java fx , mais au tout début de sa création. D'après ce que tu me montre , ça a évolué, j'ai donc besoin d'en apprendre plus par la pratique pour pouvoir émettre un jugement face à XAML.
J'ai vu tu as écris deux fois Java FX en séparant le FX avec le mot Java, alors je tiens juste te rappeler que les deux ne se séparent pas ce n'est pas comme Java EE ou Java SE, car le EE ou le SE sont des abréviations, mais JavaFX c'est un mot à part entière crée pour désigner cette technologie c'est comme si tu dit Swing, SWT, Silverlight, Flex... certes le terme FX veut désigner "Flexible" mais la technologie s'appel JavaFX en un seul mot. Déjà, en dehors de FXML et css, ce n'est pas forcement avec le langage Java qu'on code les applications JavaFX, avec l'arrivé de JavaFX 2.0 tous les langages supportés par le JVM sont supportés aussi notamment Groovy, Scala, Visage ....
En fait tu te méprends sur les templates dont il parlait.
En WPF l'apparence et la logique d'un contrôle sont également séparés. Ainsi un bouton a une propriété "Template" qui définit son apparence (et une propriété ContentTemplate si l'on veut seulement personnaliser l'aspect du contenu du bouton) et en-dehors de cela un bouton n'est qu'une logique et n'a aucune apparence propre. Template WPF et Skin Java FX me semblent donc fonctionnellement équivalents. De même que pour de simples changements de couleur WPF a des styles équivalents à ceux de CSS (mais moins puissants et plus lourds à vrai dire).
La grosse différence il me semble c'est que côté WPF le template est défini en XAML (le langage UI) plutôt qu'en C#/VB, tandis qu'en JavaFX une skin est codée en Java plutôt qu'en FXScript. Et du coup c'est plus facile en WPF : on spécifie directement un arbre visuel avec ses animations et tout le reste (plutôt que d'avoir à le rebâtir à la main en Java), et surtout le lien avec les propriétés du contrôle "skinné" est fait très simplement via des déclarations comme <TextBlock Text="{TemplateBinding Content}"/>, là où en Java il faudra souscrire aux abonnements du "skinné" pour détecter les changements de propriétés.
Du coup il me semble qu'une skin en java contient pas mal de plomberie là où un template en WPF se résume presque uniquement à la spécification de l'arbre visuel désiré.
Un simple exemple.
Je m'excuse d'abord du fait qu'on pense comme si je banalise ou je méprend les Template en XAML, car je voulais juste dire qu'au début j'ai pensé à l'objectif visé en spécifiant un exemple à réaliser comme le cas souligner avec le progress bar. Mais après avoir vu aussi à quoi ça ressemble et l'objectif des Template en XAML, ça m'a donné une idée maintenant sur quoi on veut arriver vraiment.
En plus de ça, étant donné que je suis fan de java je n'avais jamais pensé à cherché sur ce truc de Template ou semblable(pourtant ça existe en FXML) dans le moment où le même comportement on peut le réaliser en tout facilité avec Java et css . Et même si en FXML on avait assigné des valeurs figés aux contrôles mais on peut après avec le code Java et les css, faire ce qu'on veut. Et personnellement j'aime le pure java même pour les vues, car ça consomme moins de mémoire et il y a un gain de plus en performance, mais pour des raison de productivité on se retrouve avec FXML.
Mais bon, la question que je vois qui tu poses actuellement c'est une question de facilité et de gain en productivié. Alors, alors le fait de faire du binding en FXML comme vous faites avec les Template en WPF existe bien en JavaFX, pas besoin de souscrire aux abonnements du "skinné comme tu dis. Voici un exemple où je bind le contenu qu'un champs Text avec un Label, dès qu'on tape quelque chose sur le champs text ça s'affiche sur le label, voici le code source du fichier FXML, pas besoin de Java pour binder:
Alors j'ai fais un petit vidéo de 5min pour faire un petit exemple et exécuter pour voir ce que ça donne, sans pourtant tout expliquer les cas possibles d'exploitation de cette technique, j'ai montré aussi l’équivalent de ça en Java en simple binding. Alors je ne dis pas que ce que j'ai fais c'est 100% à la WPF vu mon manque de connaissance dessus, mais bon voyez un peu ce que ça donne et faites moi part de vos remarques.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
Alors comme vous voyez on est pas obligé d'enregistrer un événement pour écouter le changement et modifier, dans notre cas on a fait qu'on peut spécifier un property par défaut d'un champs existant dans l’arborescente du fichier fxml encours avec l'id, comme le textProperty d'un cahmps text, mais aussi on peut spécifier celle d'un autre fichier FXML gérer même par un autre controlleur, il reste savoir comment adapter le chemin en accédant à une proprieté qu'on peut accéder via un autres controlleur ....
De la même manière qu'on peut aussi créer une propriété à part entière variable membre du contrôleur, ou à l'extérieur dans une autre classe, on peut ajouter des controles et des format de contenu sur les données bindés ou peut animer, mais comme j'ai dis avant le Look&Feel peut se gérer via css, et on peut créer aussi des propriétés styllables, à paramétrer leurs changement sur les css. Alors j’attends vos feed back.
Je tiens à rappeler juste que FXScript est mort à présent on travail avec Java, FXML et CSS, depuis JavaFX 2.0, les choses ont carrément changé, côté architecture, performances et ce n'est pas lourd comme Swing, JavaFX est nativement bien intégré, l'api est en pure java mais l'execution se fait en grande partie en native pure ce n'est pas du baytcode interpreté, déjà ça , ça existait avant au debut de Java, pas les reccents JDK. De plus JavaFX exploite de l’accélération graphique matérielle car comme j'ai dis avant qu'il est réécris depuis la base, pas une simple couche sur le JDK, déjà c'est depuis JDK 8 que le jdk tout court commencera a pourvoir lancer des applications JavaFX, mais elles s'exécutent dans leurs propres threads, mais pas le thread Main d'une application java simple.
Ce n'était pas un reproche, nous avons tous deux une vue partielle de la situation du fait de nos expériences respectives. En fait j'ai trouvé ton premier message intéressant car je n'étais pas certain que JavaFX ait vraiment découplé logique et apparence, j'ai donc été heureux d'apprendre que c'est également le cas de ce framework.
Vraiment ? Tu ne parles pas de simples inclusions de fichiers tiers mais bien d'un mécanisme aussi puissant que les skins où l'on déclare l'arbre visuel directement en FXML ?je n'avais jamais pensé à cherché sur ce truc de Template ou semblable(pourtant ça existe en FXML)
Un petit exemple, si je veux une liste d'éléments représentés par une icône à côté d'un texte, et une disposition en grille, en XAML ça se fait à peu près aussi simplement que ça (un seul fichier) :
Code quasi-XAML : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
Concrètement avec JavaFX peux-tu faire ça entièrement en FXML ?
PS : les bindings sont en général vis-à-vis d'une classe "viewmodel" qui fait l'interface entre l'UI et le modèle de données. Par exemple on associera à une classe "Produit" une classe "ProduitVM" exposant des propriétés nécessaires à l'affichage.
PPS : le véritable code est un peu plus verbeux, un gros travers de XAML.
J'ai vu ça et je te remercie. Et je constate avec amusement que WPF et JavaFX ont opté pour la même solution moche consistant à exposer des objets représentant des propriétés UI via des membres "TextProperty" et autres.Alors j'ai fais un petit vidéo de 5min pour faire un petit exemple et exécuter pour voir ce que ça donne
FXML est interprété à l'exécution ? A nouveau même solution moche puisque c'est le cas de Xaml en WPF. Heureusement pour Modern UI ils sont passé à une génération de code.Et personnellement j'aime le pure java même pour les vues, car ça consomme moins de mémoire et il y a un gain de plus en performance, mais pour des raison de productivité on se retrouve avec FXML.
Erf, tu m'en vois bien déçu : le fait de ne pas avoir à se taper un code XML bien verbeux et moche était pour moi un gros avantage de JavaFX, même si la première mouture de FXScript laissait à désirer.Je tiens à rappeler juste que FXScript est mort à présent on travail avec Java, FXML et CSS, depuis JavaFX 2.0
Merci pour ta vidéo. Tu fais honneur à ta techno en prenant le temps d'expliquer
En effet ça a bien évolué et ça reprends beaucoup de concepts de WINFX (beta de wpf sortie en 2005).
PS : il me semble que le XAML est compilé en un langage intermédiaire en WPF.
Répondre avec citation
Partager