Kein Kommando ohne id
Posted on 23.04.2010 by tc77
Bei der Validierung kommt es an vielen Stellen meiner Grails basierten Anwendung zum Einsatz von sogenannten Kommando-Objekten, welche die Überprüfung von Parametern und unter Umständen die Erstellung von gültigen Domain-Klassen bzw. deren Instanzen übernehmen.
Heute bin ich dabei über eine Kuriosität gestoßen. Grails (Version 1.2.2) weigerte sich, die eingehenden Request-Parameter auf das Kommando-Objekt “zu setzen”. Obwohl also id und version ordnungsgemäß über ein Formular via POST versandt wurden kamen diese nicht im Kommando-Objekt an und verweilten bei null.
Um das Ganze zu verdeutlichen habe ich mal den folgenden Code-Schnipsel synthetisiert:
class MyCommand {
def id
def version
private _domain
def getDomain() {
_domain ?: Domain.get(id)
}
static constraints = {
id(validator: { val, obj ->
if (!obj.domain) {
return [ 'domain.not.found' ]
}
})
version(validator: { val, obj ->
def version = val?.toLong()
if (obj?.domain?.version > version) {
return [ 'version.mismatch' ]
}
})
}
}
Nach einiger Tüftelei hat sich herausgestellt, dass wenn ich version und dessen constraint entferne, das Feld id wie gewohnt gesetzt wird.
Eine praktikable Lösung – außer die Überprüfung der Version in der Aktion – habe ich allerdings nicht auf Lager.
Wiederholter Neustart von Grails
Posted on 22.04.2010 by tc77
Die Erkennung von Änderungen und der damit verbundene Neustart von Grails ist ein wahrer Segen bei der Entwicklung. Unter Umständen verselbstständigt sich dieser Mechanismus allerdings und Grails fährt die Anwendung rauf und runter, wodurch kein Arbeiten mehr möglich ist.
Heute bin ich also gleich mal in die Neustart-Hölle gestolpert und Grails kompilierte wieder und wieder eine unbekannte Quelldatei, von welcher Grails dachte sie sei verändert worden.
Die Lösung ist relativ simple bzw. war sie es in meinem Falle. Ich hatte beim Anlegen eine Klasse unter /src/groovy vergessen Sie mit dem entsprechenden package zu versehen, was Grails offensichtlich irritierte. Nachdem der Fehler korrigiert war lief wieder alles wie gewohnt.
Arbigge mit Netbeans
Posted on 14.04.2010 by tc77
Eigentlich bin ich derzeit mit IntelliJ IDEA unterwegs und recht zufrieden. Allerdings weigert sich IDEA bei meinem aktuellen Grails-Projekt die Klassen unter /src/groovy und /src/java zu erkennen, es zeigt sie weder im Grails- noch im Projekt-Tabulator an.
So beschloss ich nach längerer Abstinenz mal wieder einen Blick auf Netbeans zu werfen, was aktuell in der Version 6.8 vorliegt. Schön war, Netbeans erkannte ohne große Umschweife mein Grails-Projekt und öffnete es ohne Murren. Anschließend gab’ sich Netbeans erstmal eine 10 minütige Pause und scannte das Projekt. Während dieser 10 Minuten lässt sich so ziemlich gar nichts mit Netbeans anstellen, außer man hat Gefallen an der schnöden Fortschrittsanzeige.
Nachdem Netbeans das Projekt auf Herz und Nieren untersucht hatte konnte ich dann endlich loslegen. Eigentlich sollte Netbeans ja nun mit allen Klassen meines Projektes Bekanntschaft gemacht haben und mir diese, sowie deren Eigenschaften und Methoden, über die Syntax-Vervollständigung anbieten. Nix da! Beim Aufruf der Syntax-Vervollständigung verfällt Netbeans erstmal in eine Denkpause, welche jedoch nichts brauchbares zu Tage fördert. Das Beste: Während ich so duch den Code poltere hat es Netbeans innerhalb von 10 Minuten geschafft sich 3 Mal wegzulegen.
Gibt es eigentlich Entwickler da draußen, die mit Netbeans arbeiten sich mit Netbeans stressen?
Could not find a setter for property
Posted on 09.04.2010 by tc77
Folgendes Konstrukt führt in einer Grails Domain-Klasse unweigerlich zu einer org.hibernate.PropertyNotFoundException mit der Meldung Could not find a setter for property count in class Group.
class Group {
int getCount() {
...
}
}
Die Lösung ist relativ simpel. Wir müssen Grails mit static transients = [ "count" ] lediglich mitteilen das die Eigenschaft count flüchtig ist:
class Group {
static transients = [ "count" ]
int getCount() {
...
}
}