Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Karl macht echt nen klasse Job mit dem Tool. Ich setze es hier im Job seit Anfang letzten Jahres ein und bin sehr zufrieden. Mittlerweile gibt es auch Plugins für diverse IDEs und sogar nen Konverter für JBuilder-Code. Für ein professionelles Tool ist es auch recht günstig.
Da wirst du nichts finden, was dir auf Knopfdruck das UI in Java umschreibt. Dazu sind die Sprachen, Konzepte und Umgebungen zu unterschiedlich.
Ist von der Anforderung her auch zu speziell, denke ich.
Früher hiess das Gupta.
Ist ne andere Programmiersprache. Unter den Datenbankspezialisten sollte SQLBase bekannt sein.
Das war früher (Win3.11) die erste SQL Datenbank.
Wie gesagt, ich suche einen wirklich guten (sehr guten GUI-Builder) der VE hat mich nämlich nicht überzeugt.
Es gibt auch Matisse4Eclipse, der ist aber genau so schlecht wie alle anderen GUI-Builder.
IMHO gibt es noch keinen stabilen, einfach zu benutzenden GUI-Builder für Java. Matisse ist zwar von der Bedienung her ganz nett, kommt aber nicht damit klar, wenn man selber im Code Änderungen vornimmt. Ausserdem macht mir Matisse4Eclipse zwischen druch immer mal ein paar Methoden kaput, die ich dann höndig wieder korrigieren muß *nerv*.
Die Aussage, dass alle GUI-Designer schlecht sind, teile ich nicht. Wie mit jedem Tool, gehört es auch dazu das Ding bedienen zu können. Wenn ich klar strukturiert arbeite, habe ich auch keine Probleme. Nutze ich beim JFormDesigner nicht automatisch generierten Code, sondern direkt die JFD-Dateien, kann ich auch gar nicht wirklich etwas kaputt machen, da das Programm die Ansicht nicht aus dem Quellcode, sondern der JFD-Datei erzeugt.
Am Ende muss man eben in Frage kommende Tools selbst ausführlich mit praxisnahen Szenarien evaluieren.
der IntelliJ 6.0 gui designer ist toll und übertrifft das netbeans zeug um längen.
ist aber a. noch nicht final b. kostet nen ganzes stück und c. eine ganze ide und kein plugin für eclipse.
Nutze ich beim JFormDesigner nicht automatisch generierten Code, sondern direkt die JFD-Dateien, kann ich auch gar nicht wirklich etwas kaputt machen, da das Programm die Ansicht nicht aus dem Quellcode, sondern der JFD-Datei erzeugt.
Irgendwann muß ich doch an den vom Gui-Designer generierten Code wieder ran, um z.b. einen eigenen TableCellRenderer zu implementieren o.a.. Denn alles kann einem der GUI-Builder nicht abnehmen.
Ich habe beide Matisse-Versionen und JForm-Designer evaluiert und bin für mich zu dem Schluss gekommen, daß die Dinger mehr Probleme erzeugen als lösen. Viel schneller ist man damit auch nicht, aber der Code der da raus kommt ist grottig. Dann doch lieber von Hand coden und in Eclipse ein paar Templates für die Codegenerierung benutzen.
Irgendwann muß ich doch an den vom Gui-Designer generierten Code wieder ran, um z.b. einen eigenen TableCellRenderer zu implementieren o.a.. Denn alles kann einem der GUI-Builder nicht abnehmen.
Was hat der Designer mit meinem Renderer am Hut?
Entweder passe ich die JTable durch Komposition im Code an, oder ich leite mir eine eigene Table ab und arbeite im Designer mit der.
Ich habe beide Matisse-Versionen und JForm-Designer evaluiert und bin für mich zu dem Schluss gekommen, daß die Dinger mehr Probleme erzeugen als lösen. Viel schneller ist man damit auch nicht, aber der Code der da raus kommt ist grottig. Dann doch lieber von Hand coden und in Eclipse ein paar Templates für die Codegenerierung benutzen.
Ich weiß nicht was du normalerweise für UIs strickst oder wie unglaublich gut du darin bist, das von Hand zu coden (und wie gut andere darin sind sich mit deinem Code ohne große Einarbeitungszeit zurechtzufinden und ebenso produktiv Änderungen vorzunehmen), aber mir nimmt der JFD reichlich Arbeit ab und spart mir damit Zeit. Erzeugten Quellcode gibts bei mir nicht, weil ich zur Laufzeit mit den JFD-Files arbeite. Was ich nicht benutze, kann ich also auch nicht verhunzen oder mich am Stil des erzeugten Codes stören.
Ich kann im Designer ein Design umändern, beinahe wie ich lustig bin, speichere es unter anderem Namen, ändere eine Zeile in meinem Code und kanns direkt testen. Ich kannn problemlos sehr schnell UIs aufbauen und einbauen und damit eine Anwendung demonstrieren und die Funktionlität später Stück für Stück einbauen. In der Zeit haben alle aber schonmal was vor sich, haben eine visuelle Vorstellung der Anwendung und können frühzeitig Feedback geben. Änderungen im Layout sind flott gemacht. Wie du das in gleicher Geschwindigkeit und ohne viel Trial&Erro von Hand hinbekommen willst, musst du mir mal zeigen...
Und ich rede hier nicht von nem Dialogen mit einem Label, einem Eingabefeld und zwei Buttons
ich nutze auch Netbeans und finde an dem Code nichts "grottiges". Gerade wegen Matisse habe ich micht für Netbeans entschieden. Die GUIs sind ruck-zuck erstellt bzw. auch geändert und ich kann mich auf das wesentliche konzentrieren. Insofern full ack @ AlArenal, auch wenn er eine andere Software nutzt.
Ich fummle privat ab und an mit Netbeans und sehe einfach auch, dass man sich eine Weile damit beschäftigen muss. Matisse ist schon ziemlich gut, aber das findet man nicht mal eben so in 2 Minuten raus. Jedes Tool hat so seine Eigenarten und diese zu nutzen (anstatt sich dagegen zu wehren) braucht halt etwas Zeit.
Wenn man z.B: vom JBuilder kommt, muss man sich sowohl mal eingehend mit dem JFD, als auch mit Matisse beschäftigen, um die jeweiligen Stärken und vermeintlichen Schwächen in der Praxis rauszuarbeiten. Daher sprach ich ja davon, dass man entsprechend praxisnah evaluieren muss und sich dafür auch Zeit nehmen muss. Viele ziemlich gute Detaillösungen übersieht man sonst (Integration von JFD-Files, Multilingualität beim JFD, Layout beim Matisse, ...)
Also mußt du doch wieder an den Code ran, oder wie machst du das?
Wenn man z.B: vom JBuilder kommt, muss man sich sowohl mal eingehend mit dem JFD, als auch mit Matisse beschäftigen, um die jeweiligen Stärken und vermeintlichen Schwächen in der Praxis rauszuarbeiten. Daher sprach ich ja davon, dass man entsprechend praxisnah evaluieren muss und sich dafür auch Zeit nehmen muss. Viele ziemlich gute Detaillösungen übersieht man sonst (Integration von JFD-Files, Multilingualität beim JFD, Layout beim Matisse, ...)
Die Internationalisierungsfunktion im JFormDesigner ist sehr geil. Mir gefällt auch die Unterstützung der vielen Layoutmanager, aber es gibt auch einiges was mir noch nicht gefällt.
Ich suche eben nach einem GUI-Designer mit dem ich teilweise visuell entwickeln, aber auch Änderungen am generierten Code machen kann. Denn oft ist es einfacher händisch eine Änderung vorzunehmen als sich über die hakelige Bedienung zu ärgern.
Wie funktioniert das mit den JFD-Files? Wie kann man die einbinden und was bringt mir das?
Natürlich über Code. Aber ich layoute nicht über Code. Ich setze über Code auch keine Buttons, Icons oder sonstwas in meine Komponenten. Auch einige selbst entwickelte Komponenten die ich in mehreren Anwendungen einsetze und z.B: aus einem SimpleInternalFrame (JGoodies UIF Lite) mit einigen Buttons mit Icons, usw. bestehen, stricke ich mir im JFD zusammen, schreibe den GLue-Code (siehe unten) und benutze sie anschließend als eigenständoge Komponenten im JFD.
Die Internationalisierungsfunktion im JFormDesigner ist sehr geil. Mir gefällt auch die Unterstützung der vielen Layoutmanager, aber es gibt auch einiges was mir noch nicht gefällt.
Ich suche eben nach einem GUI-Designer mit dem ich teilweise visuell entwickeln, aber auch Änderungen am generierten Code machen kann. Denn oft ist es einfacher händisch eine Änderung vorzunehmen als sich über die hakelige Bedienung zu ärgern.
Wie funktioniert das mit den JFD-Files? Wie kann man die einbinden und was bringt mir das?
Beispiel für eine einfache JFD-Form (ein Panel) namens test.jfd, welches ein TextArea in einer JScrollPane und einen Button zum Beenden enthält:
Code:
/**
* Initialisiert das UI.
*
*/
private void initUI() {
/*
* Schritt 1: Aus der JFD-Datei die Komponente erzeugen lassen
*/
FormModel formModel = null;
FormCreator formCreator = null;
JPanel panel = null;
try {
formModel = FormLoader.load("test.jfd");
formCreator = new FormCreator(formModel);
panel = formCreator.createPanel();
} catch (Exception e) {
/*
* Exception wird u.a. geworfen, wenn die angegeben Datei nicht
* gefunden wurde.
*/
e.printStackTrace();
return;
}
// erzeugtes Panel auf die ContentPane dieses Frames legen
getContentPane().add(panel);
/*
* Schritt 2: Einzelne Elemente aus unserer Form referenzieren
*
* Im JFD werden allen Elementen Namen vergeben (Feld "Name" in den
* Eigenschaften). Über diesen Namen, kann man nun das Element
* referenzieren. Für einige Standard-Elemente aus Java gibt es
* Convenience-Methoden wie z.b. #getButton, die direkt einen
* JButton liefert. Alternativ kann man aber jedes mögliche Element
* über #getComponent referenzieren und muss es dann eben manuell
* casten.
*/
myButton = formCreator.getButton("myButton");
// ist dasgleiche wie:
// myButton = (JButton) formCreator.getComponent("myButton");
myButton.addActionListener(new ActionListener() {
/**
* @see java.awt.event.ActionListener#actionPerformed(java.awt.event.ActionEvent)
*/
public void actionPerformed(ActionEvent e) {
System.exit(0);
}
});
myTextArea = formCreator.getTextArea("myTextArea");
// ist dasgleiche wie:
// myTextArea = (JTextArea) formCreator.getComponent("myTextArea");
myTextArea.append("Dies ist ein programmatisch hinzugefügter String.");
}
Vorteile:
1. Ich kann mein Design nicht unwiderbringlich zermanschen.
Ich bin ein gebranntes JBuilder-Kind. Der Nachteil des JBuilder und von Matisse ist, dass die Designer das Layout wieder aus dem Code auslesen. Änderungen im Code führen dann, wenn man nicht aufpasst, u.U. dazu, dass der Designer den Code nicht mehr versteht und man mit ihm das Layout nicht mehr bearbeiten kann. Der JFD umgeht das, indem er das Layout in eigenen XML-Dateien, den .jfd-Dateien, ablegt. Es ist mir überlassen, ob ich den JFD zusätzlich (!) automatisch Java-Code generieren lasse, oder nicht.
2. Mein Code wird schlanker, wenn ich zur Laufzeit die JFD-Files nutze.
Ich referenziere nur, was ich auch wirklich brauche. Ich habe in meinem SourceCode nicht noch die ganzen Panels, Icons, Borders und Layout-Manager rumschwirren.
3. Ich kann Layouts schnell wechseln, wenn ich zur Laufzeit die JFD-Files nutze.
Ob zur internen Evaluierung von diversen Design-Ansätzen, oder als Customizing für Kunden: Da ich nur auf die von mir im Code benötigten Instanzen aus dem Layout zugreife und diese per Namen eindeutig angelegt wurden, kann ich diverse unterschiedliche Layouts vorhalten und mit FormLoader.load("meinLayout.jfd") entscheiden, welches Layout ich verwende. Lediglich die zu referenzierenden Instanzen müssen in diesen vom gleichen Typ und gleichen Namens sein.
Gerade in der Weiterentwicklung von Anwendungen kommt mir zugute, dass der JFD Designer zwischen Klassen "morphen" kann. In der aktuellen Version ist etwas vom Typ X, in der neuen soll es aber von Y sein - dazu muss ich nichts rausnehmen und neu reinsetzen, denn ich kann es "morphen" lassen.
Usw. usf.
Muss mal mit Karl sprechen, ob ich für solche flammenden Reden eigentlich Sonderkonditionen bekomme..
Der Nachteil des JBuilder und von Matisse ist, dass die Designer das Layout wieder aus dem Code auslesen. Änderungen im Code führen dann, wenn man nicht aufpasst, u.U. dazu, dass der Designer den Code nicht mehr versteht und man mit ihm das Layout nicht mehr bearbeiten kann.
@ALArenal Danke für die kleine Einführung in JFD-Files. Ich wusste nicht, daß man auch von aussen an die Komponenten wieder ran kommt. Das sieht sehr interessant aus.