DCA: Eigene Validierung für Felder

[Jayster]

Hallo liebe Contao Community,

ich wüßte gerne, ob und wie man beim DCA eine eigene Validierung für bestimmte Felder machen kann.

Ich erstelle gerade eine Erweiterung, bei der Nutzer bestimmte Zeitslots reservieren können (manche wissen das bestimmt schon aus meinen anderen Threads ;-). Diese Reservierung soll nicht nur im Frontend erfolgen, sondern auch über das Backend möglich sein. D.h. Backendbenutzer können über den DCA Einträge anlegen und bearbeiten. Damit da kein Blödsinn gemacht wird, bräuchte ich für bestimmte Felder eine eigene Validierung. Zum Beispiel habe ich ein Feld für die Uhrzeit mit folgendem Code:

'teeTime' => array(
  'label' => &$GLOBALS['TL_LANG']['tl_tee_time_reservation_bookings']['teeTime'],
  'exclude' => true,
  'sorting' => true,
  'flag' => 11,
  'inputType' => 'text',
  'default' => time(),
  'eval' => array(
    'mandatory' => true,
    'rgxp' => 'time',
   ),
   'sql' => "int(10) unsigned NOT NULL default '0'"
)

Die Validierung erfolgt also über eine rgxp vom Typ time. Das ist für mich aber noch nicht spezifisch genug. Zum einen sind nur bestimmte Zeiten uchbar, zum anderen gibt es für jeden Zeitpunkt auch nur eine festgelegte Anzahl an maximal möglichen Buchungen. Ich müsste also noch kontrollieren, dass die Zeit buchbar und noch nicht vollbelegt ist, und im Fehlerfall eine entsprechende Fehlermeldung ausgeben.

Meine Frage dazu: wie kann ich eine eigene Validierung für meine Felder implementieren? Es müsste ja wahrscheinlich irgendwie über den on_submit callback geschehen.

[the_scrat]

Hi,

das hier sollte dir helfen:

https://docs.contao.org/books/api/ex...tomRegexp.html

Du brauchst nur deinen eigenen rgxp erstellen und dieser wird dann automatisch beim Speichern validiert. Ein Callback ist hier (soviel ich weiß) nicht nötig.

[joe]

Moin das geht über den addcustomregexp hook: https://docs.contao.org/books/manual...ddcustomregexp

Im Anhang findest du ein Beispiel Modul basierend auf der Contao Dokumentation. Schau es dir mal an

[Jayster]

Danke, Scrat. EDIT: Danke auch an Joe, der geantwortet hat, während ich diesen Post verfasst habe.

Das ist schon mal sehr gut um das Format für die Zeit genau festzulegen (z.B. nur 00, 20 und 40 als Minuten).

Aber hilft mir das auch bei meinem Problem mit dem Überbuchen? Hier muss ja noch in der DB kontrolliert werden, dass noch genug Plätze frei sind (hierfür existiert in meinem Model schon eine entsprechende Methode). Ich sollte vielleicht noch dazu sagen, dass das nicht nur von der gewählten Zeit abhängt, sondern auch von der Anzahl der Plätze, die in einem anderen Feld des DCA gewählt wird. Zudem ist auch die Auswahl der Zeitpunkte durch das beschränkt, was im Parent-Element festgelegt wurde. Hier kann man z.B. angeben, dass Zeiten von 8-18 Uhr reserviert werden können. Ich glaube, hier komme ich mit einem regulären Ausdruck alllein nicht weiter. Wie gesagt: die Methoden zur Überprüfung existieren schon, ich muss sie "nur noch" beim DCA aufrufen und entsprechende Fehlermeldungen ausgeben können.

[Jayster]

@joe: Die angehängte Erweiterung würde ich mir gern anschauen, leider kriege ich beim Anklicken vom Forum die Fehlermeldung "Ungültige Angabe: Anhang".
EDIT: Häh, jetzt hat's doch noch funktioniert. Passt also ;-)

[joe]

Hm komisch. Ich hab es mal auf Github gestellt: https://github.com/may17/ContaoAddCustomRegexpExample

[cliffparnitzky]

Moin,
du kannst auch einen `save_callback` für deine Feld implementieren: https://docs.contao.org/books/api/dc...ield-callbacks

Dort dann deine Custom Prüfung codieren und mittels `throw Exception(...)` im Fehlerfall ne Meldung geben.

Gruß, Cliff

[the_scrat]

Er könnte auch den onsubmit_callback nutzen, aber genau für solche validierungssachen gibt es eben ja diesen hook.

@ screenart innerhalb des HOOKs kannst du auf alle deine Methoden/Funktionen zugreifen die zur Validierung notwendig sind.

[Jayster]

Danke für eure Hilfe. Ich habe es jetzt mal mit dem save_callback gemacht, das funktioniert sehr gut.

Zusätzlich wollte ich noch eine neue rgxp erstellen um schon vor dem save_callback die richtige Schreibweise der Uhrzeit zu testen (und um die Custom Regexp auszuprobieren ;-). Allerdings müsste ich mich, wenn ich nicht die Contao rgxp 'time' verwende, wohl selber um die Umwandlung zwischen timestamp und menschenlesbarer Uhrzeit kümmern. Das wird nämlich automatisch erledigt, wenn ich 'rgxp' => 'time' eintrage. Hat jemand eine Idee, wie ich das machen könnte? Im Prinzip müsste ich ja im on_load callback den tstamp aus der Datenbank in menschenlesbare Zeit umwandeln und beim on_save callback wieder zurück in einen timestamp. Das kommt mir etwas aufwendig vor. Wisst ihr vielleicht einen besseren Weg?

[fiedsch]

[...] den tstamp aus der Datenbank in menschenlesbare Zeit umwandeln und beim on_save callback wieder zurück in einen timestamp [...]

Schau Dir dazu mal die Date-Klasse an (system/modules/core/library/Contao/Date.php) und dort speziell die Methoden
parse() und den Kosntruktor. Beispiele:

$timestamp = time();

$dateString = \Date::parse($GLOBALS['TL_CONFIG']['datimFormat'], $timestamp);

$date = new Date($dateString, $GLOBALS['TL_CONFIG']['datimFormat']);
$timestamp = $date->dateToUnix(); 

[Jayster]

Danke, dass ist nützlich um die Zeiten entsprechend umzuwandeln. Aber ich komme wohl nicht darum herum, dass jeweils beim on_load und on_save Callback zu machen, oder?

Ich habe auch noch ein anderes Problem: wenn man einen neuen Eintrag im DCA anlegt, wird dieser sofort in der Datenbank gespeichert (auch wenn man nicht den 'speichern' Button drückt). Fehlerhafte Eingaben werden ebenfalls direkt in der Datenbank gespeichert, auch wenn die Validierung korrekt die Fehlermeldungen anzeigt. Wenn man auf den 'zurück' Button klickt, wird der Eintrag wieder aus der Datenbank entfernt. Das ist für mich ein Problem, da ich die Reservierungen auch im Frontend ausgebe. D.h. während ein Backend Benutzer einen neuen Eintrag anlegt, werden im Frontend auch falsche Daten ausgegeben, bis die Bearbeitung des Eintrags abgeschlossen ist. Gibt es eine Möglichkeit, das zu verhindern?

[the_scrat]

Naja, du könntest dir ein bestimmtes zusätzliches Feld erstellen, welches ausgefüllt wird, sobald du final gespeichert hast. Und dieses Feld frägst du im Frontend ab und solange dieses Feld nicht gesetzt ist wird der Datensatz halt nicht ausgegeben.

[Jayster]

Danke, das ist eine gute Idee. Vielleicht geht es sogar ohne das zusätzliche Feld. Ich habe gesehen, dass in der DB das Feld 'tstamp' so lange 0 ist, bis der Eintrag korrekt (also mit erfolgreicher Validierung der anderen Felder) gespeichert wurde. Ich könnte also 'tstamp != 0' abfragen.

[the_scrat]

Naja, aber tstamp wird auch dann gesetzt, wenn es fehlerhafte Einträge gibt und genau das wolltest du doch vermeiden, oder?

[Jayster]

Also so wie ich das gerade beobachtet habe, wird der tstamp erst gesetzt, wenn es keine Fehler mehr gibt. Wenn ich zum Beispiel eine nicht buchbare Uhrzeit eintrage oder kein Mitglied angebe, bleibt der tstamp 0.

Natürlich ist es nicht ganz so schön, das Feld tstamp für etwas einzusetzen, wofür es eigentlich nicht gedacht ist. Da es aber (so scheint es mir zumindest im Moment) genau das macht, was ich brauche, werde ich es mal so probieren. Ich poste dann hier, ob es eine gute Idee war oder nicht.

[Jayster]

Ich habe es jetzt doch mit einem zusätzlichen Feld 'published' gelöst. Aus zwei Gründen:
1. Es ist schöner, wenn man im Code schreiben kann 'published=1'. Das ist auch ohne Kommentar verständlich, bei 'timestamp!=0' müsste man noch erklären, warum man das so macht.
2. Es könnte sein, dass sich das Verhalten von 'tstamp' irgendwann ändert. Bei einem von mir definierten Feld habe ich dieses Problem nicht.

[Jayster]

Nicht wundern: mein Nutzername hat sich von 'screenart' auf 'Jayster' geändert.

[Jayster]

So, das klappt jetzt alles ganz gut.

Ich hätte da noch einen nützlichen Hinweis für alle, die etwas ähnliches machen wollen. Wenn man für die Validierung im DCA die Anzahl der besetzten Slots zählt, sollte man den aktiven Record nicht mitzählen. Sonst passiert folgendes: Es gibt pro Zeit maximal 4 Slots. Ein Eintrag hat alle 4 Slots reserviert. Diese Reservierung soll nun z.B. auf 3 Slots geändert werden. Zählt man die Reservierungen des aktuellen Eintrags mit, schlägt diese Änderung fehl (mit der eigens definierten Fehlermeldung "Für diese Zeit sind keine Slots mehr frei"). Es wurden ja alle reservierten Slots gezählt, auch die die gerade geändert werden sollten. Daher: id des aktiven Records ausschließen.