Man lernt ja jeden Tag etwas neues. Gestern habe ich gelernt, dass Grails von Haus aus nur ein Element per Ajax austauschen kann. Man klickt auf einen Link und kann dann z.B. den Inhalt eines DIV-Tags ersetzten, ergänzen oder was auch immer. Das ist alles ganz nett und einfach. Ändert sich aber durch eine Interaktion mehr als ein Element auf der Seite, fängt es an kompliziert zu werden. Wobei kompliziert eigentlich nicht das richtige Wort ist, denn man muss diese fehlende Funktionalität selbst ergänzen.
Es ist unzweifelhaft möglich, so das gewünschte Ziel zu erreichen. Aber ich finde es spannend, dass es eine IMHO derart triviale Anforderung nicht in den “Grails-Standard” geschafft hat. In Wicket füge ich die Komponenten, die aktualisiert werden müssen, einfach zu einer Liste hinzu. Ich muss mich nicht darum kümmern, was dann genau passiert.
Festzuhalten bleiben für mich die Punkte, die für mich eher gegen einen Einsatz von Grails sprechen:
- Ajax Update nur für ein Element möglich.
- Spring Security ist pfadbasiert – das ist IMHO ein extrem limitierter Ansatz.
- Taglibs sind kein Ersatz für Komponenten.
Grails hat Stärken.. aber ich bezweifle zunehmend, dass in Projekten, die mit Grails angefangen wurden, Grails diese positiven Effekte aus dem Projektstart auch auf lange Sicht ausspielen kann.
Update:
Immerhin habe ich gerade wieder gelernt, dass man Spring Security auch mit Annotationen am Controller benutzen kann, so dass man die Pfade nicht von Hand aktualisieren muss, wenn man etwas umbaut.
Das ich hier vielleicht Wicket und Grails vergleiche, obwohl die beiden Technologien nicht so einfach vergleichbar sind, bezieht sich in dieser Kritik nur auf den View-Layer. Es gibt sehr viele Dinge, die ich recht cool finde, an Grails. Aber um View-Layer bin ich einfach besseres gewohnt.
Also als Grails-Freund kann ich mir folgenden Kommentar nicht verkneifen
Warum wird eigentlich ein Web-Framework (Wicket) mit einem komplexen Framework zur Entwicklung von Web-Anwendungen (Grails) verglichen? Das wäre ziemlich unfair Wicket gegenüber, weil bei Grails schon so viel verwendbar vorliegt … Stichworte Groovy, Hibernate, Spring, SiteMesh im Grails-Unterbau, sowie Scaffolding, Internationalisierung usw. usf.
In einem Punkt stimme ich gerne zu … Grails hat standardmässig noch Nachholbedarf im reinen UI-Development und man kommt nicht umhin, Plugins bzw. Javascript-Librarys zu includen.
Im Zweifelsfall kann das dann auch gerne das Wicket-Plugin zur Gestaltung der Oberfläche sein, dessen Runderneuerung für Grails 1.2 erwartet wird.
Zum Thema Spring Security … mit “pfadbasiert” meinst du die URL-basierte Absicherung per Request-Map?
Das ist ja nur eine Möglichkeit. Viel besser ist die Verwendung von Controller Annotations. So ist es möglich, jede einzelne Controller-Action gegen beliebige Rollen abzusichern und das erfolgt dann wenigstens auf dem Class-Level.
Viele Grüße
Falk
Sag mal: was macht dieses SiteMesh denn eigentlich?
Ansonsten hast Du in vielen Punkten recht:) Habe den Beitrag auch schon aktualisiert.
So wie ich das verstanden habe, ist SiteMesh eine Layout-Rendering-Engine, worauf Grails im View-Bereich basiert. Darüber wird z.B. Merging von Templates/Taglibs und die Wiederverwendung/Kombination dieser Komponenten gelöst.
Die bessere Beschreibung wäre: Sitemesh is “a web-page layout and decoration framework and web- application integration framework” (von hier). Schwerpunkt liegt auf “decoration” und “integration”.