Impressum![]() Frank Seitz Wassermühlenstr. 2 25436 Uetersen E-Mail: fs ![]() Tel.: +49-176-78243503 ![]() ![]() ![]() ![]() ![]() ![]() Alle Artikel Inhaltsverzeichnis Rechtliche Hinweise Code auf GitHub Code auf meta::cpan KategorienAbonnieren |
Sonntag, 13. Juli 2025Mojolicious: Prüfung von ParameterwertenEine 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,
],
Freitag, 20. August 2021Mojolicious: Webanwendung auf Entwicklungsrechner einrichtenWir entwickeln auf Basis von Mojolicious eine Webanwendung NAME und möchten, dass diese
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:
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 nohupnohup morbo ~/opt/NAME/bin/PROGRAM --listen http://*:PORT --watch ~/opt/NAME --verbose >~/var/log/NAME.log 2>&1 & Links
Samstag, 14. Mai 2016Ein Plugin für Mojolicious schreibenÜ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:
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. BeispielAls 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
(Seite 1 von 1, insgesamt 3 Einträge)
|
KalenderStatistikLetzter Artikel:
13.07.2025 17:56 160 Artikel insgesamt
Links
|