Motivation

Ich habe bisher vor allem das JQuery- Javascript Framework benutzt und bin mit Grails zum ersten Mal mit YUI (2)in Berührung gekommen.
Und ich denke es ist eine mehr als unglückliche Wahl.

Syntax#1

Fangen wir mit Groovy an. Nehmen wir mal und das wirklich nur angenommen, der Browser könnte Groovy wie Javascript ausführen.
Wir würde man dann alle “divs” mit der Klasse “selected” eines Dokuments suchen?

def divs = document.findAllByTypeAndClass("div","selected")

Wäre da so meine erste Idee. Ähnlich den Dynamic Finders. Aber das wäre mir nicht “Groovy” genug.
Laut IBM sähe die Lösung etwa so aus:

def divs = document.div.[@class="selected"]

Quasi wie E4X. Bleiben wir einfach mal bei dieser Lösung. Sie ist Groovy genug.

Gehen wir weiter zu YUI

var elements = YAHOO.util.Dom.getElementsByClassName('test', 'div');
oder
var elements = YAHOO.util.Selector.query('div.test');

Und dann zu JQuery

var elements = $("div.selected");

Welches Framework ist nun Grooviger?

Syntax#2

Okay vielleicht ist das Beispiel noch zu einfach. Gehen wir mal weiter und markieren die eben gewählten divs mit einem rotem Hintergrund.

Zunächst wieder Groovy

document.div.[@class="selected"].each(){ it.backgroundcolor="red"}

Schöne und Groovy Lösung! Gehen wir nun über zu YUI

Dom.batch(YAHOO.util.Selector.query('div.test'), function (element) {Dom.setAttribute(element, "background-color","red");});

und dann zu JQuery

$("div.selected").each(function(){$(this).attr("background-color","red");});
//oder sogar
$("div.selected").attr("background-color","red");

Spätestens hier sollte klar werden auf was ich hinaus will. Die JQuery- Syntax passt einfach viel besser zu Groovy und Grails.

Vorwort

Ich habe mich die letzte Zeit sehr intensiv mit dem Framework Grails[1] beschäftigt. Und ich muss zugeben ich bin beeindruckt. Dieser Artikel soll eininge der Vor- und auch natürlich auch die Nachteile des “Railsway” nach meiner Sichtweise dokumentieren. Viele der Kommentare lassen sich auf Ruby on Rails, CakePHP, Symfony und andere Frameworks anwenden.

Buzzword-Bingo

Für jeden der das Spiel kennt:

Rapid Application Development(RAD), Model Driven Development(MDD), Best Practises, Spring, The Yahoo! User Interface Library (YUI), Hibernate, Don’t repeat yourself (DRY),Agile Development, Database Migaration, Code Generation, SLF4J, DOM4J, Groovy, Metaclass, Sitemesh, Model View Controller (MVC), Apache Ant, JUnit, Jakarta Commons, HSQLDB, OSCache, Apache ORO,Apache Ivy, Rapid Prototyping,Keep it simple and straightforward (KISS), Single Point of Truth(SPOT),Convention over configuration(COC), Domain Specific Languages (DSL), Scaffolding, Dynamic Finders, Create -Retríeve- Update- Delete(CRUD)

So spätestens jetzt sollte einer Bingo schreien.

Intro Railsway

Um was gehts beim Railsway? Um eins : Geschwindigkeit!
Alles fing an mit einem Video[2].
Ein Webblog in 16 Minuten.
REVOLUTION!
Was schaffen normale Softwarefirmen in 16 Minuten?

• ein Angebot schreiben? vielleicht
• ein Pflichtenheft schreiben? nö
• eine einzige Zeile Code? ganz sicher nicht!

Was ist der Railsway?

Zum einen geht es darum, dem Entwickler möglichst viele Entscheidungen abzunehmen.  Man benutzt einfach diese Sachen, die Standard sind.
Hat jemand von euch schon mal so ein Meeting erlebt?

Persistenz-Schicht(DAO)

• JDO
• JPA
• Hibernate
• Selbstgeschriebenes SQL (dann noch die Diskussion um Prepared Statements )
• Dynamisches Selbstgeschriebenes SQL (dann noch die Diskussion um Prepared Statements )
• SQL-Injection Handling

Views

• Java Server Pages(JSP)
• Java Server Pages (JSP)+ Java Standard Template Library (JSTL)
• Java Server Faces (JSF) und dann die Distribution (MyFaves/IceFaces etc .. )
• XSS Handling

Code

• Java 1.4.2
• Java 1.5
• Java 1.6
• Alles Andere

Abhängigkeiten

• Spring
• Maven
• Ivy
• Guice
• Eigenproduktion

Sonstige Entscheidungen

• put the most annoying part of each meeting here

Beim Railsway gibt es solche Meetings nicht mehr. Per Default ist es Hibernate+ Java Server Pages (JSP)+ Java Standard Template Library (JSTL) + Ivy + Java (1.5+) oder Groovy
Okay starten wir … Eclipse ? Natürlich!

Vorher : Create new Dynamic Web Project  …  bla bla bla  … MyProject    … bla bla bla … Jars kopieren …  Buildpath … pom.xml…. oh 16 minuten schon überschritten?
Railsway : grails create.app MyProject … Import existing Project

Model – View – Controller

Dieses Prinzip ist sicher jedem Entwickler bekannt. Bei Grails wird es strikt gefordert und bedankt sich dafür mit viel generiertem Code, der Überstunden erspart.

(M)Modelle

In den meissten Applikation entspricht eine Klasse einer Zeile irgendeiner Tabelle der Datenbank.
Warum also nicht die Tabelle so benennen wie die Klasse?
Diese Frage stellt sich der Railsway einfach nicht, sondern macht es.
Bei Grails entspricht auch jede Klasse einem Problem, einer eigenen Domäne.
Als Beispiel soll fogendes dienen:

class JsecUser {
String username
String passwordHash
String email
static constraints = {
username(nullable: false, blank: false)
email (email:true)
}
def setPassword(word){
passwordHash = new Sha1Hash(word).toHex()
}
}

(M2) Dynamische Mehoden

Mit Grails ist folgendes möglich :

JsecUser user = new JsecUser()
user.setUsername("admin")
user.setPassword("gayheim")
user.password = 'gayheim99'
user.save()

Die Setter in Zeile 2 und 3 haben wir nie geschrieben, sie wurden für uns generiert. Jeder der Eclipse benutzt weiss, dass man Getter und Setter auch in Eclipse generieren kann. Allerdings die die entstehende Klasse inklusive Outline-Ansicht nicht wirklich unterscheidbar nach “wo passiert das Standard-Zeug” und “wo passiert wirklich etwas”, hier hilft Grails die Übersicht zu behalten.

In Zeile 4 sieht es für Java-Entwickler so aus, als würde man direkt auf eine Eigenschaft zugreifen, doch weit gefehlt! Solche Zuweisungen gehen immer über Getter und Setter.

Die grösste Überraschung sollte aber die Zeile 5 darstellen. Alles was dazu benötigt wird, folgt nun.

(C)Persistenz in 0.5 Sekunden

Egal für welches Framework man sich entschieden hat, man konfiguriert das ganze erstmal. Ganz schlecht sind hier die selbstgeschriebenen Lösungen.
Bei Grails kann man mit

def scaffold=true

die normale CRUD-Funktionalität erreichen. Und viel mehr … ein Zauberwort ist hier Dynamic Finders

def user = JsecUser.findByUsername("admin")

ist ein gültiger Ausdruck, obwohl wir die Methode nie geschrieben haben. Alles was benötigt wird, ist eine Klasse, welche wie die Domainklasse + das Suffix Controller heisst und im Ordner “controller” abgelegt wird. Nebenbei hat man durch den Einsatz von Hibernate einen L2-Cache und SQL-Injection-Schutz OnBoard. Standard…….

(V) wunderliche Views

In Grails gibt es eine einfache Regel

/$controller/$action/$param

So würde der Aufruf

/laender/view/deutschland

folgendes bewirken:

• gehe zum Controller LaenderController
• führe die Methode “view” mit dem Argument “deutschland”  aus

Für die normalen Aktionen (CRUD ) werden die Views “list”, “create” , “show” und “edit” erzeugt, welche man an seine Bedürfnisse anpassen kann.

Wo ist das Aber?

Grails unterstützt und beschleunigt den kompletten Entwicklungsprozess.
Der Start geht sehr schnell und reibungslos.
Der Railsway erzeugt sehr schnell funktionierende Webanwendungen.

Aber

Das Ganze hat auch seinen Preis :

• Die Modelle
  • generieren standardmässig alles
  • brauchen im Gegensatz zu handgeschriebenen Klassen mehr Speicher
• Die Controller
  • generieren auch viel Overhead
  • haben einige tricky Bugs
    • [3]
    • [4]
  • die generierten SQL-Statements sind teilweise suboptimal
  • die generierten SQL-Statements benutzen selten die DBMS-spezifischen Optimierungen
• Die Views
  • durchlaufen mit Sitemesh und JSP zwei Kompilierungsprozesse

Fazit

• Mit Grails kann man sehr schnell an ordentliche Ergebnisse kommen.
• Mit Grails konzentriert man sich auf die wesentlichen Elemente der Entwicklung
• Mit Grails hält man sich an Standards
• Mit Grails muss man einen gewissen Overhead einrechnen
• High-Performance und Optimierung kostet einen Grossteil der Zeit, die man spart

Links

http://www.grails.org/

http://www.youtube.com/watch?v=Gzj723LkRJY

http://adhockery.blogspot.com/2009/06/querying-by-association-redux.html

http://adhockery.blogspot.com/2009/04/when-is-pirate-not-pirate-when-its.html