Framework zum Spielen?

Gleich vorweg: Nein, das Play Framework dient nicht der Spieleprogrammierung. Es geht um ganz normale Webanwendungen, und zwar in Java. Damit bekommt die immer länger werdende Kette von Webframeworks eine weitere Perle angehängt, und nach erster Betrachtung scheint es sich um ein sehr interessantes und sehenswertes Exemplar zu handeln! Jedenfalls, wenn man Wert auf eine flache Lernkurve, gute Toolunterstützung und Effizienz legt. Java sollte man schon beherrschen, aber viel mehr braucht man eigentlich nicht.

Wenn ich ein neues Framework anschaue, frage ich mich zuerst, ob ich damit schneller zum Ergebnis komme als mit Grails. Der nächste wichtige Punkt ist, wie schnell sich Änderungen am Datenmodell und in der Benutzeroberfläche vornehmen lassen (Erweiterung, Refactoring, Deployment). Und nicht zuletzt geht es auch darum, wie klar und übersichtlich man den Quellcode strukturieren kann. Was erzwingt das Framework, was kann man nach eigenen Vorstellungen organisieren?

Zum ersten Punkt: Ist Grails zu schlagen? Klare Antwort: Kommt drauf an...

Im Play Framework verwendet man eigentlich nur Java (demnächst auch Scala) mit ein paar eingebauten Features, die deutlichen Komfort bieten. Das offizielle Tutorial zeigt das sehr schön. Domainklassen benötigen wie in Grails keine Getter und Setter. Constraints definiert man über Annotationen direkt an der Felddeklaration. Das finde ich übersichtlicher als den separaten Constraints-Block in Grails.

Weitere Auffälligkeiten:
Das Framework ist gleichzeitig auch Anwendungsserver und Testumgebung. So kann man seine Anwendung im Hintergrund starten und dann im laufenden Betrieb die komplette Programmierung ändern. Alles ist sofort im Browser nachvollziehbar. Grails kann das eigentlich nur bei Änderungen im View-Layer, bei Änderung einer Grails-Domainklasse ist i.d.R. ein Neustart fällig.
Scaffolding funktioniert ähnlich einfach wie in Grails, allerdings ist eine automatische Codeerzeugung der View, wenn man diese im Detail ändern will, noch umständlich.
Warum das Tutorial der Route-Anpassung so viel Aufmerksamkeit widmet, kann ich nicht ganz nachvollziehen. Es geht prinzipiell auch ohne.

Das Play Framework liefert gleich drei nette Befehle für die IDE-Integration mit, so dass eigentlich kein zusätzliches Plugin mehr nötig ist: "eclipsify", "netbeansify" und "idealize". Die Benennung ist einfach sympathisch und erstellt zuverlässig ein passendes IDE-Projekt.
Bei nachträglicher Aktivierung von Modulen (CRUD, Security usw.) muss man diese Befehle übrigens wiederholen, damit die IDE zusätzliche Bibliotheken auflösen kann.

Natürlich kann Play noch nicht mit der Plugin-Vielfalt von Grails mithalten. Es macht entsprechend mehr Arbeit, wenn man Features von UI-Plugins wie GrailsUI oder RichUI erzielen möchte.

Zum zweiten Punkt: Wie schnell kann man Änderungen am Datenmodell und in der Benutzeroberfläche vornehmen?
Solange man im Scaffolding-Modus bleibt, geht das mit Play schneller als in jedem anderen Framework, das ich mir bisher angeschaut habe - nämlich augenblicklich. Wenn es bereits einen CRUD-Controller zu einer Domainklasse gibt, genügt die Deklaration eines weiteren Felds, und schon passt das Framework die Datenbank an und fügt das Feld in die Benutzeroberfläche ein. Alles im laufenden Betrieb, solange man den Development-Modus benutzt. Im Production-Modus wäre ein Neustart des Frameworks nötig, aber der dauert auch nur Sekunden. Weil das ganze ohne zusätzlichen Anwendungsserver (Tomcat, Glassfish o.ä.) läuft, entfällt auch das Hin- und Hergeschiebe von WAR-Dateien.

Zum dritten Punkt: Übersichtlichkeit. Ein Play-Projekt enthält, wenn es in Netbeans geöffnet wird, genau fünf Verzeichnisse: "app", "views", "public", "conf" und "test". Damit ist die Frage, was wohin gehört, deutlich schneller beantwortet als in Grails, das ein neues Projekt standardmäßig mit 15 Verzeichnissen anzeigt. Für Einsteiger ist in Grails nicht ersichtlich, was man in "Scripts", "Utility Classes" oder "Groovy Source Packages" ablegen sollte.

Erstes Fazit: Auf dem Radar behalten! Es gibt zwar noch holperige Details, aber im Grundsatz kann man mit dem Play Framework viel in kurzer Zeit anstellen.

Noch kein Feedback