ieko artikel

dsl mit groovy

Mon, 02 Jun 2008 00:00:00 +0200

groovy-dsl-tutorial

die script-sprache groovy (http://groovy.codehaus.org) eignet sich gut zur erstellung einer textbasierten dsl (domain specific language).

in diesem artikel soll anhand eines kleinen beispiels eine mgöliche vorgangsweise demonstriert werden.

ziel ist eine einfache dsl zur beschreibung von datenbank-tabellen, um daraus ein sql-statement zur erzeugung der tabelle zu generieren.
(anmerkung: das ist natürlich nur eine demonstration der möglichkeiten, die sinnhaftigkeit des beispiels soll hier nicht zur debatte stehen.)

hier die angestrebte dsl:

table("test") {
    column "id", datatype: "int", notnull: true
    column "name", datatype: "text"

erklärung:
in zeile 1 wird die tabelle "test" definiert, die 2 columns hat:
in zeile 2 wird die column "id" definiert, deren datentyp int ist und die zwingend ausgefüllt sein muss (not null)
in zeile 3 wird die column "name" mit dem datentyp text definiert

das ergebnis soll ein create-statement mit folgendem aussehen sein:

create table test (
   id   int   not null,
   name   text
);

hier nun die schritte im einzelnen:

vorbemerkung: groovy hat ein "builder"-konzept, das sich hervorragend für diese art der dsl eignet. mit dem groovy-builder können alle hierarchischen sachverhalte verwaltet werden.
es ist in diesem beispiel nicht zwingend nötig, ich empfehle aber trotzdem die verwendung der FactoryBuilderSupport-klasse, die die abarbeitung einzelner tags (wie hier table und column) in eigene factories auslagert. dadurch wird der builder übersichtlicher, leichter erweiterbar und wartbarer.

model: als erstes sollten wir ein daten-model definieren, in dem wir die informationen über tabellen und columns speichern.

dazu erzeugen wir 2 klassen:
TableModel.groovy:

class TableModel {
   /**
    * Name der Tabelle
    */
   String name
   /**
    * Liste der Columns
    */
   ArrayList<ColumnModel> columns = new ArrayList<ColumnModel>()
}

und ColumnModel.groovy

class ColumnModel {
    /**
     * Tabelle, zu der diese Column gehört
     */
     TableModel table
    /**
     * name der column
     */
    String name
    /**
     * datentyp
     */
    String datatype
   /**
    * not null
    */
   boolean notnull
}

die beiden klassen definieren ihre klassen-variablen, die tabelle besitzt noch eine liste der columns, die column eine referenz auf die tabelle (diese referenz ist in unserem beispiel nicht nötig, bei komplexeren anwendungen ist es durchaus sinnvoll, zugriff auf sein master-objekt zu haben).
bei der definition der attribute ohne sichtbarkeits-hinweise (public, protected, private) macht groovy sogenannte properties daraus, die automatisch über zugriffsmethoden getXxx und setXxx verfügen und auch als object.xxx angesprochen werden können.
obwohl es in groovy nicht nötig ist, datentypen anzugeben (wir könnten auch def name schreiben), ist es aus meiner sicht sinnvoll, den datentyp anzugeben, sofern er feststeht und unveränderlich sein soll.

als nächstes erstellen wir die builder-klasse
TableBuilder.groovy:

class TableBuilder extends FactoryBuilderSupport {

public TableBuilder() {
registerTags()
}

protected void registerTags() {
registerFactory("table", new TableFactory())
registerFactory("column", new ColumnFactory())
}
}

hier wird für jeden verwendeten tag eine factory registriert.
die beiden factory-klassen werden als nächstes implementiert:
TableFactory.groovy:

class TableFactory extends AbstractFactory {
   /**
    * Erzeugen Class
    */
   Object newInstance( FactoryBuilderSupport builder, Object name, Object value, Map attributes )
           throws InstantiationException, IllegalAccessException {
      attributes += [name : value]
       return new TableModel(attributes)
    }
}

ColumnFactory.groovy:

class ColumnFactory extends AbstractFactory {
   /**
    * Erzeugen Column
    */
Object newInstance( FactoryBuilderSupport builder, Object name, Object value, Map attributes )
throws InstantiationException, IllegalAccessException {
attributes += [name : value]
return new ColumnModel(attributes)
}

   /**
    * add Column to Table
    */
   public void setParent( FactoryBuilderSupport builder, Object parent, Object child ) {
      child.table = parent
      parent.columns += child
   }
}

in der methode newInstance wird jeweils eine neue instanz unserer model-klasse erzeugt.
hinweis zur zeile attributes += [name : value]:
mit groovy kann man ein objekt erzeugen, in dem man im konstruktor eine map übergibt. existieren kein konstruktor mit einzigem parameter vom typ map und ein standard-konstruktor ohne parameter, so erzeugt groovy ein objekt mit diesem standard-konstruktor und setzt dann die werte der properties anhand der übergebenen map.
da die factory in unserem beispiel jedoch den namen der tabelle bzw. column nicht in der map sondern im value übergeben bekommt, müssten wir eigene konstruktoren mit map und name erzeugen. um uns das ersparen, erweitern wir einfach die übergebene map um den namen mit dem wert, der in value steht. damit kann der groovy-automatismus verwendet werden.

die methode setParent in der ColumnFactory ermöglicht es uns, die beziehung zwischen tabelle und column zu setzen. in der column (child) wird die refernz auf die tabelle (parent) gesetzt, in der tabelle wird eine column in die liste der columns hinzugefügt.

anwenden: damit sind wir schon so weit, dass wir mit dem script

def builder = new TableBuilder();

def table = builder.table("test") {
column "id", datatype: "int", notnull: true
column "name", datatype: "text"
}

ein model der tabelle samt columns erzeugen können.

anmerkung: dank groovy können klammern in funktionsaufrufen wegfallen. deshalb ist statt

column ("id", datatype: "int", notnull: true)

auch folgende schreibweise möglich:

column "id", datatype: "int", notnull: true

jetzt fehlt nur mehr die ausgabe des create-statements, die dank der kompaktheit von groovy nur wenige zeilen umfasst:
die klasse TableModel wird um die methode create() erweitert:

   /**
    * erzeugt das create-statement für die tabelle
    */
   String create() {
      return "create table ${name} (\n" +
      (columns.collect {
         "\t" + it.create();
      }).join(",\n") + "\n);"
   }

und die klasse ColumnModel ebenfalls:

   /**
    * erzeugt das create-statement für die column
    */
   String create() {
      return name + "\t" + datatype + (notnull?"\tnot null":"")
   }

nun erweitern wir das scipt noch um die ausgabe:

def builder = new TableBuilder();

def table = builder.table("test") {
column "id", datatype: "int", notnull: true
column "name", datatype: "text"
}

println table.create()

das ergebnis kann natürlich auch gleich in eine sql-datei gespeichert oder über eine jdbc-connection direkt ausgeführt werden.

fazit: mit groovy kann mit wenig code eine dsl definiert werden.
mit dem builder-konzept und der kompakten syntax zeigt groovy hier seine volle stärke.

die source-files zu diesem tutorial können sie hier downloaden.

danke für ihre aufmerksamkeit,
ich feue mich über kommentare und anregungen.

ausdruck von web-seiten mit css optimieren

Tue, 03 Jun 2008 00:00:00 +0200

mehr platz zum drucken mit css

beim erstellen des layouts einer web-seite wird vor allem darauf geachtet, dass die bildschirmdarstellung ansprechend ist. leider wird oft vergessen, dass die anwender/innen den inhalt der seite auch ausdrucken wollen. besonders bei längeren artikeln oder wichtigen informationen ist ein ausdruck oft hilfreich.

da aber das layout für den bildschirm und dem interaktiven umgang mit der seite erstellt wurde, muss man für den ausdruck einige anpassungen vornehmen, sonst ist das ergebnis äußerst unzufriedenstellend und auch keine werbung für den betreiber der web-seite. am ausdruck brauche ich keine menü-navigation oder such-felder, und wenn diese links und/oder rechts auch noch platz wegnehmen, bleibt für den eigentlichen inhalt oft nur ein schmaler streifen in der mitte, der sich dafür aber über unzählige seiten hinzieht, bei denen der meiste platz am papier nicht genutzt wird.

im folgenden mache ich ein paar vorschläge, wie mit css (cascading style sheets) bei wenig aufwand ein gutes druckbild erzeugt werden kann.

keine frames

der erste punkt bezieht sich auf die grundlegende architektur der web-seite. dabei sollte die verwendung von frames vermieden werden.
speziell beim drucken führen frames zu problemen: entweder werden alle frames ausgedruckt, was papierverschwendung ist, da navigations-menüs etc. nicht benötigt werden oder die anwender/in muss genau darauf achten, welchen frame sie drucken will.
(zudem sind frames auch in zusammenhang mit suchmaschinen ungeeignet, da oft nur teile einer seite gefunden und angezeigt werden.)

eigenes css für das drucken

nun zu den dingen, die wir mit css erledigen können.
dazu ist es erst einmal nötig, dass wir ein eigenes css-script für den ausdruck erstellen und in die html-seite einbauen. wichtig dabei ist, dass das druck-css nach dem allgemeinen css angegeben wird und für das medium "print" definiert wird:

<html>
<head>
...
<link rel="stylesheet" href="css/allgemein.css">
<link rel="stylesheet" media="print" href="css/druck.css">
...

das druck.css muss nach dem allgemein.css kommen, damit wir dann allgemeine layout-eigenschaften für den ausdruck überschreiben können. eine sauberere aber aufwendigere lösung wäre die aufteilung in 3 css-dateien, eine die die anweisungen für alle medien ("all") beinhaltet, eine die für das layout am bildschirm zuständig ist (media="screen") und eine die den ausdruck definiert.
der einfachheit halber machen wir uns jedoch zu nutze, dass bei mehrmaliger definition einer css-eigenschaft jene verwendet wird, die zuletzt kommt. deshalb kommt druck.css nach allgemein.css und überschreibt nur im falle des druckens die nötigen css-anweisungen.

alles ausser dem eigentlichen inhalt ausblenden

nun zur konkreten arbeit mit css:
als anwender/in möchte ich nur den eigentlichen inhalt der aktuellen web-seite ausdrucken. somit will ich dinge wie navigations-menü, such-felder, news- oder andere hinweise nicht drucken.
das können wir steuern, in dem wir alle bereiche, die nicht zum inhalt gehören, beim drucken nicht anzeigen.
im druck.css definieren wir daher zum beispiel:

#ContentLeft,
#ContentRight,
.navigatoin,
.news {
   display: none;
}

wobei sie natürlich die ids oder class-names (ContentLeft, ContentRight, navigation, news) an ihre web-seite anpassen müssen.

content-bereich maximieren

oft genügt es noch nicht, alles rundherum ausblenden. durch ein eventuell fixes layout hat der inhalt noch immer nicht mehr platz. dann ist es nötig, die css-eigenschaften für den content-bereich zu überschreiben. in welcher form hängt natürlich von ihrem layout ab, zum besipiel:

#Content {
   width: 100%;
   margin-left: 0;
   margin-right: 0;
}

kopfbereich verkleinern

einen kopf (header) sollte die seite natürlich haben. anbieter/innen möchten hier ihr unternehmen präsentieren, anwender/innen möchten wissen, von wem die information stammt.
der kopf muss am papier nicht so aussehen wie am bildschirm und manchmal macht es sinn, wenn wir den kopf-bereich der seite verkleinern, eventuell das logo kleiner ausdrucken, die schriftgröße minimieren.
hier können wir ebenfalls die css-eigenschaften der allgemeinen css-datei überschreiben und so den kopf für den druck anpassen.

#Header{
   font-size: 1.5em;
}
#Header img {
   height: 2 em;
}

... und was sonst noch alles nötig ist, eventuell auch das ausblenden von verschiedenen inhalten im kopfbereich.

keine hintergrundfarbe und -bild

ob der hintergrund mit ausgedruckt werden soll oder nicht lässt sich zwar im browser einstellen, aber warum soll sich die anwender/in darum kümmern müssen, wann sie umstellen muss und wann nicht. aus meiner sicht ist es service am kunden, wenn der ausdruck die farbpatronen der tintenstrahldrucker nicht unnötig leert. daher ausschalten von hintergrundfarbe und auch von hintergrundbildern, sofern sie nicht für den inhalt bedeutend sind.

body,
#Content {
   background-color: #FFFFFF;
   background-image: none;
}

links / zitate

angeregt durch einen kommentar von "Oliver" hier noch ein paar weitere hinweise:
(an dieser stelle herzlichen dank für das qualifizierte feedback von oliver.)

stellen sie links in der webseite in einer anderen farbe dafür ohne unterstreichung dar, kann man diese bei einem schwaz-weiss-ausdruck nicht mehr erkennen. daher kann es gut sein, diese wieder unterstrichen darzustellen.

a {
   color: #000;text-decoration: underline
}

des weiteren ist es natürlich am papier nicht möglich, den link anzuklicken. und da man nur den Text sieht, weiss man anhand des ausdrucks nicht mehr die adresse, auf die der link verweist. um die link-adresse auszugeben, bedienen wir uns eines css-pseudoelements namens ":after". damit kann man nach einem html-element automatisch inhalte ausgeben (mit ":before" davor).

a {
   content: " [" attr(href) "]";
   background-color: inherit;
   color: #369;font-style: italic;
}

bewirkt nun, dass die linkadresse (das attribut "href") nach dem link-text zwischen [ und ] kursiv ausgegeben wird.

für zitate, die sie in dieser form definieren

Zitat: <q cite="urheber des zitats">Das ist ein Zitat</q>

gibt es die möglichkeit, den urheber bzw. die quelle des zitats auch auszugeben. dazu bedienen wir uns wieder des :after-pseudoelements und schränken den css-selektor auf alle "q" ein, die das attribute "cite" definieren:

q[cite]:after {
   content:close-quote " (Quelle: " attr(cite) ")";
}

kommentare

ich hoffe, die hinweise waren nützlich für sie, ich freue mich über weitere anregungen und vorschläge, die sie als kommentar hinterlassen können.

groovy, dsl und templates

Tue, 17 Nov 2009 00:00:00 +0100

groovy-dsl-tutorial

im artikel dsl mit groovy gaben wir anhand eines kleinen beispiels eine einführung in groovy-dsl. wir haben eine tabelle mit ihren spalten definiert und dann ein create-table-statement daraus generiert.

da es eine groovy-dsl einführung war, haben wir ein wichtiges prinzip der softwareentwicklung, nämlich die trennung von model und view, vernachlässigt. (zum erzeugen des create-statements hatten wir die create-funktionen im Table- und ColumnModel.) das möchten wir in diesem artikel nachholen.

unser beispiel:

angenommen sie entwickeln eine datenbankanwendung mit hunderten von tabellen und eine anforderung ist, dass die anwendung mit unterschiedlichen datenbanken läuft. mit unserer bisherigen lösung müssten wir für jeden datenbankdialekt eine eigene create-funktion implementieren. da wir unser model aber nicht mit noch mehr code überfrachten wollen, wählen wir einen anderen weg: groovy-temples. (anmerkung: wir gehen der einfachheit halber davon aus, dass es eine reine sql-anwendung ist und kein orm-framework verwendet wird)

groovy besitzt ein template framework, und mit der SimpleTemplateEngine wird es uns leicht gemacht, vorlagen für die create-statements je datenbank-typ zu erstellen und damit die create-statements zu generieren.

vorbereitung

wir verwenden die groovy-programme aus unserem vorigen artikel (dsl mit groovy).
als erstes bereinigen wir unsere model-klassen und entfernen die create-funktionen.
zur besseren übersicht hier noch einmal die beiden klassen:

class TableModel {
   /**
    * Name der Tabelle
    */
   String name
   /**
    * Liste der Columns
    */
   ArrayList<ColumnModel> columns = new ArrayList<ColumnModel>()
}

class ColumnModel {
    /**
    * Tabelle, zu der diese Column gehört
    */
    TableModel table
    /**
    * name der column
    */
    String name
    /**
    * datentyp
    */
    String datatype
   /**
    * not null
    */
   boolean notnull
}

unsere templates

unser erstes template soll ein create-table-statement für eine MySql-datenbank sein, und so aussehen:

create table test (
    id int not null,
    name text
)
engine = InnoDB;

einem groovy-template werden daten übergeben, die innerhalb des templates verwendet werden können.
in unserem fall übergeben wir ein TableModel-objekt mit dem namen "table". (code siehe weiter unten).

im template selbst können wir groovy-code ausführen:
- ${xxx}: mit dieser syntax wird der wert, den xxx liefert, im template ausgegeben
- <% xxx %>: hiermit wird xxx als groovy-code ins template eingebettet
zum besseren verständnis verwenden wir in unserem ersten template beide varianten.

unser template ist folgendermaßen strukturiert:

create table ${table.name} (
  <% table.columns.eachWithIndex{ col, i -> %>
      ${col.name} ${col.datatype} <% if (col.notnull) { %>not null<% } %>
      <% if (i+1 < table.columns.size()) { %>,<% } %>
  <% } %>
)
engine = InnoDB;

nun die erklärung zu den einzelnen zeilen:
01: "create table" ist ein fixer text, mit "${table.name}" wird das "name"-property aus unserem table-objekt ausgegeben
02: hier wird mittels der "<% xxx %>"-syntax groovy-code eingebettet: es wird über alle columns im table-objekt iteriert. (mit index)
03: dieser teil wird für jede column ausgeführt und gibt column.name, column.type und "not null" wenn column.notnull == true
04: dieser teil dient nur dazu, um nach jeder außer der letzten column ein komma (",") auszugeben
05: das hier ist das ende der "table.columns.eachWithIndex { col, i -> " anweisung. d.h. der each-loop ist hier beendet
06 und 07: geben nur mehr einen fixen text aus.

das template-code wurde nur zwecks erklärungen in mehrere zeilen aufgeteilt. würden wir das template wie hier verwenden kämen zu viele zeilenumbrüche zustande, da alle zeilenumbrüche auserhalb von groovy-code ausgegeben werden.

daher zusammenfassend unser endgültiges MySql-template (gespeichert in der datei MySql.tpl):

create table ${table.name} (<% table.columns.eachWithIndex{ col, i -> %>
    ${col.name} ${col.datatype} <% if (col.notnull) { %>not null<% } %><% if (i+1 < table.columns.size()) { %>,<% } %><% } %>
)
engine = InnoDB;

analog können wir auch für Oracle ein template schreiben (Oracle.tpl):

create table ${table.name} (<% table.columns.eachWithIndex{ col, i -> %>
    ${col.name} ${col.datatype=="text"?"clob":col.datatype} <% if (col.notnull) { %>not null<% } %><% if (i+1 < table.columns.size()) { %>,<% } %><% } %>
);

hier ist folgender abschnitt erklärungsbedürftig:

${col.datatype=="text"?"clob":col.datatype}

da es in Oracle den datentyp "text" nicht gibt, wird statt "text" "clob" (character-large-object) als datentyp ausgegeben.
(anmerkung: in einer realen anwendung würde man den datentyp nicht als text sondern als enum definieren und jeweils den der datenbank entsprechenden datentyp ermitteln.)

SimpleTemplateEngine

wir haben unsere templates definiert, nun wollen wir sie auch verwenden:

dazu bietet uns groovy mit der SimpleTemplateEngine die einfachste möglichkeit.
hier die nötigen schritte:

import groovy.text.SimpleTemplateEngine

def engine = new SimpleTemplateEngine()

erzeugen einer engine-instanz

def template = engine.createTemplate(template)

erzeugen einer template-instanz. template kann dabei ein String, ein File, eine URL oder ein beliebiger Reader sein

template = template.build(model)

erzeugen anhand der im model übergebenen daten (als Map) das ergebnis

def result = template.toString()

liest das ergebnis als String aus

anmerkung: der einfachheit halber kann man die createTempate() und build() - schritte zusammenfassen:

def template = engine.createTemplate(template).build(model)

für unser beispiel ergibt sich damit:

import groovy.text.SimpleTemplateEngine

def builder = new TableBuilder();

def table = builder.table("test") {
column "id", datatype: "int", notnull: true
column "name", datatype: "text"
}

// Ausgabe
def engine = new SimpleTemplateEngine()

// Ausgabe für MySql
def template = engine.createTemplate(new File('MySql.tpl')).
make([table: table])
println "MySql-Statement:"
println template.toString()

// Ausgabe für Oracle
template = engine.createTemplate(new File('Oracle.tpl')).
make([table: table])
println "Oracle-Statement:"
println template.toString()

zuerst erstellen wir mit der dsl vom vorigen artikel eine tabellen-definition, die in der variablen "table" gespeichert wid.
danach erzeugen wir, wie oben beschrieben eine template-engine, und verwenden einmal das MySql-template und danach das Oracle-template.
als model übergeben wir der build-funktion die Map [table: table] (1. "table" ist die variable, wie sie im template verwendet wird, 2. "table" ist unsere lokale table-variable, die wir am anfang erzeugt haben.)
anstatt das ergebnis mit println an die konsole auszugeben könnten wir natürlich das ergebnis in .sql-dateien schreiben und es dann in der datenbank ausführen.

hier das erzielte ergebnis:

MySql-Statement:
create table test (
id int not null,
name text
)
engine = InnoDB;

Oracle-Statement:
create table test (
id int not null,
name clob
);

create table test (
id int not null,
name text
);

die source-files zu diesem artikel können sie hier downloaden.

danke für ihre aufmerksamkeit,
wir feuen uns über kommentare und anregungen.