Eine Seite, die Daten verändert, wie z.B. eine Speichernseite, die die Felder eines Formulars gepostet bekommt, um deren Werte auf einer Datenbank zu speichern, sollte alle Daten vor dem Speichern akribisch prüfen.

Als Helper definieren wir uns zwei Methoden.

Erstens Methode getParam(), die den Wert eines Parameters abfragt und zusammen mit dem Parameternamen liefert:

$self->helper(
    getParam => sub {
        my ($self,$field) = @_;
        my $val = $self->param($field);
        return ($val,$field);
    }
);

Zweitens Methode returnTo(), die wir im Fehlerfall nutzen, um die Fehlermeldung, den Namen des fehlerauslösenden Feldes und sämtliche Formularwerte an die Formularseite zurück zu kommunizieren:

$self->helper(
    returnTo => sub {
        my ($self,$page,$msg,$field) = @_;

        my $url = Quiq::Url->href($page,
            navMsg => $msg,
            navField => $field,
            -append => $self->req->params->to_string,
        );
        $self->redirect_to($url);

        return;
    }
);

Damit können wir leicht eine universelle Fehlerbehandlung auf der Speichernseite realisieren. Beispiel (Speichern eines Belegs):

if ($aktion eq 'Speichern') {
    !! Prüfe die Formulardaten

    my $a = Quiq::Assert->new;

    my ($field,$val,$msg);
    ($val,$field) = $self->getParam('blg_betrag');
    if (!$a->isNumber($val)) {
        $msg = "FEHLER: Ungültiger Betrag ,$val'";
    }
    ...weitere Prüfungen...

    if ($msg) {
        $self->returnTo('/belegFormular',$msg,$field);
        return;
    }

    ...führe die Operation aus...
}

Auf der Formularseite nehmen wir die Information entgegen, initialisieren das bearbeitete Objekt mit den vorhergehenden Formulardaten, stellen die Fehlermeldung dar und setzen den Fokus auf das Feld mit dem beanstandeten Wert.

Entgegennahme der Information:

my $field = $self->param('navField') // 'blg_datum';
my $msg = $self->param('navMsg') // '';
if ($msg =~ /FEHLER/) {
    $blg->initFromCgi($self);
}

Darstellung der Fehlermeldung auf der Seite (wir nutzen zwei CSS-Klassen, auch eine für die Darstellung von normalen Meldungen):

$h->tag('div',
    -ignoreIf => !$msg,
    class => $msg =~ /FEHLER/i? 'fehler': 'meldung',
    $msg
),

Den Fokus setzen wir zum Schluss unter Nutzung von jQuery:

ready => q~
    var e = $('#__FIELD__');
    $(e).focus();
~,
placeholders => [
    __FIELD__ => $field,
],

Wir entwickeln auf Basis von Mojolicious eine Webanwendung NAME und möchten, dass diese

• in ihrer vorgegebenen Entwicklungsumgebung abläuft
• beim Booten automatisch gestartet wird
• permanent läuft
• sich bei Codeänderungen automatisch neu lädt
• fürs Debugging eine eigene Logdatei schreibt
• interaktiv gestoppt und gestartet werden kann
• wenn nicht benötigt, auf unbestimmte Zeit deaktiviert werden kann

Diese Anforderungen lassen sich leicht mit morbo als Webserver in Kombination mit der Prozesssteuerung systemd realisieren. Hierbei ist morbo der Entwicklungs-Webserver von Mojolicious und systemd die fundamentale Prozesssteuerung vieler Linux-Systeme (ein moderner Ersatz für init). Ein zusätzlicher Webserver wie nginx oder apache wird nicht benötigt.

Die Unit-Datei NAME.service, mit der wir den Service gegenüber systemd definieren, ist recht einfach (Erläuterungen zur einzig interessanten Zeile ExecStart siehe im Folgenden):

[Unit]
Description=DESCRIPTION
After=network.target

[Service]
Type=simple
User=USER
ExecStart=bash -lc "morbo PROGRAM --listen http://*:PORT --watch SOURCEDIR --verbose >LOGFILE.log 2>&1"

[Install]
WantedBy=multi-user.target

Hierbei ist:

DESCRIPTION

Eine kurze, einzeilige Beschreibung des Service.

USER

Der Name des Unix-Users, unter dessen Rechten der Prozess ausgeführt wird, denn wir möchten, dass der Prozess im Kontext eines bestimmten Users läuft. Wenn nicht angegeben, ist root der User.

PROGRAM

Pfad/Name des Programms, das die Webanwendung ausführt. Wir rufen die Anwendung nicht direkt auf, sondern via bash -lc "...", damit sie in der Umgebung des Users USER läuft.

PORT

Port, auf dem die Anwendung läuft. Wegen * ist sie auf allen Interfaces erreichbar, d.h. sie ist zugreifbar via localhost:PORT oder HOSTNAME:PORT.

SOURCEDIR

Wurzelverzeichnis, im dem sich die Quellen der Anwendung befinden. Dieses Verzeichnis überwacht morbo in Bezug auf Änderungen. Verteilen sich die Quellen über mehrere Verzeichnisse, kann die Option --watch mehrfach angegeben werden.

LOGFILE

Pfad/Name der Logdatei, in die der Webserver (morbo) die Zugriffe und Fehlermeldungen protokolliert. Die Logdatei wird beim Booten neu begonnen, womit auf einfache Weise vermieden wird, dass sie unbegrenzt wächst, historische Information wird in der Entwicklungsumgebung ja nicht benötigt.

Die systemd Unit-Datei kopieren wir in das Verzeichnis /etc/systemd/system. Mit folgender Kommandofolge machen wir die Anwendung dauerhaft und sofort verfügbar:

# systemctl daemon-reload # Konfigurationsänderung systemd bekannt machen
# systemctl enable NAME   # Service aktivieren, so dass die Anwendung beim Booten gestartet wird
# systemctl start NAME    # Service sofort verfügbar machen (ohne Rebooten zu müssen)

Den Status überprüfen wir mit:

# systemctl status NAME

Die Anwendung kann jederzeit gestoppt und gestartet werden mit:

# systemctl stop NAME
# systemctl start NAME

Der automatische Start beim Booten lässt sich ab- und anschalten mit:

# systemctl disable NAME
# systemctl enable NAME

Die Liste aller vorhandenen Unit-Files und ihres jeweiligen Status:

# systemctl list-unit-files

Vorschlag für eine Verzeichnisstruktur im Homeverzeichnis von USER:

~/etc/systemd/NAME.service # Unit-Datei, per Symlink referenziert von /etc/systemd/system aus, Qwner ist USER
~/var/log/NAME.log         # Logdatei
~/opt/NAME/...             # Projektverzeichnis

Die konkrete Kommandozeile zum Starten der Anwendung lautet dann:

morbo ~/opt/NAME/bin/PROGRAM --listen http://*:PORT --watch ~/opt/NAME --verbose >~/var/log/NAME.log 2>&1

nohup

nohup morbo ~/opt/NAME/bin/PROGRAM --listen http://*:PORT --watch ~/opt/NAME --verbose >~/var/log/NAME.log 2>&1 &

Links

• Mojolicious
• Mojolicious Cookbook (mit einer ähnlichen Unit-Datei für systemd)
• morbo
• systemd - Homepage
• systemd - Debian Wiki
• systemd/Services - Debian Wiki

Über die Plugin-Schnittstelle kann Mojolicious oder eine Mojolicious-Applikation um jede denkbare Funktionalität erweitert werden. Die Plugin-Schnittstelle ist sehr einfach gehalten. Denn sie gibt nur vor, wie eine Funktionalität zum System hinzugefügt wird, nicht jedoch, um welche Art von Funktionalität es sich handelt.

Die Implementierung eines Mojolicious-Plugin erfolgt in zwei Schritten:

1. Durch Ableitung von Mojolicious::Plugin wird eine Subklasse - die Plugin-Klasse - gebildet.

2. In der Plugin-Klasse wird die Methode register() implementiert.

In der Dokumentation zur Basisklasse Mojolicious::Plugin wird die Implementierung so beschrieben:

package Mojolicious::Plugin::MyPlugin;
use Mojo::Base 'Mojolicious::Plugin';

sub register {
    my ($self, $app, $conf) = @_;

    # Magic here! :)
}

Der Aufwand der Plugin-Implementierung besteht natürlich darin, den mit

# Magic here! :)

bezeichneten Teil mit Leben zu füllen.

Ist das Plugin implementiert, wird es durch einen einzigen Aufruf zur Applikation hinzugefügt:

$app->plugin(MyPlugin => \%config);

Der analoge Aufruf unter Mojolicious::Lite:

plugin MyPlugin => \%config;

Hierbei ist %config ein Hash mit Schlüssel/Wert-Paaren - typischerweise als Hash-Literal angegeben - durch den das Plugin konfiguriert wird. Ist keine Konfigurierung des Plugin nötig, kann das Argument weggelassen werden.

Beispiel

Als einfaches Beispiel implementieren wir ein Plugin Hello, das bei jedem hereinkommenden Request die Zeichenkette 'Hello' und die IP-Adresse des Aufrufers ins Log ausgibt. Dies erreichen wir, indem wir in der Methode register() einen before_routes-Handler aufsetzen, der genau dies tut.

package Mojolicious::Plugin::Hello;
Mojo::Base 'Mojolicious::Plugin';

sub register {
    my ($self, $app, $conf) = @_;

    $app->hook(before_routes=>sub {
        my $c = shift;
        $c->app->log->debug('Hello '.$c->tx->remote_address);
    });

    return;
}

Das Plugin wird durch

$app->plugin('Hello');

oder im Falle von Mojolicious::Lite durch

plugin 'Hello';

in der Applikation aktiviert. Eine Konfiguration ist bei den Aufrufen nicht angegeben, da das Plugin keine Konfigurierungsmöglichkeit vorsieht.

Links zu Mojolicious

• Homepage des Mojolicious-Projekts
• Quellen und Dokumentation auf meta::cpan
• Repository auf GitHub
• Mojolicious Plugins auf meta::cpan