Artikel

 
September 2009 | Artikel

Grails 1.2: Spring 3, Uri Rewriting und mehr Fortsetzung, Teil 3

Teil 1   Teil 2   Teil 3   

Exception bei save()

Die Methode save() einer Domainklasse liefert ein null, wenn die Validierung der Domain-Klasse fehlschlägt und die Instanz der Klasse selbst, wenn die Validierung erfolgreich war. Das heißt, wenn man es versäumt, den Rückgabewert der Methode zu überprüfen, weiß man nicht, ob eine erfolgreiche Speicherung erfolgt ist und läuft so typischerweise in NullPointerExceptions. Es gibt nun ein neues Argument für die save()-Methoden:

  1. try {
  2. user.save(failOnError:true)
  3. }catch(ValidationException e) {
  4. // handle
  5. }

Dadurch wird eine Exception erzwungen, wenn die Validierung fehlschlägt. Dies macht besonders den Einstieg für Java-Entwickler einfacher.

Vorkompilierung der GSPs

GSPs werden im laufenden Betrieb des Webcontainers in Java-Klassen kompiliert. Hierbei wird PermGen Space benutzt, ein spezieller Bereich des Heaps. Hat man viele GSP-Seiten, so wird entsprechend viel dieses Speichers benutzt. Der Default-Wert liegt bei 64 MB. Der ein oder andere Java-Entwickler hat den ungeliebten Fehler java.lang.OutOfMemoryError: PermGen space des Öfteren schon gesehen. Man kann jetzt natürlich den Wert des Speichers erhöhen, jedoch sollte man die "günstige" Möglichkeit der Precompilation auf jeden Fall nutzen. Wenn man eine War-Datei mit dem Befehl grails war erstellt, so geschieht dies automatisch.

Tomcat als Default Container

Bis zur Version 1.1.1 benutzt das Grails-Framework Jetty als Standardwebcontainer. Seit der Version 1.2 ist jedoch Tomcat als Standardcontainer konfiguriert, und zwar als Plug-in. Möchte man wieder Jetty, so reicht es, das Tomcat-Plug-in zu deinstallieren und das Jetty-Plug-in zu installieren.

Verbesserte i18n-Unterstützung für class- und property-Namen

Klassen- und Property-Namen können nun in den entsprechenden message.properties Dateien definiert werden, die dann auch in den dynamischen scaffolded views Berücksichtigung finden. Dies war bis jetzt nur durch Plug-in-Erweiterungen möglich.

Named URL Mappings

Sie können in der UrlMappings.groovy nun benannte Mappings definieren, z.B.:

  1. name demoListing: "/detail/list" {
  2. controller = 'demo'
  3. action = 'list'
  4. }

Dieses Mapping kann dann von dem dazugehörigen Link Tag in der View benutzt werden:

  1. <link:demoListing>Demo</link: demoListing>
Project Documentation Engine

Die Grails-Referenzdokumentation wurde mit einer eigenen Engine erstellt. Diese Dokumentations-Engine benutzt eine Variante der Textile-Syntax, um automatisch eine Projektdokumentation zu erstellen mit Links, Formatierung etc. Nun steht diese Engine auch für eigene Projekte zur Verfügung.

Plug-in Metadata Generator

Bei der Veröffentlichung eines eigenen Plug-ins ins Plug-in-Repository von Grails werden seit Grails 1.2 Metadaten zu dem Plug-in generiert, wie dynamisch injizierte Methoden und Properties. Diese Metadaten werden in die plugin.xml-Datei gespeichert. Dies ist insbesondere nützlich für IDEs, die dann mit den Informationen z.B. eine Code-Completion für die betroffenen Klassen anbieten können.

Fazit

Grails bietet mit der Version 1.2 einige sehr interessante Neuerungen, die das Framework immer mehr für den professionellen Einsatz im Enterprise-Bereich interessant macht. Einige davon sind: Einsatz von Spring 3.0, methodenbasierte Transaktionen in Services, Named Urls, Named Queries und Tomcat als Standardcontainer.

Masiar Ighani ist freiberuflicher J2EE-Entwickler/Architect/Coach und Autor. Er hat 15 Jahre Projekterfahrung in diesen Bereichen und spezialisiert auf IDM und SOA. Seit einem Jahr beschäftigt er sich auch leidenschaftlich mit dem neuen Grails-Framework.
  1. Grails Framework
  2. Spring 3.0
  3. Documentation Engine: Punkt 3.6

Teil 1   Teil 2   Teil 3   

Anzeige

Kommentare

Gravatar Trepper 29.09.2009
um 12:55 Uhr
Vor allen Dingen die Qualität von Grails sollte verbessert werden. Es gibt sehr alte nicht behobene Fehler und immer wieder tückisches Verhalten etwa dass der Rückgabewert einer Closure bei beforUpdate und afterUpdate einmal ausgewertet und einmal ignoriert wird. Das ist nirgends dokumentiert.Ansonsten wäre es noch schön wenn perspektivisch Scala eine größere Rolle spielen würde denn aus meiner Sicht hat die Sprache viele Vorteile gegenüber Groovy.Von den kleinen Macken abgesehen ist Grails aber ein feines Framework mit dem die Arbeit Spaß machen kann. Von der Architektur gefällt es mir auch besser als anderen RoR-artigen. #zitieren

Anzeige

zurück zum Seitenanfang