Yup, ich hab mittlerweile auch mitbekommen, dass das ein anderer schon vor mir getan hat. Ok, es geht nicht um das Rad, es geht um ein Framework, wie ich es vor einiger Zeit skizziert habe. Ein solches Framework habe ich in den vergangenen Monaten mit einem Kunden meines Arbeitgebers implementiert. Die prinzipielle Idee ist es Domain Driven Design zu betreiben, in dem (praktisch) nur das Domain Model implementiert wird und die GUI daraus automatisch generiert wird. Ich bin auf diesen Ansatz gestoßen, da wir in dem fragliche Projekt zunächst keine konkreten Anforderungen hatten, und dadurch die Zeit nutzten um uns unser Leben so einfach wie möglich zu machen. Was wir wussten war, dass wir Stammdaten zu pflegen hatten. Also begannen wir Generische Dialoge zu konstruieren, die eine Klasse analysieren und daraus ableiten, wie sie dargestellt und editiert werden können. Zunächst sollten die Dialoge nur für 'einfache' Objekte genutzt werden, aber bei den meisten Anforderungen, die sich zunächst nicht aus dem Framework befriedigen ließen kamen wir zu dem Schluss, dass sich relativ einfach generische Prinzipen ableiten lassen. Zusätzlich lassen sich unsere Dialoge durch Annotations am Domain Model beeinflussen. Zum Beispiel wird darüber gesteuert, in welcher Reihenfolge und in welchen Gruppen Steuerelemente angezeigt werden. Insbesondere werten wir auch die Annotations von JPA (aka Hibernate Annotations) und Hibernate Validator aus, so dass unser GUI automatisch die selben Prüfungen durchführt, wie sie als Constraints in der Datenbank hinterlegt sind (die ebenfalls zu 95% aus den Annotations generiert wird).

Man könnte meinen, dass eine solche GUI krude aussieht. Und das tat sie zunächst auch, aber mittlerweile sind unsere generischen Dialoge soweit gediehen, dass die tatsächlichen Benutzer sie ausdrücklich loben. Ich behaupte, dass ich mit diesem Framework ein Domain Model aus 10 Klassen in weniger als einem Tag runterschreiben kann, inklusive Datenbank, Gui, Tests und Deployment. Die Frage wie das Domain Model auszusehen muss natürlich immer noch beantwortet werden, aber so haben wir endlich die Zeit, um uns genau diese Dinge gründlich Gedanken zu machen, da wir uns nicht mehr mit dem mühseligen auswählen und anordnen von GUI Komponenten beschäftigen müssen, und auch die Datenbank in der Struktur einfach nebenbei entsteht und sich die Datenbankspezialisten darum kümmern können wie sie die Datenbank schnell bekommen, und nicht darum, welcher Datentyp verwendet wird.

So viel zu meinem Rad. In den letzten Wochen habe ich viel hin und her überlegt, wie ich diese Erfahrungen nutzen kann, denn das Framework gehört natürlich unserem Kunden (und natürlich gibt es schon wieder viele Dinge, die ich jetzt anders oder besser machen würde). Und bei diesen Ãœberlegungen bin ich auf einen früheren Erfinder des Rades gestoßen, und sein Rad: Naked Objects. Während wir in dem oben skizzierten Projekt über das Konzept der GUI Generierung eher zufällig gestolpert sind, hat sich Richard Pawson, wie er es in seiner PhD Thesis beschreibt, gezielt der Fragestellung genähert. Seine Idee ist die folgende: So genannte 'Feature Complete Objects' beschreiben sowohl ihre Daten, als auch ihr mögliches Verhalten und die möglichen Interaktionen. Also im Prinzip alles, was ein Benutzer egal ob Entwickler oder Endanwender mit diesem Objekt machen kann. Da der Endanwender meist keine Programmiersprache beherrscht, muss ein Wrapper erzeugt werden, der es dem Benutzer erlaubt die Objekte zu manipulieren. Dies ist nichts anderes als eine generische GUI, so wie ich sie oben skizziert habe. Das Framework Naked Objects, das von Robert Matthews gestartet wurde, kann sowohl eine Swing GUI, als auch einen Webclient erzeugen.

Also wieder einmal das Rad zu spät erfunden. Wikipedia führt sogar noch weitere Raderfinder, oder zumindest Radbauer auf. Aber auch wenn ich wohl nicht als Erfinder in die Analen der Softwareentwicklung eingehen werde, halte ich das Konzept für einen hoch interessanten Ansatz, bei dem es aber sicher noch eine Menge zu tun gibt. Ich bin zum Beispiel weder von der generierten GUI von Naked Objects 100% überzeugt, noch von dem Ansatz wirklich 100% zu generieren. Mindestens für eine Ãœbergangszeit halte ich es für absolut wichtig immer noch die Möglichkeit zu haben einfache einen Dialog zu öffnen und den eigenen GUI-Code dort zu verewigen.

Ich werde das Projekt und das Blog von Richard Pawson jedenfalls weiter beobachten, in dem er unter anderem über neue Ideen für das Framework schreibt.