Formulare im Bestellprozess

Benötigte Lesezeit: 7 Minuten


Einleitung

Der PepperShop bietet mit dem Bestellformular System einen einfach einzubindenden, dynamisch gestaltbaren und multilingual einsetzbaren Formulargenerator. Im Moment ist als Vorlage ein Formular fix implementiert – nach der Kasse und vor der Bestellübersicht.

Um dieses Modul verwenden zu können, werden HTML- und PHP-Kenntnisse vorausgesetzt.

Dateien und Einbindung

Dateien

shop/ Beschreibung
USER_BESTELLUNG_1.php -> bestellformular/ Bestellprozess des PepperShop / Einbindung
nach_kasse_form.php Formulartemplate
nach_kasse_elements.php Elemente des Formulars (sprachunabhängig)
nach_kasse_de.php Elementdefinitionen in der Sprache Deutsch
nach_kasse_en.php Elementdefinitionen in der Sprache Englisch
nach_kasse_fr.php Elementdefinitionen in der Sprache Französisch
nach_kasse_it.php Elementdefinitionen in der Sprache Italienisch

Einbindung in den Bestellprozess

Das einzige Formular, welches bis jetzt existiert, das ‘nach_kasse’-Formular, ist in der Datei shop/USER_BESTELLUNG_1.php eingebunden. Nach der Kasse und vor der Bestellübersicht. Die Einbindung erfolgt im Bereich darstellen == 2. Zu Beginn des Bereichs wird überprüft ob man von der Kasse her kommt oder vom Formular und weiter unten ist die Steuerung der Anzeige des Formulars oder der Bestellübersicht eingefügt. Die Anzeigesteuerung erfolgt über die in shop/util.php definierte Konstante NACH_KASSE_FORM. Standardmässig ist diese auf false (Boolean) gesetzt.

Formulartemplate(s)

Allgemeines

Wie im Kaptiel Dateien und Einbindung beschrieben, gibt es die Datei shop/bestellformular/nach_kasse_form.php, welches das HTML-Template des Formulars beinhaltet. Eigentlich nicht nur ein Template, sondern gleich mehrere:

Template Beschreibung
$form_strings['title'] Formulartitel (nicht HTML-<title>)
$form_strings['head'] Formularteil vor den Elementen
$form_strings['element'] Beschreibung eines Elements
$form_strings['begruendung'] Beschreibung der Begründung (falls verwendet)
$form_strings['footer'] Formularteil nach den Elementen

Die Templatedefinitionen erfolgen jeweils in einem PHP-String, welcher sich meistens über mehrere Zeilen hinweg erstreckt.

Variablen

Die Variablen, welche vom Formulartemplatesystem ersetzt werden, sind in geschweifte Klammern gefasst. Einige Beispiele: | Variablen | Beschreibung | | ——— | ——— | |{get_localized_text[formulartitel]}| Lokalisierte Variable (hier formulartitel) einlesen | |{selection}| innerhalb einer Elementedefinition gibt es keine Prefixes| |{special:name}| ‘special:’ = Prefix zur Unterscheidung|

Hidden Elements

Es gibt drei versteckte HTML Input-Elemente, welche für die Anzeigesteuerung verwendet werden, und welche somit auch immer vorhanden sein müssen:

<input type="hidden" name="von_bestellformular" value="true">
<input type="hidden" name="lang" value="'.$lang.'">
<input type="hidden" name="javascript_enabled" value="'.$javascript_enabled.'">

<form>-Tag

Etwas speziell ist natürlich auch immer der <form ... > HTML-Tag, weil dies die Verknüpfung des Formulars mit dem Bestellprozess aus Sicht des Formulars darstellt.

<form name="Bestellformular" action="'.$link_zum_check.'" method="post">

Wichtig ist hier die PHP-Variable $link_zum_check. Diese Variable enthält den Ort, wo das Formular die eingegebenen Kundendaten zur Verifikation sendet. In der Formulartemplatedatei sieht man ganz am Anfang PHP-Variablendefinitionen, eine davon ist dieser Link. Der Link zurück ist via HTML-Link realisiert, auch diese Variable ist am Dateianfang definiert.

Elementedefinition

Ein Element, resp. Seine Definition besteht aus zwei Teilen: Einem sparchabhängigen und einem unabhängigen Teil. Definiert wird der Name des Formulars, das Label (was wird dem Shopkunden angzeigt), die Art der Eingabeüberprüfung (text, exakt, gar nichts, …) und Optionen…

Sprachunabhängige Daten

Diese Daten werden in der Datei shop/bestellformular/nach_kasse_elements.php definiert. Ein Beispieleintrag sieht wie folgt aus:

$form_elements[0]['name']       = 'keine_medikamente_einnehmen';
$form_elements[0]['type']       = 'dropdown';

Wichtig ist, dass man die Nummer ([0]) pro Element erhöht, es dürfen weiter in der Nummerierung keine Lücken vorkommen.

Wie man sieht ist die Elementedefinition via PHP-Arrays realisiert.

  • 'name' Hiermit ist ein interner Name gemeint, am besten nur [a-zA-Z0-9_] verwenden
  • 'type' Von welchem Typ ist das Element: dropdown, text, radio, checkbox, textarea

Die Textfeldoptionen sind auch sprachunabhängig, werden aber im sprachabhängigen Teil erklärt, da dort die Typen der Eingabefelder beschrieben werden. Alle weiteren Einstellungen sind sprachabhängig und befinden sich in den entsprechenden Dateien.

Sparchabhängige Daten

Die von einer Sprache abhängigen Definitionen eines Elements befinden sich für jede Sprache in einer eigenen Datei. Die Namen der Dateien lassen sich leicht einer Sprache zuordnen, der Postfix ist jeweils der ISO-639-1 Code der Sprache, Format: Formularname_ISO-Code.php. Hier einige Beispiele:

  • nach_kasse_de.php Deutsch
  • nach_kasse_en.php Englisch
  • nach_kasse_fr.php Französisch
  • nach_kasse_it.php Italienisch

Die Sprachabhängigen Daten sind folgende, zum Teil Typ-abhängige Daten:

Daten Beschreibung
$form_elements[0]['name'] Name des Elements (interner Name)
$form_elements[0]['label'] angezeigter Name (Bezeichnung / Label)
$form_strings['element'] Fehlermeldung, wenn Check nicht bestanden wird
$form_elements[0]['check_type'] Art des Checks (z.B. @text, …)

Info: Die Bestellformulare verwenden per Default eine unabhängige Sprachensteuerung im PepperShop.

check_type – nach was soll geprüft werden?

Was ist der akzeptierte Wert/Wertebereich für dieses Element. Falls ein anderer Wert vom Shop-Kunden gegeben wird, zeigt ihm der PepperShop die in error_msg angegebene Fehlermeldung und er wird nochmals zum Formular zurück gesendet. | Arten des Cheks | Beschreibung | | ——— | ——— | |irgendwas| = genau dieser Text ist gefordert | |–irgendwas| = alles ist erlaubt, ausser Leerstring und der angegebene String| |@text| = irgend ein Text kann eingegeben werden, ein Leerstring wird als falsch erkannt | |@email| = Nur eine E-Mail Adresse wird akzeptiert (nur syntaktischer Check) | ||= Wenn man nichts angibt, so wird das Element nicht überprüft|

Nun folgen die vom Typ des Elements abhängigen Elementdefinitionen, es gibt zu jedem Typ ein Beispiel in der sprachabhängigen Definitionsdatei.

Ein Dropdown Menü besteht aus Optionen. Die Auswahl dieser Optionen wird dem Shop-Kunden angezeigt. Die Dropdown-Werte (dropdown_values) werden wiederum in einem Array von 0-n eingeordnet. Da ein Dropdown-Wert selbst aber noch aus mehreren Definitionen besteht, ist auch der Wert selber in einem Array definiert (array(…)). Der ‘value’ enthält den via POST übertragenen Wert, ‘label’ den angezeigten Namen. Die optionale Definition ‘option_color_style’ fasst einen in Hex codierten Farbwert, wie er im Web üblich ist mit vorangestelltem #. Die Farbwertzuweisung funktioniert nur im Internet Explorer richtig.

$form_elements[0]['dropdown_values'][0] = array('value'=>'Ja','label'=>'Ja'  ,'option_color_style'=>'#33CC33');
$form_elements[0]['dropdown_values'][1] = array('value'=>'Nein','label'=>'Nein', 'option_color_style'=>'#FF0000');

text

Ein Textfeld muss noch wissen, wie lange das Eingabefeld sein soll ‘size’ und wie seine maximale Länge aussehen soll – ‘maxlength’. Da das Textfeld keine sprachabhängigen Daten beinhaltet, wird die Definition in der Datei nach_kasse_elements.php gemacht:

$form_elements[0]['options']    = array('size'=>10,'maxlength'=>30);

radio

Damit man nicht noch weitere Feldnamen Definitionen im Programmcode abfragen muss, wurden hier in der v.1.0 API die dropdown_values verwendet. Man hat wieder ‘name’ und ‘label’ aber danach noch eine neue Definition ‘default’. Dieses Feld fasst einen boolschen Wert. Wenn es = true ist, so dient dieses Feld in der Radiobuttongroup als vorangewähltes Standardfeld. Pro Radiobuttongroup sollte es immer nur ein Feld geben, welches ‘default’ = true hat. Alle anderen Felder der Gruppe müssen ‘default’ = false haben.

In folgendem Beispiel sieht man gerade noch, wie man z.B. mittels einem einfachen <span>-Tag eine Farbinformation für das Label integrieren kann.

$form_elements[0]['dropdown_values'][0] = array('value'=>'Ja' ,'label'=>'<span 
style="color:#33CC33">Ja</span>'  ,'default'=>true);
$form_elements[0]['dropdown_values'][1] = array('value'=>'Nein','label'=>'<span 
style="color:#FF0000">Nein</span>','default'=>false);

checkbox

Hier gilt dieselbe Syntax wie für die Radiobuttongroup. Die ‘default’ Definition bedeutet hier, dass die Checkbox vorangewählt ist. Die Checkbox hat die Eigenschaft, dass sie ihren Wert nur überträgt, wenn sie aktiviert ist. Falls dies nicht der Fall ist, wird kein POST-Wert generiert und übertragen, dies nur zur Information.

$form_elements[0]['dropdown_values'] = array('value'=>'Ja','label'=>'<span
style="color:#33CC33">Ja</span>','default'=>true);

textarea

Mit einer Textarea kann auch grösserer Text abgefragt werden. Man muss hier die Anzahl Zeilen (‘rows’) und Spalten (‘cols’), sowie die Art des Zeilenumbruchs (‘wrap’) definieren. Die hier möglichen Werte sind dieselben wie in der HTML 4.01 Spezifikation.

$form_elements[0]['dropdown_values'] = array('rows'=>10,'cols'=>3,'wrap'=>'physical','default_value'=>'Mein Text');

Ablauf des Prozesses im Bestellvorgang

Theoretisch lassen sich an beliebigen Orten im Bestellprozess Formulare einbinden. Die jeweiligen Controller müssten dazu an den entsprechenden Orten im Handler des Bestellprozesses eingesetzt werden: shop/USER_BESTELLUNG_1.php.

Abbildung 1: Ablauf des Prozesses im Bestellvorgang

Wie werden die Checkresultate ausgewertet?

In der Datei shop/bestellformular/nach_kasse_elements.php können zu Beginn der Datei zwei Variablen definiert werden: $form_check_commit(wie sollen die Fehler interpretiert werden) und den Array $form_check_begruendung, in welchem die Details beschrieben werden, wenn die Interpretation ‘begruendung’ gewählt ist.

Interpretationsarten

Der Variable $form_check_commit kann man zwei verschiedene Werte angeben:

  1. einzeln: Der Check eines jeden einzelnen Elements muss erfüllt werden. Wenn auch nur einer nicht erfolgreich bestanden wird, kann der Kunde nicht weitergehen. Dies ist die Standard Formularauswertungsmethode.
  2. begruendung: Ist die Wahl auf ‘begruendung’ gefallen, so wird vom Kunden eine Begründung verlangt, wieso er bei den nicht bestandenen Checks auf diese Art gewählt hat. Wenn der Shopkunde keine Checks der Elemente die im Array $form_check_begruendung['exclude'] eingetragen sind, verletzt, so kann er passieren. Nach soviel Prosa nun der Checkablauf noch in einer Auflistung: 2.1 Ist mindestens ein Check nicht erfüllt, wenn ja: 2.2 Fehlermeldungen und das Begründungsfeld anzeigen. 2.3 Wenn der Shopkunde nun keine Begründung angibt und mindestens ein Check immer noch fehlerhaft ist, wird der Kunde daran gehindert weiterzufahren. 2.4 Wenn der Kunde alle Checks besteht oder zumindest eine Begründung angegeben hat, so wird noch ein weiterer Check gestartet: 2.5 Verletzt der Shopkunde noch einen Check, welcher von der Begründungsklausel ausgeschlossen ist (im Array exclude enthaltenes Element). Wenn ja, gilt für dieses Element die in 1) beschriebene ‘einzeln’ Interpretation – er muss diesen Check bestehen.
🌶️
🔥
🌶️