Extension:Page Forms/Input types/fr

Cette page couvre les différents types d'entrées possibles pour Page Forms, ainsi que les paramètres et les autres adaptations qu'il est possible de leur appliquer.



text
Type d'entrée par défaut; correspond à l'entrée text de HTML.

Paramètres spéciaux :

textarea
Correspond à la balise HTML.

Paramètres spéciaux :



text et textarea avec autocomplétion
Ces deux entrées sont les alias de combobox et de tokens dans la version 5.0, et sont affichées de la même manière que les type d'entrée  et , et peuvent être configurées de la même manière, mais ils fournissent en plus l'autocomplétion - sur une ou plusieurs valeurs. Voir les sections sur l' initialisation des paramètres et l' autocomplétion ci-dessous sur la manière de personnaliser l'autocomplétion.

combobox
Le type d'entrée combobox fournit une interface de style liste déroulante : une entrée qui fonctionne comme un champ régulier avec autocomplétion, mais avec une icône supplémentaire de flèche vers le bas, comme celle d'un dérouleur, pour permettre à l'utilisateur de voir d'un seul coup toutes les valeurs possibles. Il est implémenté en utilisant la bibliothèque JavaScript Select2.

Paramètres spéciaux :

tokens
Ce type d'entrée réalise le marquage des valeurs du champ en plaçant chacune d'elles dans un bloc (un token) pour en faire autant d'unités séparées au lieu d'une chaîne de caractères. Ces jetons peuvent ensuite être réarrangés. Comme pour combobox, cette entrée est implémentée en utilisant la bibliothèque JavaScript Select2.

Paramètres spéciaux :

Par défaut, les tokens apparaissent comme une entrée sur une seule ligne et sont listés verticalement si nécessaire, au fur et à mesure que des valeurs supplémentaires sont ajoutées. Dans certains cas vous voudrez que cette entrée apparaisse plus grande qu'une rangée lorsqu'elle commence, afin qu'elle soit plus évidente pour les utilisateurs qui voudront la dérouler. Pour faire cela avec une entrée unique, ajoutez un paramètre  à la balise du champ, tel que , puis ajoutez à MediaWiki:Common.css quelque chose similaire à :

Si vous voulez que cela s'applique à toutes les entrées tokens du wiki, ajoutez à MediaWiki:Common.css quelque chose similaire à :

radiobutton
L'entrée radiobutton correspond aux boutons radio du HTML. Elle affiche un ensemble de valeurs parmi lesquelles l'utilisateur ne peut en choisir qu'une.

Par défaut, la valeur du premier bouton radio est None, permettant ainsi à l'utilisateur de choisir la valeur vide. Pour empêcher d'afficher « None », vous devez indiquer que le champ est « mandatory », et choisir une des valeurs autorisées en tant que valeur par défaut dans le champ « default= ».

dropdown
L'entrée dropdown correspond à la balise HTML &lt;select&gt;. Elle affiche une liste déroulante de valeurs, parmi lesquelles l'utilisateur ne peut en sélectionner qu'une.

checkboxes
Les entrées checkboxes affichent des cases à cocher permettant à l'utilisateur de choisir tout nombre de valeurs. S'il y a plus qu'un nombre donné de cases à cocher, les liens « Selectionner tous » et « Selectionner aucun » vont automatiquement apparaître au-dessus de l'ensemble des cases, pour permettre automatiquement aux utilisateurs de les cocher toutes ou aucune. Ce nombre est fixé par la variable, dont la valeur par défaut est 10, bien qu'elle puisse être changée dans LocalSettings.php.

Paramètres spéciaux :

listbox
L'entrée listbox correspond à la balise HTML &lt;select&gt;, avec l'attribut with the « multiple » ajouté. Cela affiche une liste verticale d'options, dans laquelle l'utilisateur peut faire une sélection multiple.

Paramètres spéciaux :

tree
Le type d'entrée tree accepte des données hiérarchiques présentées sous forme d'arbre, où toutes les valeurs ont soit des boutons radio soit des cases à cocher à leur côté, en fonction du champ qui est soit multiple, soit mono élément. Les valeurs peuvent provenir d'un arbre des catégories du wiki, ou être déclarées manuellement dans la définition du formulaire.

Comment cette entrée sait-elle qu'elle peut accepter une ou plusieurs valeurs et avoir des boutons radio ou bien des cases à cocher ? Elle regarde simplement si le champ dans le modèle est défini comme supportant une liste de valeurs (en utilisant #arraymap) ou pas. Ce contrôle n'est pas parfait, quoique. Si l'entrée tree affiche des boutons radio au lieu de cases à cocher, ajoutez simplement le paramètre « |list » à la balise du champ dans la définition du formulaire, pour déclarer la liste.

En fonction de la source des valeurs, vous devez spécifier l'un de ces deux paramètres supplémentaires.


 * - définit le nom de la catégorie qui se trouve à la racine de l'arbre.
 * - déclare la structure complète de l'arbre; vous devez utiliser les puces de style wikicode pour définir le niveau de profondeur.

Le paramètre structure vous permet d'obtenir l'équivalent de ceci :

Vous pouvez également initialiser les paramètres facultatifs suivants :


 * - définit la hauteur de la boîte en pixels, dans laquelle l'arborescence est affichée
 * - définit la largeur de la boîte en pixels, dans laquelle l'arborescence est affichée
 * - définit le délimiteur utilisé quand le champ contient une liste de valeurs. Par défaut une virgule ','.
 * - cache le nom de la catégorie de la racine.
 * - définit le nombre de niveaux de l'arborescence affichés au début. Par défaut 10.

Vous pouvez voir un formulaire d'exemple utilisant ce type d'entrée ici.



Pour les noms de catégorie
Si vous utilisez le type d'entrée « tree » pour afficher une arborescence de catégorie, notez que cette entrée va afficher uniquement les noms des catégories sélectionnées mais sans le préfixe de l'espace de noms Category: ; donc si vous voulez qu'il s'affiche aussi sur la page, le modèle devra l'ajouter.

Si le champ spécifie plusieurs catégories, et que le modèle utilise #arraymap pour le proposer, l'appel à #arraymap devrait ressembler à :

...en d'autres termes, vous devez spécifier le paramètre « delimiter » final pour #arraymap, et en faire un espace, un blanc ou quelque chose de similaire, pour éviter d'imprimer, les virgules entre les balises des catégories.

checkbox
Une case à cocher unique, utilisée pour les valeurs booléennes.

Paramètres spéciaux :

date
Cette entrée contient trois éléments séparés, pour l'année, le mois et le jour.

datetime
L'entrée « datetime » est similaire à l'entrée « date » mais inclut des entrées supplémentaires pour les heures, les minutes, les secondes et l'indication AM/PM.

Paramètres spéciaux :

year
year est le texte qui représente seulement l'année dans le champ d'une date.

datepicker
« datepicker » permet à l'utilisateur de choisir une date avec l'aide d'une fenêtre séparée comportant un calendrier basé sur JavaScript.

Special parameters:

The starting day of the week (e.g., Saturday, Sunday or Monday) is set based on the language of the wiki; it unfortunately cannot be set independently of the language. If your wiki is in English and you would like weeks in the calendar input to start on Monday instead of Sunday (which is the default), you can do that by setting your wiki's language to be "en-gb" instead of "en".

datetimepicker
« datetimepicker » est un type d'entrée basé sur Javascript très similaire à « datepicker » et contenant des fenêtres pour sélectionner à la fois la date et l'heure. Par défaut. Ses paramètres sont tous ceux de « datepicker » plus les suivants :

rating
Le type d'entrée « rating » affiche un ensemble d'étoiles pour permettre à l'utilisateur de formuler une évaluation.

Paramètres spéciaux :

googlemaps, leaflet, openlayers
Les types d'entrée « googlemaps » « leaflet » et « openlayers » vous permettent d'afficher une carte pour obtenir la valeur des coordonnées en utilisant respectivement les services Google Maps, Leaflet ou OpenLayers.

Si vous utilisez l'entrée googlemaps, vous aurez probablement besoin d'avoir une clé d'accès à l'API Google Maps, et la déclarer dans LocalSettings.php via le paramètre , pour que l'entrée puisse s'afficher.

Vous pouvez aussi définir (facultatif) ces paramètres pour les types d'entrées suivants :

Le type d'entrée leaflet permet un paramètre supplémentaire :

Le type d'entrée googlemaps vous permet d'entrer une addresse pour localiser les coordonnées plus facilement. Mais si le formulaire contient déjà un ou plusieurs champs pour entrer l'addresse, alors il est possible que l'utilisateur doive la rentrer deux fois - une fois pour enregistrer les données actuellement, et une seconde fois pour les localiser. Pour éviter que les utilisateurs aient à faire ce double travail, il est possible de faire en sorte que tous les champs d'addresse fournissent leur valeur directement à la carte lorsque le point est recherché. Vous pouvez faire cela en utilisant le paramètre  - voir ici.

Tous ces formats par défaut, dépendent du code JavaScript externe. Néanmoins, simplement en installant l'extension OpenLayers, il est possible de faire que le format openlayers utilise du code JavaScript local.

Désactivation
Notez bien que tous ces types d'entrée envoient les données de votre wiki (c'est à dire les données qui sont le résultat des requêtes), aux services externes. Ce sont les seules parties de code de Page Forms qui envoient les données à l'extérieur, autres que l'autocomplétion sur des valeurs externes, bien que cette dernière demande une configuration supplémentaire pour fonctionner. Si vous avez un wiki privé et que vous êtes très préoccupé de ne pas voir vos données s'extérioriser, vous pouvez ajouter le code suivant dans LocalSettings.php :

Ceci va bloquer l'utilisation de tout service externe par Page Forms - ce qui à cet instant signifie interdire ces trois types d'entrée.

regexp
Le type d'entrée regexp n'est pas réellement un type d'entrée, mais plutôt la possiblité d'afficher l'entrée réelle (le plus souvent de type text) en appliquant une validation supplémentaire basée sur une expression régulière. Voir ici l'explication plus détaillée de ce type d'entrée et de ses paramètres.



Types d'entrée autorisés selon le type de données
Lorsque vous utilisez Cargo ou Semantic MediaWiki, chaque type de données défini possède un type d'entrée par défaut et également selon le cas, une longueur d'entrée par défaut. En plus, certains types de données sont gérés d'une manière particulière quand le champ contient une liste de valeurs délimitées au lieu d'une seule valeur.

Voici les types par défaut et les autres types d'entrée permis pour chaque type de données, et cela pour des valeurs seules :

Voici les types d'entrée par défaut et les autres types d'entrée autorisés pour les listes délimitées d'un type de donnée particulier :



Déclaration des valeurs et correspondances
Certains types d'entrée fournissent à l'utilisateur des valeurs prédéfinies. Cela, peut être des valeurs parmi lesquelles l'utilisateur doit choisir (comme avec le type d'entrée ), ou des valeurs servant de guide à l'utilisateur (comme avec , bien que là aussi ces options peuvent être rendues obligatoires en ajoutant le paramètre  ).

Dans les deux cas, l'ensemble des paramètres pour spécifier les valeurs affichées à l'utilisateur est presque le même. Voici les paramètres pour la balise du champ pouvant être utilisés dans tous les cas :

Il y existe quelques options supplémentaires pour les entrées basées sur l'autocomplétion; voir ci_dessous.

Correspondance
Il est possible que vous observiez que l'ensemble des valeurs affichées à l'utilisateur est différent de l'ensemble de valeurs affichées actuellement dans le wikicode de la page. Si les valeurs sont des noms de pages, et que ces pages ont un display title déclaré et différent du vrai nom de la page, alors par défaut le formulaire va afficher le display title à la place du nom de page. Si vous le souhaitez, vous pouvez voir affiché le nom de la page elle-même, en ajoutant ceci dans LocalSettings.php :

Vous pouvez activer d'autres correspondances similaires en utilisant les paramètres suivants :

Example 1: mapping template
Par exemple, un formulaire peut contenir une balise de champ telle que :

Le modèle sur Template:StatusLabel peut ensuite contenir quelque chose comme :

Vous pouvez ensuite utiliser le même mapping template pour afficher le libellé de la valeur sur les pages régulières qui ne sont pas des formulaires. Dans le modèle qui contient le champ status, vous pourriez avoir ceci :

Example 2: Cargo-based mapping
Let's say that, in a company, every employee is assigned an employee ID. In the wiki, the page about each employee has as its name the employee ID. There are also pages about projects, and within each project page is a "Project members" field, which holds a list of employee IDs. In the "Project" form, in the "Project members" input, you want people to enter in employees' actual names, but have the employee IDs show up on the page. You could do that with the following field tag:

Now, what if the name of each employee page is not the employee ID (nor their real name) but rather a randomly-assigned name, like "Employee 12345"? Then you could do the mapping using the additional "mapping cargo value field" parameter, like this:

Autocomplétion
Quatre des types d'entrée (, , plus   et   pour les versions antérieures à la 5.0) utilisent l'autocompletion — dès que l'utilisateur commence à taper, l'entrée affiche une liste déroulante des completions possibles.

Si un champ représente une propriété de Semantic Mediawiki, ou un champ Cargo, de type «  », l'autocomplétion sera activée par défaut — le champ se complétera automatiquement avec le nom de toutes les pages qui utilisent déjà cette propriété ou ce champ. Pour tous les autres types, il n'existe pas d'autocomplétion par défaut, mais vous pouvez réaliser cela simplement en déclarant ce type d'entrée comme étant l'un des quatre possèdant l'autcomplétion.

Vous pouvez manuellement activer l'autocomplétion d'un champ sur l'ensemble des valeurs à partir d'une propriété SMW, un champ Cargo, une catégorie, un espace de noms, un concept, ou en définissant une liste manuelle, en utilisant un des paramètres « values ... » - voir ci-dessus.

Vous pouvez aussi appliquer l'autocomplétion basée sur des valeurs hors du wiki, contenues dans des pages web, des bases de données, des fichiers, etc.; voir ci-après pour les différentes manières de réaliser cela.

Si un champ est désigné comme contenant des valeurs multiples, l'autocomplétion prendra en charge par défaut les valeurs multiples : après avoir saisi une valeur et placé le délimiteur, une nouvelle autocomplétion va recommencer avec la valeur suivante. Vous pouvez spécifier manuellement qu'un champ possède l'autocomplétion sur les valeurs multiples, en ajoutant le paramètre « list » à la définition du champ. Vous pouvez également spécifier le délimiteur de cette liste de valeurs, en utilisant le paramètre « delimiter=... » (par défaut une virgule ',').

Par défaut, le nombre maximum de possibilités d'autocomplétion qu'un champ peut offrir est 1000 ; cela pour des raisons de performance. Pour modifier ce nombre, changer la valeur de  en LocalSettings.php.

Désactivation
Vous pouvez désactiver l'autocomplétion si elle a été déclarée par défaut sur un champ, en indiquant que le type d'entrée est simplement « text » ou « textarea ».



Autocomplétion distante
L'ensemble des valeurs possibles d'autocomplétion d'un champ est par défaut contenu directement dans la page HTML du formulaire, dans une déclaration JavaScript. Par soucis de performance, il y existe une limite sur le nombre de valeurs placées sur la page; par défaut la limite est fixée à 100. Après que ce nombre est atteint, l'autocomplétion distante est réalisée là où elle s'applique, via un appel Ajax vers le serveur, en fonction de ce que l'utilisateur a entré. Ce type d'autocomplétion est plus lent, mais il permet beaucoup plus de résultats d'autocomplétion.

Vous pouvez changer la valeur par défaut en ajoutant à LocalSettings.php un code similaire à :



Correspondance de chaque caractère
Par défaut, l'autocomplétion dans Page Forms détecte le début de chaque mot de l'ensemble des valeurs possibles. Vous pouvez par contre modifier l'autocomplétion afin qu'elle coïncide avec chaque caractère, en ajoutant la ligne suivante à LocalSettings.php :

Cette fonctionnalité est particulièrement importante pour les wikis qui ont des valeurs avec des caractères non ASCII, tels que les wikis avec des alphabets non romain, parce que l'autocomplétion par défaut basée sur les mots, ne fonctionne pas encore avec des caractères non ASCII.



Autocomplétion avec des caractères accentués
L'autocomplétion des inflexions pour les caractères avec accents, est prise en charge pour les types d'entrée combobox et tokens.

Le repli d'accents a ses limites mais il peut aider à ce que certaines interactions importantes quoique négligées, avec l'utilisateur fonctionnent mieux. Une fonction réalisant le repli d'accents associe essentiellement les caractères Unicode à leur équivalent ASCI. Avec le repli d'accents, il n'est pas important de savoir si vous cherchez cafe, café ou çåFé; le résultat sera le même.



Autocomplétion sur des valeurs externes
Il y a deux manières pour qu'un champ ait l'autocomplétion en utilisant des données externes au wiki - la première est, à partir d'une URL récupérer une sous-chaîne et retourner les données au format JSON similaires au JSON fourni par l'API MediaWiki, et la seconde est d'utiliser l'extension External Data pour récupérer les données à partir de source quelconque externe/interne.


 * from an API-like URL that takes in a substring and returns data in the necessary JSON format
 * from Wikidata
 * from any external source, using the extension.



A partir d'une URL externe
Vous pouvez obtenir l'autocomplétion d'un champ sur des valeurs venant de l'extérieur du wiki, en utilisant le paramètre suivant :


 * identifiant d'URL

Pour réaliser cela, veuillez suivre les étapes suivantes :


 * 1) Créez une page ou un service web qui recupère une sous-chaîne via la chaîne de requête, et affiche un ensemble de valeurs de complétion. Page Forms attend un format JSON de la réponse avec une clé « pfautocomplete » à la racine et un tableau d'objets avec la clé « title » marquant les valeurs des complétions possibles. Un court exemple de ceci est disponible à partir de cet appel d'API sur semantic-mediawiki.org.
 * Par exemple, si vous avez une liste de trois pays -- Uruguay, Germany, et Japan -- et que vous demandez une liste des complétions posibles pour « an », vous recevrez :
 * Ceci est aussi facile si l'autocomplétion se fait avec les valeurs d'un autre wiki.
 * 1) Vous essayez de représenter cette URL avec une courte chaîne.
 * Supposons par exemple que le service qui fournit la recherche dans notre liste de pays s'appelle «  ».
 * 1) Ajoutez la chaîne abrégée dans le tableau de   du fichier LocalSettings.php pour configurer Page Forms et utiliser votre URL lorsqu'il détecte la chaîne. Mettez «   » là où vous voulez envoyer la saisie de l'utilisateur.
 * Dans notre exemple, si nous voulons que Page Forms alimente le texte tapé par l'utilisateur vers l'URL  via le paramètre d'URL «   », nous écrivons :
 * 1) Ajoutez le paramètre « values from url=URL-identifier-string » au champs ad'hoc dans la définition du formulaire.
 * Pour notre exemple des pays, le champ peut ressembler à :
 * 1) Ajoutez le paramètre « values from url=URL-identifier-string » au champs ad'hoc dans la définition du formulaire.
 * Pour notre exemple des pays, le champ peut ressembler à :

From Wikidata
You can have a form input hold, and autocomplete on, values from Wikidata, using the parameter. The value for this parameter is structured as a mini-query, like  ("instance of" = "sculpture", "country" = "Italy"). The "Q" values can also be replaced by field names, to enable a Wikidata-based version of "show on select", for example, where "Location" is a template, and "Country" is a field, above the current one.



Utiliser l'extension External Data


L'extension External Data (ED) permet de récupérer les données à partir d'un nombre de sources comprenant des URLs externes, des pages de wikis réguliers, des fichiers téléversés, des fichiers présents sur le serveur local, des bases de données ainsi que des répertoires LDAP.

Pour appliquer l'autocomplétion en utilisant ED, il faut d'abord appeler une fonction quelconque #get_..._data de l'analyseur syntaxique de ED à partir de la définition du formulaire (de préférence à la fin de la définition du formulaire, pour éviter les passages à la ligne inutiles). Cela va récupérer des données qui pourront ensuite être utilisées dans les balises des champs. (voir la documentation de External Data pour réaliser cela). La balise du champ peut utiliser les paramètres suivants :


 * nom de variable ED (obligatoire)
 * nom de variable ED (optionnel)
 * nom de variable ED (optionnel)

Voici un exemple d'appel à #get_web_data pour récupérer les données d'une URL :

En supposant qu'une définition de formulaire contienne un tel appel, une balise de champ peut ensuite utiliser les valeurs récupérées pour l'autocomplétion - non pas simplement pour définir les valeurs d'autocomplétion en elle-même, mais également, si le type d'entrée est « combobox » ou « tokens », pour définir une image de la vignette correspondante et la description de chacunes d'elles.

En supposant que l'appel de External Data récupère trois colonnes de valeurs comme ci-dessus, la balise du champ qui utilise ces données est similaire à :



Autocomplétion dépendante
Vous pouvez définir l'autocomplétion des valeurs d'un champ comme étant basée sur la valeur que l'utilisateur a déja entrée pour un autre champ du formulaire. Ceci se fait à l'aide du paramètre  dont la syntaxe est la suivante :

Il indique que l'ensemble actuel des valeurs autorisées pour ce champ est l'ensemble de toutes les valeurs que peut prendre ce même champ sur les pages où 'field name' est égal à la valeur sélectionnée pour 'field name' dans le formulaire courant.

Est-ce gênant ?

Cet exemple peut vous aider : si un modèle appelé Restaurant avec des champs de modèle (et non des propriétés) appelés Country et City, et pour lequel vous voulez que l'ensemble des villes utilisé pour l'autocomplétion ne soit que les villes du pays que l'utilisateur a sélectionné, alors la balise de champ pour le champ City doit ressembler à ceci :



Téléversement de fichiers
Si un champ du formulaire doit contenir le nom d'un fichier à téléverser (par exemple une image), vous pouvez permettre aux utilisateurs de faire le téléversement directement via le formulaire. Ceci se fait simplement en ajoutant le paramètre uploadable (téléversable) à la déclaration du champ dans la définition du formulaire. Ceci va ajouter dans le formulaire un lien de téléversement, à côté de ce champ; si l'utilisateur clique sur ce lien, une fenêtre de style « lightbox » va s'ouvrir (en utilisant la bibliothèque JavaScript) pour qu'il puisse téléverser le fichier. Une fois cela fait, la fenêtre se ferme et le champ contient le nom du fichier téléversé. Si le champ est configuré pour contenir une liste de valeurs, le nouveau nom de fichier sera ajouté à ce qu'il y avait déjà dans le champ; sinon le nom du fichier viendra remplacer ce contenu.

Notez que le paramètre uploadable ne peut être utilisé que dans les champs de type text, text avec autocomplétion, combobox et tokens.

Pour les champs avec téléversement, vous pouvez aussi définir le nom du fichier par défaut à téléverser, en initialisant le paramètre « default filename= » dans la définition du champ. La valeur de ce paramètre peut inclure des fonctions d'analyse syntaxique, des mots magiques et similaire. Il peut également inclure la variable &lt;page name>, qui est substituée par le nom de la page devant être ajoutée ou modifiée. Donc en ajoutant à la définition du champ le paramètre default filename=Image for &lt;page name>, par exemple pour la page Abc, vous initialisez le nom par défaut du fichier à téléverser à Image for Abc. Notez que si vous voulez simplement spécifier un fichier par défaut à utiliser tel que « Imageneeded.png », le paramètre régulier « default=Imageneeded.png » fera l'affaire.

Vous pouvez voir une démonstration de téléversement de fichier ici.

Notez que la fenêtre de téléversement ne fonctionnera pas si  est iniialisé à   dans votre fichier LocalSettings.php.

Vous pouvez également déclarer que les champs avec téléversement utilisent directement le téléversement du système d'exploitation, au lieu de passer par celui de MediaWiki - ce qui donne à l'utilisateur moins de possibilités, mais le processus est plus simple et sur les appareils mobiles cela peut présenter des options intéressantes comme de pouvoir téléverser des photos juste après qu'elles aient été prises. Pour réaliser cela, ajoutez la ligne suivante au fichier LocalSettings.php :

Les paramètres spéciaux pour les champs téléversables sont :
 * - Indique que c'est un champ avec téléversement.
 * - Indique qu'une vignette de l'image téléversée doit être placée sous le champ dans le formulaire.
 * nom de fichier - Indique le fichier par défaut pour les fichiers téléversés à l'aide de ce champ.



Paramètre show on select
Pour les entrées du type 'checkbox', 'checkboxes', 'radiobutton', 'dropdown' et 'listbox', le paramètre  précise qu'un ou plusieurs éléments de la page ne doivent être affichés que lorsque certaines valeurs sont sélectionnées dans cette entrée.

La syntaxe pour ce paramètre est :



Une valeur peut être fournie par plusieurs ID d'élément :



Pour les entrées de type 'checkbox', simplement «  ID d'élément » doivent être utilisés. Notez que les IDs d'éléments ne peuvent contenir d'espaces ni de caractères multi-octets et ne peuvent pas commencer par un nombre.

Pour avoir un exemple de l'utilisation de cette fonctionnalité, allez sur ce formulaire, et observez ce qui se passe lorsque vous sélectionnez différentes valeurs dans la liste déroulante Publication type. Vous pouvez regarder comment cela été implémenté dans cette définition de formulaire.