Zum Hauptinhalt springen
Sobald ein Käufer sich anmelden kann, hat er nicht mehr eine Adresse, sondern einen Vorrat davon: eine Rechnungsadresse und beliebig viele gespeicherte Lieferadressen. Das Shopsystem nennt diesen Zustand “multiple Adressen”. Er verteilt sich über fünf Templates, und auf jedem wird etwas anderes gebraucht. Diese Seite ist der Wegweiser durch diese fünf Templates. Sie sagt, welches Template welche Aufgabe hat, welche Tags dort stehen müssen und welche Zustände es zu bedienen gibt. Beschrieben sind die einzelnen Tags jeweils auf der Seite ihres Präfixes, die hier verlinkt ist. Wegweiser: Rechnungs- und multiple Lieferadressen abfragen · Referenz: Abschnitt Templates

Die fünf Templates

Alle fünf tragen Sie in der Shopkonfiguration shop.config im Abschnitt <Templates> ein. Die Dateinamen sind Konvention, nicht Vorschrift. Maßgeblich ist der Parameter im Abschnitt <Templates>. Mehrere Tags dieser Seite prüfen intern, auf welchem Template sie stehen, und gelten als ungültiges Tag, wenn sie woanders auftauchen.

Rechnungsadresse und Lieferziel auf einer Seite

Das Template CombinedAddress erledigt beides in einem Formular: die Eingabe der Rechnungsadresse und die Entscheidung, wohin geliefert werden soll.
WS-DelivAddr_list arbeitet ausschließlich auf dem Template CombinedAddress. Auf jedem anderen Template gilt es als ungültiges Tag.

Was ST-MultipleData wirklich prüft

Die bisherige Beschreibung setzt ST-MultipleData mit “angemeldet” gleich und ST-SingleData mit “nicht angemeldet”. Das stimmt nur auf zwei der Templates. Der Grund für die Sonderregel auf der Bestellübersicht ist, dass dort nicht Adressen, sondern Zahlungsdaten mehrfach vorliegen können. Dieselben beiden Tags bedienen beide Fälle. Setzen Sie sie deshalb immer mit Blick auf das Template, auf dem sie stehen.
{!ST-SingleData} greift derzeit in genau denselben Fällen wie {ST-SingleData}. Die negative Klammerung ist damit wirkungslos. Verwenden Sie stattdessen {ST-MultipleData}, das den Gegenfall korrekt abdeckt.

Das Lieferziel über Radiobuttons

Statt einer einzelnen Selectbox können Sie das Lieferziel über eine Gruppe von Radiobuttons anbieten und die Liste der gespeicherten Adressen nur dann einblenden, wenn sie gebraucht wird. Dafür gibt es eine eigene Tag-Familie mit immer demselben Bauplan. Für <Ziel> gibt es fünf Werte.
Sie sind die fünfte Option der Gruppe und der Einstieg in die Verteilung auf mehrere Lieferadressen. Die radioselected-Tags geben als Einzel-Tag checked mit einem führenden Leerzeichen aus. Sie können sie deshalb direkt hinter das vorangehende Attribut setzen. Als Klammerung greifen sie bei der jeweils gewählten Option, so wie oben bei der Auswahlliste.

Die neue Adresse speichern

Gibt der Käufer eine neue Lieferadresse ein, kann er sie für das nächste Mal speichern lassen. Damit legt der Käufer die neue Adresse zugleich als Standard-Lieferadresse fest, statt sie nur zu speichern. Beide Feldnamen sind im Shopsystem fest vergeben. Nehmen Sie sie immer aus dem Tag und schreiben Sie sie nicht von Hand, sonst erkennt der Shop die Eingabe beim Absenden nicht.

Zum Ändern einer gewählten Adresse

BT-DelivAddr_select_change liefert den Feldnamen der Schaltfläche, mit der die in der Auswahlliste gewählte Lieferadresse zum Bearbeiten geöffnet wird. Beschrieben ist das Tag bei BT- (Schaltflächen).

Die Rechnungsadresse im Kundenkonto ändern

Auf dem Template AddressManage gibt es nur einen Zustand: das Formular.
Ohne die Klammerung mit A-Edit arbeitet der Eingabebereich nicht. Sie ist keine Formsache, sondern schaltet den Bearbeitungszustand erst frei.

Die Lieferadresse im Bestellablauf anzeigen

Das Template DelivAddress zeigt die Adresse, an die geliefert wird.
Die Klammerung {WS-DelivAddr} greift nur, wenn der Käufer im Bestellablauf tatsächlich eine Lieferadresse gewählt hat. Der Einzel-Tag ~WS-DelivAddr~ wird dagegen immer ausgegeben. Klammern Sie den Block deshalb, sonst steht bei einer Lieferung an die Rechnungsadresse eine leere Überschrift auf der Seite.Dieses Tag gibt es im Shopsystem nicht, weder hier noch auf der Verwaltungsseite. Für die Liste der fehlerhaften Eingaben verwenden Sie die Einzelprüfungen der Familie MSG-DelivAddr_InputError_…, für alles Übrige MSG-DelivAddr_Notify. Die einzelnen Felder melden ihre Fehler ohnehin über ihre eigenen _error-Suffixe.

Die Lieferadressen verwalten

Das Template DelivAddressManage ist die einzige Seite mit mehreren Zuständen. Welcher gilt, entscheidet das Shopsystem, und drei Klammerungen trennen sie im Template.

Die Tags dieser Seite

MSG-DelivAddr_saved und MSG-DelivAddr_deleted fehlen in der bisherigen Beschreibung dieser Seite. Mit ihnen melden Sie den Erfolg einer Aktion zurück, statt den Käufer kommentarlos auf die Übersicht zu schicken.
Setzen Sie D-DeleteNoConfirmLink nicht direkt in die Übersicht. Der Link löscht ohne Rückfrage. Der Weg über D-DeleteConfirmLink in den Bereich D-ConfirmDelete ist der einzige, bei dem der Käufer die Löschung noch abbrechen kann.

Aus dem Bestellablauf oder aus dem Kundenkonto

Dieselbe Seite wird von zwei Stellen aus aufgerufen, und sie muss danach an verschiedene Orte zurückführen. D-Mode_Order und D-Mode_Manage unterscheiden das.
Die beiden Klammerungen prüfen nicht, woher der Käufer kam, sondern wohin es nach der Aktion weitergeht. D-Mode_Order greift, wenn die hinterlegte Folgeseite die Adresseingabe oder die Bestellübersicht ist, D-Mode_Manage in jedem anderen Fall. In der Praxis läuft das auf dieselbe Unterscheidung hinaus, die beiden Zweige schließen einander immer aus.

Die Einstiege im Kundenkonto

Einzelne Felder statt Blockpositionierung

WS-AddrFields und WS-DelivAddrFields geben den kompletten Satz Eingabefelder aus. Wenn Sie das Layout selbst bestimmen wollen, positionieren Sie stattdessen jedes Feld einzeln. Dafür gibt es zu jedem Adressfeld ein festes Raster von Suffixen, bei der Rechnungsadresse unter A-, bei der Lieferadresse unter D-.
Das Raster und die Liste der verfügbaren Felder stehen bei den beiden Präfixen.
Das Feld UserDescr der Lieferadresse gibt die Blockpositionierung nicht mit aus. Wenn der Käufer seinen Adressen eigene Bezeichnungen geben soll, müssen Sie dieses eine Feld immer von Hand positionieren, auch wenn Sie sonst mit WS-DelivAddrFields arbeiten.
Die Auswahllisten für Anrede, Titel, Land und Geburtsdatum füllt das Shopsystem selbst. Bei fehlerhaften Eingaben hängt es an die Klassennamen automatisch das Suffix _error an, und die Klammerungen für fehlerhafte Eingaben greifen auch dort.
Die benutzerdefinierten Auswahllisten UserDefList-1 bis UserDefList-3 sind veraltet und werden nicht mehr unterstützt. Verwenden Sie sie in neuen Templates nicht mehr.

Verwandte Themen