C’était vrai pour JavaFX 1 (c'est sur cela que le marketing de Sun s’était positionné d'ailleurs : ils ciblaient les designers) mais pas du tout pour JavaFX 2 et 8 je trouve : là, et depuis 2011, on est au même niveau que Swing ou AWT.Envoyé par 23JFK
Le FXML est :Le code d’intégration façon xml est encore plus obscure que la verbosité d'un pur java sans représenter un avantage réel pour un développeur qui doit réapprendre un n-ième pseudo langage alors qu'il connait très probablement déjà les API graphiques du langage.
- Complètement optionnel (tout comme l’était le FXD dans JavaFX 1 d'ailleurs).
- Beaucoup plus lisible et beaucoup moins lourd que ses équivalents XML chez Adobe ou Microsoft. C'est juste du code Java sous forme XML, c'est super-hyper-simpliste par rapport a ce que propose la concurrence.
(À noter que le FXD était quand mème plus simple que le FXML puisque c’était directement du JavaFX Script -un sous-ensemble, pas le langage complet- donc le même langage de programmation que celui employé par JavaFX 1 à l’époque).
Simplement on arrete pas de marteler qu'il faut toujours séparer la vue du modèle / contrôleur c'est pas pour rien car : c'est plus facile de manipuler visuellement le contenu d'un fichier FXML via SceneBuilder (ou a mano) pour faire des modifs dans une interface que d'aller bidouiller une classe Java de XXXXXX lignes de code de construction d'UI. Et je le répète, ça reste OPTIONNEL ! Si j'ai souvent opté pour FXML dans mes articles sur JavaFX c'est justement pour éviter de noyer l'article dans un flot de code Java uniquement destiné à placer un contrôle à un endroit précis de l’écran et ensuite à en changer le style / le LnF alors que le propos de l'article était bien ailleurs. C'est un peu comme si on reprochait l'usage d'un CSS (externe) dans du HTML : c'est quand même mieux quand le style est a part du contenu de la page, et la définition d'une <table> est plus facile à lire si y a pas des attributs de définition du style de 3km de long à chaque ligne.
Pour ce qui est de la qualité des produits Oracle sur JavaFX, là par contre effectivement, on a eut droit quand même a certains gros bugs tant sur le Rich Application Suite de JavaFX 1 que dans SceneBuilder pour JavaFX 2 & 8. Et Sun / Oracle etait long a sortir des patchs.
Je met plus ça sur le manque de moyens investis qu'autre chose : un truc choquant quand on va à la JavaOne c'est de se rendre compte combien certaines équipes d'Oracle sur certaines parties de Java sont toutes rikiti : j'ai l'impression que souvent on a des équipes de 2-8 personnes qui bossent sur un produit utilisé par des millions de personnes. Le gros des employé ça doit être des salesmen ou des gens du support ou écrivent la doc... J’étais un peu désolé de mon pétage de plombs lors de la JavaOne 2011 sur les 5 pauvres gars de l’équipe chargée l’équipe Java Deployment mais bon voila quoi c'est tout ce que méritait la qualité d'un produit comme Java Web Start...
Ça ne sera pas forcement mieux chez Gluon car ils ont annoncé que les releases gratuites seraient 2 fois par an. Seuls les clients payants ont droit a des releases plus souvent (la fréquence dépend de leur billing plan) ou alors il faut passer par la case build toi-même (Gluon reste OpenSource donc les sources de SceneBuilder et javafxport sont dispos).
quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.
suivez 
Répondre avec citation
.
Partager