Wirkt auf mich nicht gerade seriös. Glaube der Kerl hofft einfach nur, dass sein Codename one Produkt als Alternative zu swing angenommen werden könnte (letztendlich erlaubt es Desktop-builds). Das JavaFX Swing noch nicht vertrieben hat ist doch jetzt nicht mal im Ansatz überraschend. Wir setzen hier in der Firma beides ein und die Swing Anwendung wird noch auf unbestimmte Zeit am Leben erhalten. Warum sollte man die auch neu schreiben nur weils ein neues GUI-Framework gibt?
Ich beginne mich gerade in FX einzuarbeiten.
Ich hatte mich eigentlich drauf gefreut, weil mich einige “Features” wirklich ansprachen: Strickte Trennung von Design und Code beispielsweise.
Leider Laufe ich dabei gegen einige Wände, denn wenn man dialoge tatsächlich via FXML configuriert, wie bekommt man dann sein Model in den Dialog? Richtig: per static Setter in der Controller Klasse.
Unittesting der Kommunikation Controller<->ViewModel? Schwierig, weil die FX-Controls keine Interfaces haben und alle ihre *property-Getter final sind-> das Aus für Mocking-Frameworks (nein, PowerMock ist keine Alternative…)
Außerdem muss man Application.launch() aufrufen, bevor einige Methoden in den FX-Objekten aufrufbar sind (beispielsweise setParent())
Also ich bin erst mal schwer enttäuscht.
bye
TT
Die Seriosität zu beurteilen ist schwierig. Es gibt einen Haufen Dampfplauderer da draußen, und im Zweifelsfall muss man zumindest die Möglichkeit in Betracht ziehen, dass irgendjemand einfach nur seine subjektiven Gedanken in die Welt kackt. So viel als Einleitung zu dem, was ich jetzt schreiben werde 
Ich werde sicher keine Prognosen über den Erfolg oder Mißerfolg von JavaFX machen - und noch viel weniger über die managerialen Gründe für das (mögliche) eine oder andere spekulieren. Aber vielleicht ein paar technische Spekulationen: Rein technisch denke ich, dass JavaFX an einigen Punkten krankt. Dass es am Anfang so eine scheinbar von Java lösgelöste Scripting-Lösung war könnte ein Grund für die geringe Akzeptanz sein. Noch immer hört man (von „Entscheidern“!) solche Sachen wie „JavaFX? Das ist doch dieser Flash-Konkurrent von Sun!?“.
Dass JavaFX „kurz vor der Mobile-Revolution“ rauskam, und nicht konsequenter, breiter und systematischer Mobile Geräte unterstützt, ist bedauerlich - und auch, dass so wenig für eine breitere Unterstützung (OpenJDK, Android…) getan wird, owbohl der Aufwand dafür vergleichsweise gering sein sollte.
Ansonsten wird in dem Artikel ja auch nach den Alternativen gefragt. Sehr (zu) verknappt zusammengefasst, rein in bezug auf die Java-Welt (und nicht die „potentielle Zielwelt“ von JavaFX, im oben angedeuteten Sinn) :
- AWT: Das ist veraltet und viel zu unflexibel - praktisch unbrauchbar für die meisten Fälle
- SWT: Da lehne ich mich mal weit aus dem Fenster und sage: Lächerlich. Die Layouts sind ein Krampf, sowas wie Images praktisch nicht unterstützt, händisches Resourcen-Management ist sooo 1980, und wenn man ein GUI, das aus mehr als Buttons besteht, damit händisch Programmieren wollte, würde man schlicht scheitern (oder so: Ohne JFace geht da gar nichts, und damit ist SWT schlicht nicht mehr flexibel und „leichtgewichtig“ genug).
- Swing: Stimmig, flexibel, recht effizient - in vieler Hinsicht einfach „gut“. Natürlich mit ein paar Alt- und Neulasten und Glitches, aber hervorragend dokumentiert, integriert und etabliert. (Nebenbei gibt es SO viel Swing-Code, dass es nicht von Heute auf Morgen aussterben wird)
- JavaFX: Ein guter Versuch. Ein paar Altlasten rausgeworfen. Sowas wie die Graphs und Effekte, und allein schon die Tatsache, dass das ganze als Flexibles Szenegraphsystem angelegt ist, sind für manche Anwendungsfälle hundertprozentige PRO-Punkte. Insbesondere denke ich, dass viele Konzepte, die in JavaFX umgesetzt sind, sehr schön Hand in Hand gehen (könn(t)en) mit den Sprachlichen Neuerungen von Java 8. Leider kommen eben ein paar Hemmschuhe dazu: Nicht perfekt ins JDK integriert. Selbst die Samples kommen kaum ohne „unchecked casts“ aus (an manchen Stellen wirkt es etwas „overengineered“, aber das muss man genauer ausdifferenzieren). Das Styling mit CSS ist schon… gewöhnungsbedüftig. Insgesamt aber nichts, was von vorschnell totsagen sollte.
21x der englische Autor Almog im deutschen Artikel erwähnt, ganz schön nervig
nach der Grafik im englischen Artikel hat JavaFX just Swing überholt, läuft doch gar nicht schlecht,
beides wie generell Desktop-Frameworks ist vielleicht absteigend gegenüber Android & Co.,
aber wird doch sicher seinen Platz behalten, wie im verlinkten Artikel
genannt, interne komplexte Unternehmensanwendungen (wie bei mir 
) usw.
Swing wird nach und nach aufgesaugt, vielleicht nicht direkt bei Java-Anfängern, die das in der API und den Lehrbüchern noch als erstes finden, auch nicht ganz falsch,
aber zumindest im professionellen Umfeld,
Problem gäbe es für Framework X erst wenn wirklich funkelndes Framework Y als Alternative sichtbar ist, und wenn dann Wechsel auch nicht ganz schade,
habe es noch nicht ausprobiert, aber so einen Ansatz finde ich immer bedenklich,
was ist wenn man dynamisch bestimmte Elemente dazu haben oder ausblenden möchte,
andere Reihenfolge, andere Designs, Sprache, User-Konfiguration,
dynamischer Zusammenbau von Dialogen Auswahl von X aus 100 möglichen abfragbaren Feldern
man hat eine Programmiersprache, sowas richtig tolles,
warum diese einzigartige Programmiermacht abgeben für irgendwelche statischen XML-Vorgaben?
na vielleicht kombinierbar, bisschen vorgeben und immer noch dynamisch
Oder per DI-Framework. Man kann vom FXMLLoader die ControllerFactory setzen und dort gibt man einfach ein von z.B. Guice oder Weld erzeugtes Objekt zurück.
Properties würde ich nicht mocken. Und meinst du wirklich Controller ↔ ViewModel oder View ↔ ViewModel. Meine zwar mal was über ein Konzept von Controller in MVVM gelesen zu haben, aber erinner mich nicht mehr richtig. Wir setzen hier auf reines MVVM und View und ViewModel sind nur über Bindings miteinander verbunden. Von den Properties gehen wir aus, dass die funktionieren und dann ist das ViewModel sehr einfach testbar.
Ich bin mir nicht sicher ob ich das Problem Zwecks FXML und Controller verstanden hab, aber du kannst ja den FXMLoader instanzieren, die fxml laden und dann per “getController” die Controller instanz kriegen und darauf normale getter ausführen.
[quote=Clayn]du kannst ja den FXMLoader instanzieren, die fxml laden und dann per “getController” die Controller instanz kriegen und darauf normale getter ausführen.[/quote]Dann wurde aber die initialize-Methode des Controller schon aufgerufen. Da würde ich aber die Daten aus dem Model benötigen, um beispielsweise eine Tabelle zu füllen…
[quote=Tomate_Salat;126285]Man kann vom FXMLLoader die ControllerFactory setzen[/quote]Dafür habe ich kein Beispiel gefunden, nur vage Andeutungen wie Deine… ;o)
[quote=Tomate_Salat;126285]Wir setzen hier auf reines MVVM und View und ViewModel sind nur über Bindings miteinander verbunden. Von den Properties gehen wir aus, dass die funktionieren und dann ist das ViewModel sehr einfach testbar.[/quote]Mein Beispiel:class Controller{ @FXML TextField input1; @FXML TextField input2; @FXML Button button; @Inject MyViewModel myViewModel; @Override public void initialize(URL url, ResourceBundle resourceBundle) { button.disableProperty().bind(myViewModel.buttonActivatorProperty()) }Wie beweise ich jetzt per Unittest, dass das disable-Property des Buttons mit dem richtigen Property aus dem ViewModel gebunden wurde?
Dank fehlendem Interface für Button und der finalen disableProperty()-Methode habe ich keine Chanche…
[SPOILER]Womöglich sehe ich das zu akademisch, aber ich will nun mal keinen Produktivcode schreiben, der nicht durch einen Unittest gefordert wird.[/SPOILER]
bye
TT
Gerade mal ein Snippet rauskopiert.
loader.setController(new MainWindowController(myData));
try {
loader.load();
} catch (IOException ex) {
Exceptions.printStackTrace(ex);
}```
[ol]
[li]Loader erstellen,
[/li][li]Controller erstellen und setzen,
[/li][li]View Laden. [x]
[/li][/ol]
x) Erst jetzt beginnt der Lifecycle mit @FXML injektionen und initialize-Methode.
Es wird in vielen Fällen davon abgeraten sich nur auf den Controller in der FXML zu verlassen.
Es ist aber gut dort einen DefaultController für Tests oder sonstiges zu hinterlegen. So braucht man zum Sysout-Debuggen nur die eine View initialisieren und bekommt schonmal Basis-Funktionalität.
*** Edit ***
```new JFXPanel(); //Damit JavaFX aufwacht.
MyViewModel myViewModel = new MyVeiwModel();
Controller controller = new Controller()
FXMLLoader loader = new FXMLLoader(getClass().getResource("view.fxml"));
loader.setController(controller);
try {
loader.load();
} catch (IOException ex) {
Exceptions.printStackTrace(ex);
}
myViewModel.buttonActivatorProperty().setValue(true);
assert button.isDisable() == true;
myViewModel.buttonActivatorProperty().setValue(false);
assert button.isDisable() == false;```
Controller-Properties sind package private, also Test im entsprechenden Verzeichnis und gut?Das JavaFX Swing nicht mal so heute auf morgen überholt war eigentlich abzusehen wenn 99% aller Tutorials im Internet immernoch auf Swing basieren.
Kennt man doch von OpenGL wenn sich ein Neuling dazu gesellt und mit Code wie
GL10.glBegin();
ankommt.
Muss einigen Punkten stark zustimmen die von euch genannt worden:
- Keine offizielle(!) Unterstützung auf Mobile Devices (Obwohl es geplant war, aber ich glaube Oracle und Google sind mit etwas anderem beschäftigt)
- Kein herkömmliches Java wie für alles andere. Sehr schwierig für Anfänger, ist doch das Verständnis der main() Methode schon eines der größten Probleme
- Keine richtige Unterstützung im JDK und in den IDEs. Noch immer muss man sich Zusatzpackages herunterladen und installieren, Swing geht out of the box.
Trotzdem ist JavaFX Swing bei weitem überlegen, wenn auch noch im Anfangsstadium. Es fehlen eine vielzahl von Swingüblichen Bibliotheken, wobei FX bereits breit aufgestellt ist.
Wenn die JavaFX in den Sand setzen weiß ich auch nicht mehr weiter. Dann hat Oracle komplett einem am Deckel und für mich wirds in Zukunft nurnoch C# und Dalvik sofern ich die Wahl habe.
Windows GUI form control ist halt auch einfach WYSIWYG bereits seit Jahren.
Um das View zu testen würde ich keine Unittests verwenden sondern Integrationstests.
Ist sehr einfach:
loader.setControllerFactory(new Callback<Class<?>, Object>() {
@Override
public Object call(Class<?> param) {
return guice.getInstance(param);
}
});
Damit werden deine Controller (ViewModels) in diesem Fall von Guice erstellt. Danach werden die ganzen FXML-Sachen abgearbeitet.
Mit IntelliJ IDEA absolut kein Problem
[quote=ionutbaiu]Gerade mal ein Snippet rauskopiert.
Java Code:
FXMLLoader loader = new FXMLLoader(getClass().getResource("mainwindowview.fxml"));
loader.setController(new MainWindowController(myData));
try {
loader.load();
} catch (IOException ex) {
Exceptions.printStackTrace(ex);
}
Loader erstellen,
Controller erstellen und setzen,
View Laden. [x][/quote]Funktioniert!
[quote=ionutbaiu;126302]Es ist aber gut dort einen DefaultController für Tests oder sonstiges zu hinterlegen.[/quote]Das geht nicht, dann beschwert sich FX,das es schon eine Controllerdefinition gäbe…
bye
TT