Philipps Blog

I just finished my latest improvements to the legacy version of my counter script.
I just added the lookup for ISPs and added dynamic scaling for the axis legend.
I will now going forward to change the whole system to a more sophisticated software, e.g. using a Datawarehouse approach. The first version of the Data-Model is finished.

So from the old version (that was just some plain tables, flowing around)

I created a new Model with more Tables, connected to each other. Basically i devided the Model into a basic Fact (Count) and some Dimensions (for every Value):

With my current values (around 22k Facts), i have already to limit the facts that are queryed from the Datebase. I wrote a short script to migrate all old Datasets to the new Data-Model.

Um eine Play!-Anwendung zu testen, welche HTTP-Basic-Auth verlangt ist es notwendig, die Standard-Datei ApplicationTest.java anzupassen:
Verändert werden muss die Test-Methode testThatIndexPageWorks():

Aus

    @Test
    public void testThatIndexPageWorks() {
        Response response = GET("/");
        assertIsOk(response);
        assertContentType("text/html", response);
        assertCharset(play.Play.defaultWebEncoding, response);
    }

Wird:

    @Test
    public void testThatIndexPageWorks() {
        Request request = FunctionalTest.newRequest();
        request.user = "test";
        request.password = "test";
        request.url = "/";
        Response response = GET(request, "/");
        assertIsOk(response);
        assertContentType("text/html", response);
        assertCharset("utf-8", response);
    }

Wobei User = test und Passwort = test.
Bei allen weiteren Test-Methoden verfährt man analog, oder erstellt sich eine Factory-Methode für den Request.

Es ist möglich, eine Play!-Anwendung sehr einfach in eine WAR-Struktur zu übertragen und in einen Application-Server zu deployen.
Dies ist recht gut unter Deployment options in der Play!-Dokumentation recht gut erklärt. Was hier allerdings verschwiegen wird ist, wie man den notwendigen Context beim Routing konfiguriert. (Der Context ist der Pfad der Anwendung, welcher standardmäßig vom Namen des WAR-Archivs abgeleitet wird, oder per Descriptor konfiguriert wird) – heißt das Archiv testapp.war ist der Context /testapp.

Innerhalb einer Play!-App muss der Context sowohl in der Config Datei, als auch im Routing definiert werde:

application.conf

...
context=testapp
...

Danach lässt sich in der routes Datei der Context in die Routen konfigurieren:

# Routes
# This file defines all application routes (Higher priority routes first)
# ~~~~

%{ context = play.configuration.getProperty('context', '') }%

# Home page
GET     ${context}                                        Application.index
GET     ${context}/                                       Application.index

# Map static resources from the /app/public folder to the /public path
GET     ${context}/public/                                staticDir:public
GET     ${context}/Users/like/{uid}                       Users.like
GET     ${context}/Users/{uid}/show                       Users.show
...

Im letzten Post wurde eine kurze Beschreibung in den Aufbau einer Play! Anwendung gegeben.
Nachfolgend soll eine einfache kleine Anwendung erstellt werden.

Die Anwendung soll die Links von verschiedenen Webseiten als Bookmarks speichern.
Hierzu benötigen wir ein Model für ein Bookmark:

package models;

import java.util.Date;
import javax.persistence.Entity;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
import play.data.validation.Required;
import play.db.jpa.Model;
@Entity
public class Bookmark extends Model {
    @Temporal(TemporalType.DATE)
    public Date createdAt;
    @Required
    public String title;
    @Required
    public String url;
    public Bookmark(){
        createdAt = new Date();
    }
}

Wie der geneigte Java-Entwickler auf den ersten Blick erkennen mag, handelt es sich um ein normales JPA Model. Einzig der public Accessor für die einzelnen Attribute erscheint befremdlich.
Zur Beruhigung sei gesagt, dass hier eine der Vereinfuchungen von Play! in Aktion tritt. Zur Laufzeit werden hier die notwendigen Getter/Setter erstellt (diese können aber auch selbst definiert werden), sowie der direkte Zugriff auf die Attribut verhindert. (vgl. http://www.playframework.org/documentation/1.2.3/model#properties ).

Weiterhin unbekannt ist hier die Anotation @Required. Play! unterstützt hier eine on-Model-Validation. Das Attribut wird als Required gekennzeichnet, es ist also notwendig, dass diese Attribut zu Persistierung gesetzt ist. Wie die Validierung im Controller verwendet wird, dazu später mehr.

Wie einige vielleicht ja schon wissen beschäftige ich mich jetzt schon seit einige Zeit mit dem recht neuen, aber mittlerweile immer bekannterem, Java-basiertem Web-Framework Play!. Anders als bei vielen neueren Frameworks wird nicht durch die Mittel einer dynamischen Sprache, sondern durch die Vereinfachung der bestehenden Sprachmittel von java versucht die Entwicklung einer Web-Anwendung zu beschleunigen und zu vereinfachen. Das bedeuten unter anderem das konsequente Weglassen der bisherigen Package-Struktur. Auf der anderen Seite werden altbewährte Bibliotheken aus der Java-Welt verwendet (z.B. JPA, Hibernate, Lucene, usw.). Da es eine ganze Menge an englischsprachigen Tutorials gibt und ich mir schon länger vorgenommen habe in einem kleinen Tutorial die grundlegenden Züge einer Play!-Anwendung zu beschreiben, wird dieser Text mal wieder in Deutsch sein .

Play verwendet – wie fast alle aktuellen Web-Frameworks ein MVC-Pattern,

So sollte es einem Entwickler (egal ob Ruby, Java oder Python), der mit der aktuellen Techniken vertraut ist, relativ leicht fallen, sich mit dem typischen Aufbaue einer Play-Anwendung zurecht zu finden.

Die Installation des Frameworks ist auf der Seite des Projektes gut erklärt. Neben einer aktuellen JVM sind keine weiteren Vorausetzungen zu erfüllen. Wichtig ist nur, dass das “play” Script im aktuellen Pfad erreichbar ist.

Nachfolgend möchte ich eine kleine Bookmark-Verwaltung erstellen.

Mit einem

# play new bookmarks

Wird die Grundstruktur einer Play-Anwendung erstellt.

Das oberste Verzeichnis enthält alle Modelle, Controller und Views der Anwendung (dazu später mehr). Unter “conf” befinden sich folgende Dateien:

- application.conf: Konfiguration der Anwendung – Art der DB, Caching, Konfiguration der Module
- dependencies.yml: Play unterstützt Module, die verschiedene Funktionen kapseln können. Seit Version 1.2 werden die Abhängigkeiten einer Anwendung durch Einträge in dieser Datei gesetzt.
- messages: Diese Datei wird für die Internationalisierung einer Anwendung benötigt (amerikanische Strings). Um eine neue Sprache hinzu zu fügen legt man eine neue Datei mit dem entsprechenden Ländercode an – z.B. messages.de für deutsch.
- routes: Play ermöglicht es, durch Einträge in dieser Datei, das Routing der Anwendung zu beeinflussen. Es erfolgt ein Mapping von URL auf Controller-Actions (dazu später mehr).

Das lib Verzeichnis kann verwendet werden um Java Libs zu verwenden, die nicht als Modul für Play! zur Verfügung stehen. Alle Jars im libs-Verzeichnis werden automatisch in den Classpath der Anwendung aufgenommen.

Das test Verzeichnis enthält die die Testdateien (Junit-/Selenium-Tests sowie ew. Fixures mit Testdaten).

Nach dem ersten Start der Anwendung werden noch zwei weitere Verzeichnisse erstellt:
Ein tmp-Verzeichnis (welches die kompilierten Klassen, sowie Caching Dateien enthält) und ein
db-Verzeichnis, welches bei der Wahl einer h2 Datenbank, die entsprechende Datenkbankdatei enthält (auch dazu später mehr).

Dies soll für die ersten 5 Minuten genügen .

Wie einige vielleicht ja schon wissen beschäftige ich mich jetzt schon seit einige Zeit mit dem recht neuen, aber mittlerweile immer bekannterem, Java-basiertem Web-Framework Play!. Anders als bei vielen neueren Frameworks wird nicht durch die Mittel einer dynamischen Sprache, sondern durch die Vereinfachung der bestehenden Sprachmittel von java versucht die Entwicklung einer Web-Anwendung zu beschleunigen und zu vereinfachen. Das bedeuten unter anderem das konsequente Weglassen der bisherigen Package-Struktur. Auf der anderen Seite werden altbewährte Bibliotheken aus der Java-Welt verwendet (z.B. JPA, Hibernate, Lucene, usw.). Da es eine ganze Menge an englischsprachigen Tutorials gibt und ich mir schon länger vorgenommen habe in einem kleinen Tutorial die grundlegenden Züge einer Play!-Anwendung zu beschreiben, wird dieser Text mal wieder in Deutsch sein .
Play verwendet – wie fast alle aktuellen Web-Frameworks ein MVC-Pattern. So sollte es einem Entwickler (egal ob Ruby, Java oder Python), der mit der aktuellen Techniken vertraut ist, relativ leicht fallen, sich mit dem typischen Aufbaue einer Play-Anwendung zurecht zu finden.
Die Installtion des Frameworks ist auf der Seite des Projektes gut erklärt. Neben einer aktuellen JVM sind keine weiteren Vorrausetzungen zu erfüllen. Wichtig ist nur, dass das “play” Script im aktuellen Pfad erreichbar ist.
Nachfolgend möchte ich eine kleine Bookmark-Verwaltung erstellen.
Mit einem

# play new bookmarks

Wird die Grundstruktur einer Play-Anwendung erstellt.

• app:
  Das oberste Verzeichnis enthält alle Modelle, Controller und Views der Anwendung (dazu später mehr).
• Unter “conf” befinden sich folgende Dateien:
  • application.conf:
    Konfiguration der Anwendung – Art der DB, Caching, Konfiguration der Module
  • dependencies.yml:
    Play unterstützt Module, die verschiedene Funktionen kapseln können. Seit Version 1.2 werden die Abhängigkeiten einer Anwendung durch Einträge in dieser Datei gesetzt.
  • messages:
    Diese Datei wird für die Internationalisierung einer Anwendung benötigt (amerikanische Strings). Um eine neue Sprache hinzu zu fügen legt man eine neue Datei mit dem entsprechenden Ländercode an – z.B. messages.de für deutsch.
  • routes:
    Play ermöglicht es, durch Einträge in dieser Datei, das Routing der Anwendung zu beeinflussen. Es erfolgt ein Mapping von URL auf Controller-Actions (dazu später mehr).
• Das lib Verzeichnis kann verwendet werden um Java Libs dort zu speichern, die nicht als Modul für Play! zur Verfügung stehen. Alle Jars im libs-Verzeichnis werden automatisch in den Classpath der Anwendung aufgenommen.
• Das test Verzeichnis enthält die die Testdateien (Junit-/Selenium-Tests sowie ew. Fixures mit Testdaten).

Nach dem ersten Start der Anwendung werden noch zwei weitere Verzeichnisse erstellt:

• Ein tmp-Verzeichnis (welches die kompilierten Klassen, sowie Caching Dateien ernhält) und ein
• db-Verzeichnis, welches bei der Wahl einer h2 Datenbank, die entsprechende Datenkbankdatei enthält (auch dazu später mehr).

Dies soll für die ersten 5 Minuten genügen .