CustomerVendor-Controller: Daten in Neu-Anzeige bei Fehler beibehalten
RDBO hat das Verhalten, dass bei einem neuen, noch nicht gespeicherten Objekt die Methoden zum Hinzufügen von Relationship-Objekten (z.B. in 1:n-Beziehnungen wie $customer->add_contacts(…)) beim danach erfolgenden Auslesen der Beziehung nicht zurückliefert. Das heißt, dass Folgendes der Fall ist:
my $customer = SL::DB::Customer->new; $customer->add_contacts(SL::DB::Contacts->new); print scalar(@{ $customer->contacts || [] }); # Das hier gibt 0 aus
Existiert das Objekt hingegen schon, dann klappt das normal. Das Problem kann man umgehen, indem man beim Anlegen des neuen Objektes die Beziehungen explizit auf eine leere Array-Referenz setzt, damit der in RDBO enthaltene Check an der Stelle greift.
Das betrifft den Workflow, wenn man Daten in den benutzerdefinierten Variablen eingibt, auf Speichern drückt und kivitendo dann wegen eines fehlgeschlagenen Checks die Maske erneut anzeigt.
CustomerVendor-Controller: Daten in Neu-Anzeige bei Fehler beibehalten
RDBO hat das Verhalten, dass bei einem neuen, noch nicht gespeicherten
Objekt die Methoden zum Hinzufügen von Relationship-Objekten (z.B. in
1:n-Beziehnungen wie $customer->add_contacts(…)) beim danach erfolgenden
Auslesen der Beziehung nicht zurückliefert. Das heißt, dass Folgendes
der Fall ist:
my $customer = SL::DB::Customer->new;
$customer->add_contacts(SL::DB::Contacts->new);
print scalar(@{ $customer->contacts || [] }); # Das hier gibt 0 aus
Existiert das Objekt hingegen schon, dann klappt das normal. Das Problem
kann man umgehen, indem man beim Anlegen des neuen Objektes die
Beziehungen explizit auf eine leere Array-Referenz setzt, damit der in
RDBO enthaltene Check an der Stelle greift.
Das betrifft den Workflow, wenn man Daten in den benutzerdefinierten
Variablen eingibt, auf Speichern drückt und kivitendo dann wegen eines
fehlgeschlagenen Checks die Maske erneut anzeigt.