Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1244

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1442

Strict Standards: Redefining already defined constructor for class wpdb in /www/htdocs/v167612/wplog/wp-includes/wp-db.php on line 306

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /www/htdocs/v167612/wplog/wp-includes/cache.php on line 433
iFool » Groovy & Grails

Archiv

Archiv für die Kategorie ‘Groovy & Grails’

HSQLDB nicht als “inMemory-DB” nutzen

16. Dezember 2009

Auch bei der Entwicklung einer Anwendung und den damit verbundenen Tests kann es recht lästig sein, immer wieder “zu Fuß” Testdaten eingeben zu müssen. Die von GRAILS automatisch verwendete HSQLDB ist in der Data-Source als inMemory-DB konfiguriert und daher gehen alle erfassten Daten bei jeder Beendigung der Anwendung verloren.

Zwar kann man durch entsprechende Einlassungen im Bootstrap auch Testdaten “beim Hochfahren” generierern, aber das ist für flexible Tests auch nicht so prickelnd, zumal die Erfassung über Programmierung auch Mühen bedeutet.

Eine gute Alternative bietet die Möglichkeit, einfach die HSQLDB-Datasource anzupassen:


 development {
  dataSource {
   dbCreate = "update" // one of 'create', 'create-drop','update'
   url = "jdbc:hsqldb:file:/temp/test/mydb;shutdown=true"
  }
 }

In diesem Beispiel auf einem PC mit Windows 7 wird beim ersten Start ein Verzeichnis C:\temp\test mit folgenden Files erstellt: mydb.lck, mydb.log, mydb.script und mydb.properties.  In den Textdateien mydb.script und mydb.log werden die Tabellendefinitionen und die Daten in lesbarer Form gespeichert. Beim Start der Anwendung wird dann jeweils aus diesen Textdateien wieder eine schnelle “inMemory-DB” aufgebaut. Während die Anwendung läuft werden DB-Änderungen in der *.log-Datei protokolliert, sodass die Daten auch bei einem Crash der Anwendung nicht verloren gehen können.

Die Verwendung von HSQLDB in Verbindung mit Textdeateien zur Speicherung der Daten ist eine bequeme und sofort Verfügbare Alternative für jeden GRAILS-Entwickler. Außerdem kann es auch eine Alternative für den Livebetrieb in Anwendungen mit kleinem Datenbestand sein (bei wenigen Hundert Datensätze etwa).

Allgemein, Groovy & Grails

GRAILS: Cursor beim Seitenaufbau automatisch in ein bestimmtes Feld setzen

9. März 2009

Die Aufgabenstellung ist eigentlich trivial: Im Body-Tag der GSP-Seite kann man das im OnLoad-Event sehr einfach vorsehen:


<body OnLoad="document.myform.startnummer.focus(); document.myform.startnummer.select();">

In diesem Beispiel wird bei einer create.gsp-Seite der Focus auf das Feld “startnummer” im Formular “myform” gesetzt und der Inhalt des Feldes gleichzeitig markiert. Dummerweise funktioniert das aber nicht so ohne weiteres.

Wenn man sich den Sourcecode der fertig gerenderten Seite ansieht erkennt man ein leeres <body>-Tag! Das liegt daran, dass bestimmte Standards durch das Layout der Anwendung vorgegeben werden. Ein OnLoad-Event ist zunächst nicht vorgesehen. Man kann es aber sehr einfach durch die folgende Ergänzung der Seite /views/layouts/main.gsp gewissermaßen “freischalten”:


   <body onload="${pageProperty(name:'body.onload')}">

Groovy & Grails

GRAILS quickstart mit MySQL

24. Februar 2009

mysql_logoIch dachte mir, es sei ganz nützlich immer ein Datenbanksystem auf dem Notebook zu haben und installierte mir deshalb schnell mal MySQL. Das war mit dem MSI-Installer für Windows auch garkein Problem: Einfach die Standardversion (derzeit MySQL Server 5.1) ausgewählt und schon war die Basis fix und fertig eingerichtet.

Jetzt galt es nurnoch, eine Datenbank mit gültigem User einzurichten und ein paar Handgriffe im Setup der GRAILS-Anwendung zu unternehmen, die mit MySQL zusammenarbeiten sollte.

Den Job mit der Datenbankeinrichtung hat mir ein kleines Script abgenommen (Dateiname C:\temp\create_rc.sql):


DROP DATABASE RC;
CREATE DATABASE RC;
USE RC;
DROP USER 'rcuser'@'localhost';
CREATE USER 'rcuser'@'localhost';
GRANT ALL PRIVILEGES ON RC.* TO 'rcuser'@'localhost';

Mehr…

Groovy & Grails ,

Wie werde ich die ID-Spalten los? Arbeiten mit Templates

15. Januar 2009

GRAILS macht eigentlich automatisch schon sehr schöne Listen aber “per default” werden dabei leider alle Attribute berücksichtigt. Das führt dann dazu, dass man die unwichtigen ID-Felder zur scheinbar wichtigsten Spalte werden: Sie stehen an erster Stelle und werden dann auch noch mit der “show”-Aktion der zugehörigen Domänenklasse verlinkt.

listwithoutid_fieldSo wie links im Bild sieht es schon besser aus: Das ID Feld wird unterdrückt und statt dessen das erste (kennzeichnende) Feld gesetzt und verlinkt.

Jetzt könnte man das für jede Domainklasse nach der Generierung der Ansichten (gsp-Views) anpassen, aber das macht keinen richtigen Spaß, denn

    1. Wäre das eine relativ stupide Arbeit, die man für jede einzelne Domainklasse durchführen müsste
    2. Würde das ganze nach dem nächsten Generieren wiederholt werden müssen

Die Bessere Alternative ist hier die Arbeit mit den Templates, um das GRAILS-Verhalten nachhaltig zu ändern

Mehr…

Groovy & Grails, IT

Validierung der Benutzereingaben innerhalb der Domainklasse

14. Januar 2009

validierung_messagesDomainklassen bestimmen hauptsächlich die Eigenschaften der Businessobjekte und die Beziehungen dieser Objekte untereinander. Zu den Eigenschaften gehört die Anzahl, Art und Ausprägung der einzelnen Attribute.

Die Art und Anzahl der Attribute wird durch Deklaration einzelner Objekte und einfacher Datentypen im Kopf der Klasse vorgenommen. Wie kann der Entwickler dann Einfluss auf die gültigkeit der Benutzereingaben nehmen? Hier geht es um Validierung…

In der Abbildung wird ein “Create-Dialog” für eine Domainklasse “Archiv” gezeigt, die 2 Attribute enthält: Name des Archivs und Beschreibung.  Der Benutzer hat mit seinen Eingaben gegen 2 Validierungsregeln verstoßen und ich möchte kurz einmal zeigen, wie soetwas funktioniert.

Mehr…

Allgemein, Groovy & Grails

Autoinkrementierung bei bestehenden DB2/400 Tabellen

2. Januar 2009

Die im “alten Stil” erstellten DB-Tabellen wurden über DDS-Sourcecodebestimmungen beschrieben und anschließend mit CRTPF erstellt. Views (logische Sichten) wurden ebenfalls mit DDS beschrieben und mit CRTLF erstellt.

Heute sollte man Tabellen  mit SQL erstellen und ändern. Wer jedoch eine mit DDS beschriebene Tabelle später um ein Auto-Inkementierungsfeld erweitern möchte hat schlechte Karten: Es existiert kein entsprechendes DDS-Schlüsselwort und ein ALTER-Table der folgenden Art schlägt ebenfalls fehl:

ALTER TABLE AULICH/M$SE009PA ADD COLUMN ID BIGINT NOT NULL GENERATED
 ALWAYS AS IDENTITY
                                                
M$SE009PA in AULICH für Operation ungültig.                        

Die genaue Fehlermeldung lautet SQL7008 M$SE009PA in AULICH für Operation ungültig.   14 - DATALINK-, LOB- oder IDENTITY-Spalte kann einer Nicht-SQL-Tabelle
nicht hinzugefügt werden.                                              

Autoinkrementierung mit DDS-beschriebenen Datenbankdateien geht nicht. Jedenfalls nicht auf normalem Weg! Wer sich damit nicht abfinden kann und die bestehenden Tabellen nicht auf SQL-Tabellen migrieren kann, dem bietet sich ein halbwegs eleganter Ausweg über die Erweiterung der DDS-Tabellenbeschreibung um ein “normales” ID-Feld (numerisch, 18,0) und das Füllen dieses Feldes über ein Triggerprogramm.

Mehr…

AS400, Groovy & Grails

Groovy & Grails

2. Januar 2009

Grails Logo

Webanwendungen zu erstellen kann sehr mühsam sein. Ich hatte in der Verganagenheit häufig Probleme mit

  • komplexer Softwarearchitektur
  • fehlenden Konzepten für eine einheitliche Anwendungsstruktur
  • Entscheidungen für das “richtige” Framework

Webanwendungen spielen aber eine immer größere Rolle im LAN bzw. Intranet auch mittelständischer Betriebe. Wenn ich dort als Systemintegrator unterwegs bin um z.B. unser DMS MultiArchive in die Systemlandschaft zu integrieren habe ich schnell die Anforderung auf dem Tisch kleinere Funktionen als Bindeglieder zwischen den Anwendungssystemen neu zu erstellen. Ein Beispiel: Die Wareneingänge zu einem bestimmten Lieferschein sollen direkt aus dem Browser-Frontend von MultiArchive über ein weiteres Browserfenster angezeigt werden können. Das ERP-System bietet diese Funktion aber nicht!

Mehr…

Groovy & Grails ,