Benutzerformulare
Benutzerformulare im Shop sollten immer über die Funktion \brandbox\shop\user\engine::mapUserToForm
erstellt werden. Das führt zu Erweiterbarkeit durch die Datenmodellierung und einem einheitlichen Verarbeiten der Formulare.
Konfiguration (Kunde)
Durch Hinzufügen einer Formularmaske zu der Kunden-Tabelle können weiter Felder zu den Benutzerformularen hinzugefügt werden.
In der Feldkonfiguration kann definiert werden in welchen Formularen das Feld sichtbar sein soll. Aktuell verfügbare Formulare für die Benutzerformulare im Shop: shopRegister
, shopCheckout
, shopPersonal
, shopCheckoutAnonymous
, shopCheckoutRegistration
.
JSON-Konfiguration
{
"whitelist": [
"shopRegister",
"shopCheckout",
"shopPersonal"
]
}
Es können hier auch die schon bestehenden Felder der Kundendatensatz verändert, bzw konfiguriert werden. Dazu muss nur ein Formularfeld angelegt werden, welches das Zielfeld ersetzt und zu der Formlarmaske hinzugefügt wird. Auch dann greift die Konfiguration der Whitelist. So kann auch eine Sortierung der Felder im Formular erreicht werden oder die Feldeinschenkungen verändert werden.
Konfiguration (shopOrder)
Durch Hinzufügen einer Formularmaske zu der Bestellung-Tabelle können weiter Felder zu den Benutzerformularen hinzugefügt werden.
In der Feldkonfiguration kann definiert werden welcher Felder in Bestellungsprozess sichtbar sein soll.
Dadurch bekommen wir neue Felder beim Bestellungsprozess.
Beim erfolgreicher Bestellung bekommen wir neue Felder auch beim Bestellungsansicht & Bestellungsbestätigung E-Mail und in Delivery Invoice.
Verwendung im Code
Whitelist Key | User-Engine Konstante |
---|---|
|
|
|
|
|
|
|
|
|
|
Beispiel: Formular "Mein Konto" "Persönliche Daten"
$shopUser = $this->getUser();
$form = $this
->getEngineUser()
->mapUserToForm($shopUser, user\engine::FORM_KEY_PERSONAL)
;
$form->identification = $identification;
$form->formTag = true;
$form->links = $links;
$form->actions = $actions;
$form->notifications = $notificationBlocks;
$form->attributes = $attributes;
return $form;
Beispiel: Validierung "Persönliche Daten"
use brandbox\component\mapping;
use brandbox\component\validator;
// .. class definition ...
use validator\validatorTrait;
// .. onSave -> $params = $httpParams ..
$shopUserEntity = $this
->getEngineUser()
->getShopUser()
;
$whitelistedFields = $this
->getEngineComponentForm()
->getListedColumnsByEntity($shopUserEntity, user\engine::FORM_KEY_PERSONAL)
;
// Important: Only allow whitelisted fields to be changed
$map = mapping\lib\map\mapEntityAdvanced::get($whitelistedFields);
/** @var user\lib\entity\shopUser $validationUser */
$validationUser = $this
->map()
->from($params)
->withMap($map)
->to($shopUserEntity)
;
return $this->validateValue(
$validationUser,
$this->getApplicationLanguage(),
function() use ($params, $validationUser) {
$this->updateUser($validationUser);
}
);
Events
Interface: \brandbox\shop\user\lib\event\userFormEventInterface
Adapter: \brandbox\shop\user\lib\event\adapter\userFormEventAdapter
Methode | Eingabe | Rückgabe | Beschreibung |
---|---|---|---|
|
|
| Bietet die Möglichkeit die Felder und die Benutzerformulare zu erweitern oder modifizieren. $userFormKey kann dazu verwendet werden, zu unterscheiden in welchem Formular das Event abgeschickt wurde. Siehe Whitelist Keys. |
|
|
| Bietet die Möglichkeit columnIdentifiers zu definieren, deren Violation ignoriert werden darf. Beispielweise könnte ein Kunde mit der Kundengruppe A nicht den Zwang haben einen Vornamen bei der Registrierung angeben zu müssen aber der Kunde mit der Gruppe B schon. |
|
|
| Wird im Bestellprozess Schritt "Persönliche Daten" aufgerufen nachdem der Schritt validiert wurde, valide ist, die httpParameter auf shopSessionCheckout übertragen wurden, und bevor shopSessionCheckout gespeichert wird. Wird beim Speichern der Benutzerformulare aufgerufen bevor der Benutzer gespeichert wird. Fallbeispiele: Benutzer registriert sich ( |
|
|
| Wird beim Speichern der Benutzerformulare aufgerufen nachdem nachdem |