|
| |
| TUTORIEL XML |
 |
|
|
| Découverte de WebForms 2.0 |
| La spécification proposée par Opéra, Mozilla et Apple vient concurrence le XForms du W3C en présentant une approche compatible avec les anciens navigateurs.
(16/06/2005) |
  |
L'origine
La spécification WebForms,
créée en dehors des auspices du W3C, répond à un besoin pressant
: offrir aux développeurs Web les moyens de créer des formulaires
plus sophistiqués. Cela pourrait sembler futile si l'on ne voyait
que le Web se compose aujourd'hui, pour une bonne partie, d'applications
client de toutes formes, chacune devant reposer sur le formulaire
pour récolter les informations fournies par l'utilisateur et
les envoyer au serveur, voire simplement indiquer à un script
le clic sur un bouton.
Les formulaires font partie intégrante du paysage Web d'aujourd'hui
: connexion, recherche, inscription, e-commerce, messagerie.
Les auteurs ont estimé que les formulaires tels que définis
dans HTML4 (et repris dans XHTML 1.0) font montre de leurs insuffisances
et ont choisi de les étendre.
L'idée n'est pas nouvelle : le W3C lui-même s'est lancé dans
la création de la spécification XForms, dans l'objectif de définir
la prochaine génération de formulaires Web, avec séparation
présentation/contenu, système de typage, réutilisation (voir
notre article
du 9/10/2002)...
Le problème soulevé par le WHAT WG est que XForms mettra trop
de temps à parvenir aux développeurs : il faut en effet attendre
que la spécification complète soit intégrée aux différents navigateurs,
ce qui vu sa complexité et le temps pris par la spécification
CSS1 (passée au statut de recommandation en 1996 et à reconnue
insuffisamment jusqu'en 2003) pourrait prendre de nombreuses
années encore. Sous l'impulsion de Opéra (membre fondateur du
WHAT WG, aux côtés de Apple et Mozilla), WebForms a été mis
en chantier en 2003.
Le parti
pris par le WHAT WG avec WebForms 2.0 est avant tout de faire
en sorte que ces nouveaux formulaires puissent être utilisés
par tous aujourd'hui. La spécification a donc été conçue de
telle sorte que les anciens navigateurs puissent afficher les
formulaires comme s'ils étaient classiques, tandis que les navigateurs
modernes offriraient des capacités démultipliées. Cette compatibilité
se paye par un usage de méthodes scriptées pour parvenir à l'effet
escompté.
Les apports
WebForms entend donc combler les limitations des formulaires
(datant de HTML 4.01, donc de 1999), parmi lesquelles le manque
de typage pour les données, et l'absence de validation côté-client
automatique, la nécessité de passer par JavaScript pour les
tâches complexes, l'impossibilité de spécifier l'encodage des
informations envoyées au serveur...
Les apports simplifient grandement le travail des développeurs
Web. Par exemple, il est possible avec WebForms de déclarer
un champ comme n'acceptant des données que du type "date" ou
"adresse e-mail". Si l'utilisateur ne fournit pas le bon type
de donnée, le navigateur peut l'en avertir, sans devoir mettre
en place des tests JavaScript.
<input type="datetime" step="120"
... />
<input type="email" />
<input type="url" pattern="/site/.+" ... />
<input type="number" min="0" max="28" ... />
Dans le même ordre d'idées, le formulaire peut désormais valider
lui-même les données fournies : une date dans une certaine période,
un e-mail d'un certain domaine. Ceci s'accomplit via des balises
internes et l'usage du DOM. La spécification définit ainsi une
véritable API de validation, disposant de plusieurs attributs
et méthodes : willValidate et
validate, checkValidity(),
validationMessage(), setCustomValidity().
Elle présente également de nombreux indicateurs d'erreur de
validation : typeMismatch, patternMismatch,
stepMismatch, valueMissing,
tooLong, rangeUnderflow,
rangeOverflow, customError
et valid sont autant de signaux
à exploiter pour le développeur.
Enfin, de nombreux attributs du DOM permettent de préciser les
usages des balises : data, pattern,
required, autocomplete,
autofocus, inputmode,
min, max,
step, wrap,
disabled, accept,
action, enctype,
method, replace,
et target.
Il est également possible d'indiquer si un champ est requis
ou non, ce qui avec les formulaires classiques doit se faire
via JavaScript ou un test côté serveur.
<input type="email" name="adressemail"
required="required" />
Par ailleurs, outre les extensions ci-dessus, WebForms crée
de nouvelles fonctionnalités :
- La répétition d'éléments (comme une liste d'achats)
- L'élément "output", qui affiche le résultat d'un calcul côté
client entre plusieurs champs input
<input name="a" type="number" step="any"
value="0"> *
<input name="b" type="number" step="any" value="0"> =
<output name="result" onforminput="value = a.value * b.value">0</output>
- Le remplissage automatique d'un champ à partir d'une source
externe
 |
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
Ces trois ajouts sont également pris en compte par XForms, mais
WebForms a l'avantage de fonctionner correctement sur un navigateur
ne prenant pas en compte l'intégralité des spécifications XML
et affiliés (pour les systèmes portables, par exemple).
La spécification n'est pas définitive (mais semble stable à
l'heure actuelle); elle est encore loin d'être validée par le
W3C qui préconise de prendre en compte XForms et d'autres travaux
effectués par certains groupes du consortium. Il existe
cependant une implémentation JavaScript pour IE, incomplète,
mais mettant déjà en avant les possibilités de WebForms 2.0
: le
projet WF2 chez SourceForge, et avec tests et exemples chez
les développeurs Olav
Junker Kjær et Dean
Edwards. |
|
|
|
