Formulaires dans le processus de commande

Introduction

PepperShop offre un générateur de formulaires facilement intégrable, dynamiquement concevable et multilingue avec le système de formulaire de commande. Actuellement, un formulaire est fixé comme modèle – après le paiement et avant l’aperçu de la commande.

Pour utiliser ce module, des connaissances HTML et PHP sont requises.

Fichiers et intégration

Fichiers

Intégration dans le processus de commande

Le seul formulaire qui existe jusqu'à présent, le formulaire ‘nach_kasse’, est intégré dans le fichier shop/USER_BESTELLUNG_1.php. Après le paiement et avant l’aperçu de la commande. L’intégration a lieu dans la zone darstellen == 2. Au début de la zone, il est vérifié si vous venez du paiement ou du formulaire, et plus bas, le contrôle de l’affichage du formulaire ou de l’aperçu de la commande est inséré. Le contrôle d’affichage se fait via la constante NACH_KASSE_FORM définie dans shop/util.php. Par défaut, celle-ci est définie sur false (Boolean).

Modèle(s) de formulaire

Général

Comme décrit dans le chapitre Fichiers et intégration, il y a le fichier shop/bestellformular/nach_kasse_form.php, qui contient le modèle HTML du formulaire. En fait, pas seulement un modèle, mais plusieurs :

Les définitions de modèle sont chacune dans une chaîne PHP, qui s'étend généralement sur plusieurs lignes.

Variables

Les variables qui sont remplacées par le système de modèle de formulaire sont encadrées par des accolades. Quelques exemples : | Variables | Description | | ——— | ——— | |{get_localized_text[formulartitel]}| Lire variable localisée (ici formulartitel) | |{selection}| dans une définition d'élément il n’y a pas de préfixes| |{special:name}| ‘special:’ = préfixe pour distinction|

Éléments cachés

Il y a trois éléments d’entrée HTML cachés qui sont utilisés pour le contrôle d’affichage et doivent donc toujours être présents :

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

Balise <form>

Quelque chose de spécial est bien sûr toujours la balise HTML <form ... >, car cela représente la connexion du formulaire avec le processus de commande du point de vue du formulaire.

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

Important ici est la variable PHP $link_zum_check. Cette variable contient l’emplacement où le formulaire envoie les données client saisies pour vérification. Dans le fichier de modèle de formulaire, vous pouvez voir les définitions de variables PHP au tout début, dont l’une est ce lien. Le lien retour est réalisé via lien HTML, cette variable est également définie au début du fichier.

Définition d'élément

Un élément, ou sa définition, consiste en deux parties : Une partie dépendante de la langue et une partie indépendante. Le nom du formulaire, l'étiquette (ce qui est affiché au client du magasin), le type de validation d’entrée (texte, exact, rien, …) et les options sont définis…

Données indépendantes de la langue

Ces données sont définies dans le fichier shop/bestellformular/nach_kasse_elements.php. Une entrée d’exemple ressemble à ceci :

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

Il est important d’augmenter le numéro ([0]) par élément, il ne doit pas y avoir de lacunes dans la numérotation.

Comme vous pouvez le voir, la définition d'élément est réalisée via des tableaux PHP.

• 'name' Cela fait référence à un nom interne, mieux vaut utiliser uniquement [a-zA-Z0-9_]
• 'type' Quel type est l'élément : dropdown, text, radio, checkbox, textarea

Les options de champ de texte sont également indépendantes de la langue, mais sont expliquées dans la partie dépendante de la langue, car les types de champs d’entrée y sont décrits. Tous les autres paramètres sont dépendants de la langue et se trouvent dans les fichiers correspondants.

Données dépendantes de la langue

Les définitions d’un élément qui dépendent d’une langue se trouvent dans un fichier séparé pour chaque langue. Les noms des fichiers peuvent facilement être assignés à une langue, le postfixe est le code ISO-639-1 de la langue, format : Formularname_ISO-Code.php. Voici quelques exemples :

• nach_kasse_de.php Allemand
• nach_kasse_en.php Anglais
• nach_kasse_fr.php Français
• nach_kasse_it.php Italien

Les données dépendantes de la langue sont les suivantes, données partiellement dépendantes du type :

Info : Les formulaires de commande utilisent par défaut un contrôle de langue indépendant dans PepperShop.

check_type – que doit-on vérifier ?

Quelle est la valeur/plage de valeurs acceptée pour cet élément. Si une valeur différente est donnée par le client du magasin, PepperShop lui affiche le message d’erreur spécifié dans error_msg et il est renvoyé au formulaire. | Types de vérifications | Description | | ——— | ——— | |irgendwas| = exactement ce texte est requis | |–irgendwas| = tout est autorisé, sauf chaîne vide et la chaîne spécifiée| |@text| = n’importe quel texte peut être saisi, une chaîne vide est reconnue comme fausse | |@email| = Seule une adresse e-mail est acceptée (vérification syntaxique uniquement) | |= Si vous ne spécifiez rien, l'élément n’est pas vérifié|

Suivent maintenant les définitions d'éléments qui dépendent du type d'élément, il y a un exemple pour chaque type dans le fichier de définition dépendant de la langue.

dropdown

Un menu déroulant consiste en options. La sélection de ces options est affichée au client du magasin. Les valeurs déroulantes (dropdown_values) sont à nouveau arrangées dans un tableau de 0-n. Puisqu’une valeur déroulante elle-même consiste en plusieurs définitions, la valeur elle-même est également définie dans un tableau (array(…)). La ‘value’ contient la valeur transmise via POST, ‘label’ le nom affiché. La définition optionnelle ‘option_color_style’ contient une valeur de couleur codée en hexadécimal, comme c’est courant sur le web, avec un # précédent. L’assignation de valeur de couleur ne fonctionne correctement que dans Internet Explorer.

$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

Un champ de texte doit également savoir combien de temps le champ d’entrée doit être ‘size’ et quelle doit être sa longueur maximale – ‘maxlength’. Puisque le champ de texte ne contient pas de données dépendantes de la langue, la définition est faite dans le fichier nach_kasse_elements.php :

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

radio

Pour que vous n’ayez pas à interroger d’autres définitions de noms de champs dans le code du programme, les dropdown_values ont été utilisés ici dans l’API v.1.0. Vous avez ‘name’ et ‘label’ à nouveau, mais ensuite une nouvelle définition ‘default’. Ce champ contient une valeur booléenne. Si elle = true, ce champ sert de champ par défaut présélectionné dans le groupe de boutons radio. Par groupe de boutons radio, il ne devrait toujours y avoir qu’un seul champ qui a ‘default’ = true. Tous les autres champs du groupe doivent avoir ‘default’ = false.

Dans l’exemple suivant, vous pouvez voir comment vous pouvez intégrer des informations de couleur pour l'étiquette en utilisant une balise <span> simple, par exemple.

$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

La même syntaxe s’applique ici que pour le groupe de boutons radio. La définition ‘default’ signifie ici que la case à cocher est présélectionnée. La case à cocher a la propriété qu’elle ne transmet sa valeur que lorsqu’elle est activée. Si ce n’est pas le cas, aucune valeur POST n’est générée et transmise, c’est juste pour information.

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

textarea

Avec une zone de texte, un texte plus grand peut également être interrogé. Ici, vous devez définir le nombre de lignes (‘rows’) et de colonnes (‘cols’), ainsi que le type de saut de ligne (‘wrap’). Les valeurs possibles ici sont les mêmes que dans la spécification HTML 4.01.

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

Flux du processus dans le processus de commande

Théoriquement, des formulaires peuvent être intégrés à n’importe quel emplacement dans le processus de commande. Les contrôleurs respectifs devraient être insérés aux emplacements correspondants dans le gestionnaire du processus de commande : shop/USER_BESTELLUNG_1.php.

Comment les résultats de vérification sont-ils évalués ?

Dans le fichier shop/bestellformular/nach_kasse_elements.php, deux variables peuvent être définies au début du fichier : $form_check_commit (comment les erreurs doivent être interprétées) et le tableau $form_check_begruendung, dans lequel les détails sont décrits si l’interprétation ‘begruendung’ est choisie.

Types d’interprétation

La variable $form_check_commit peut recevoir deux valeurs différentes :

1. einzeln : La vérification de chaque élément individuel doit être remplie. Si même un seul n’est pas réussi, le client ne peut pas continuer. C’est la méthode d'évaluation de formulaire standard.
2. begruendung : Si le choix tombe sur ‘begruendung’, le client est invité à fournir une justification quant à la raison pour laquelle il a choisi cette façon pour les vérifications échouées. Si le client du magasin ne viole aucune vérification des éléments entrés dans le tableau $form_check_begruendung['exclude'], il peut passer. Après tant de prose, le flux de vérification à nouveau dans une liste : 2.1 Au moins une vérification n’est-elle pas remplie, si oui : 2.2 Afficher les messages d’erreur et le champ de justification. 2.3 Si le client du magasin ne fournit pas de justification et qu’au moins une vérification est encore défectueuse, le client est empêché de continuer. 2.4 Si le client réussit toutes les vérifications ou a au moins fourni une justification, une autre vérification est lancée : 2.5 Le client du magasin viole-t-il encore une vérification qui est exclue de la clause de justification (élément contenu dans le tableau exclude). Si oui, l’interprétation ‘einzeln’ décrite en 1) s’applique à cet élément – il doit réussir cette vérification.

Aide supplémentaire

Avez-vous des questions ou avez-vous besoin d’assistance ? Avez-vous des exigences particulières ou souhaitez-vous une solution individuelle pour votre système ? Notre équipe de support se fera un plaisir de vous aider. Les prestations de support sont facturées au temps passé au tarif de CHF 195.- / heure. Voici comment nous joindre :

• E-Mail : support@glarotech.ch
• Téléphone : +41 (0)71 923 08 58
• Heures d’ouverture : Lundi – Vendredi I 08:00h – 12:00h I 13:30h – 17:00h

Autres pages utiles

• FAQ (Foire aux questions)
• Modules & Fonctions
• Interfaces