Hey ,

Merci pour les retours et les questions. J'y réponds dans l'ordre.

Non. Plusieurs attributs onerror peuvent avoir en liste les identifiants d'une même erreur. Exemple :

<input ... onerror="ecommon" />
<input ... onerror="ecommon e1" />
<input ... onerror="e3 ecommon" />
<input ... onerror="e42" />
...
<error id="ecommon"><p>Merci de remplir patati</p></error>

Question intéressante.
Si tu utilises le composant (pas encore codé) <tab>, XYL va pouvoir savoir si c'est l'onglet courant ou pas et réagir en conséquence. En revanche, si c'est bidouillé avec du CSS, XYL ne va pas interpréter CSS pour savoir si l'élément est visible ou pas, c'est trop compliqué.
C'est un problème intéressant mais qui n'a pas trop de sens finalement car on va toujours essayer de mettre les erreurs sur des zones visibles pour l'utilisateur . Me trompe-je ?

Oui on pourrait l'envisager mais ce serait inutile.
D'une part, on se limite trop en faisant ça. D'autre part, ça nous obligerait à modifier le DOM dynamiquement (j'entends, Hoa devrait le faire) pour pas grand chose.
En revanche, CSS peut très bien répondre à ce problème. Les propriétés display, dir, float et box-orient sont potentiellement chacunes tes amies.
Si tu écris :

<input /><error>...</error>

Tu peux très bien t'en sortir avec du CSS pour ajuster les boîtes les unes par rapport aux autres sans toucher à XYL mais seulement avec du CSS.

Actuellement, l'erreur ne sait pas par qui elle a été déclenchée, mais c'est très intéressant. On devrait être capable de faire ça. Je vais l'ajouter en feature, bien vu !
Tu aimerais que ça se passe comment ? Tu aimerais faire quoi ? Simplement un lien hyper-texte ou alors un truc plus CSS ou encore Javascript (quand on :hover ou :focus l'erreur, l'input s'highlight ou quelque chose du genre ?).

J'ai précisé dans la vidéo que XYL utilise Praspel pour exprimer des contraintes, mais XYL ne sait pas encore déduire les équivalences entre les contraintes Praspel et les mécanismes de contraintes côté navigateurs. Par exemple : string(boundinteger(0, 12)) revient à écrire maxlength="12", tout comment string(boundinteger(4, 12)) revient à écrire maxlength="12" mais on pert le "minlength" en quelque sorte. Les contraintes côté navigateurs sont faibles (malgré XForms 2.0/HTML5 Forms). C'est quelque chose sur lequel je vais travailler. Peut-être même imaginer une implémentation de Praspel côté client (en Javascript) qui permettrait plus de dynamicité. Je dois encore y réfléchir.
Il y a également des champs avec des contraintes implicites. Par exemple :

<input type="text" validate="email()" />

est équivalent à

<input type="email" />

si le domaine réaliste email existe bien sûr (mais il va exister ).

Ai-je répondu à toutes tes questions ? En es-tu satisfait ?

J'écris un code qui je pense va résoudre ton problème :

<form …>
  <yield name="my_common_error">
    <error id="ecommon"><p>Hopla</p></error>
  </yield>

  <p>Test error1: <input type="text" … />
        <my_common_error /></p>
  <p>Test error2: <input type="text" … />
        <my_common_error /></p>
   <p>Test error3: <input type="text" validate="…" onerror="ecommon" />
        <my_common_error /></p>
  <p>…

De cette façon, si l'erreur intervient sur le dernier champ, tous les champs auront l'erreur qui va apparaître. Je ne vois pas trop le but mais je pense que je n'ai pas compris ton problème en fait. Me trompe-je ?

C'est évident. Si on a des onglets, on peut toujours mettre un onglet avec des contours rouges et le nombre d'erreur à l'intérieur. Mais mettre un formulaire dans plusieurs onglets est déjà un peu étrange …

Les XForms2.0/HTML5 Forms ne sont pas là pour sécuriser le serveur mais pour améliorer l'interface graphique et l'expérience utilisateur (respectivement UI et UX). Et surtout l'UX !
Si on ajoute une vérification côté serveur, c'est évidemment pour contrôler les requêtes HTTP qui ne proviennent pas forcément du navigateur . curl sera ton premier ami.

Y aura-t-il des domaines réalistes tu veux dire ? Oui bien sûr. Pour les emails, ça va arriver. Il faudrait faire le domaine réaliste regex qui est loin d'être facile. Une fois ce dernier fait, on va pouvoir faire une tripotée d'autres domaines réalistes de type chaîne de caractères.
Contre les injections SQL, ça ne dépend pas du formulaire mais de ton gestionnaire de base de données. Je fais la distinction. PDO protège naturellement contre les injections SQL si on utilise des requêtes préparées.

Est-ce que l'implémentation des formulaires dans XYL répond à toutes tes besoins actuels ou pas ? Si non, qui sont les résistants précisémment ?

Hey Jean ,

Une problématique tout à fait intéressante. Je vais y réfléchir.
Mais une petite note : tout gestionnaire de formulaire côté serveur a cette faiblesse. Je pense avoir une solution mais je dois l'expérimenter (et voir l'impact que ça peut avoir sur des performances HTTP ; je pense que ce sera ridicule).

Si tu utilises XYL, il va tout générer de lui-même. Le document sera HTML5 compatible avec la plupart des navigateurs (même ceux ne supportant pas l'HTML5). L'HTML5 n'a rien de difficile à rendre compatible. Rappelons tout de même que pas loin de 50% des navigateurs sur le marché supportent HTML5 .
Au final, pourquoi s'imposer XHTML 1.0 strict ? Si ton document est compatible comme tu le souhaites, plus de soucis.

Là encore, intéressante problématique. Je n'y avais pas pensé. Je fais un test, 2mn.
Pour l'instant (mais je vais améliorer ça), tu peux écrire :

<input … onerror="etop e1" />

<error id="etop">
  <section1>
    <title>Errors</title>

    <error id="e1"><p>…</p></error>
  </section>
</error>

Ça fonctionne. Le mieux serait quelque chose du genre :

<error id="e1" onerror="etop">

Le nom est mal choisi mais c'est l'idée. Ou mieux encore (qui respecterait une belle logique) :

<form action="…" method="…" onerror="etop">

Ça c'est bien . Je pense que je vais partir là-dessus. T'en penses quoi ?

L'idée d'un « HoaJS » a été débattue. Le débat n'est pas clos.
La validation côté client se fera à travers HTML5. La compatibilité vers les autres navigateurs est attendues. Ou alors, Praspel côté client. C'est une autre idée également à creuser.

C'est gênant à quel niveau (sans être offensant) ?

Merci pour tes remarques .

C'est simple et ça me va très bien comme solution

Question d'habitude. Je sais que pas mal de geeks sont à fond sur des outils du type vim, mais d'abord sous Windows, je ne crois pas que cet outil soit disponible, ensuite, je travaille plus rapidement au clavier avec un système d'onglets plutôt que d'ouvrir les fichiers et de les refermer pour en ouvrir un autre. Ça fait maintenant une douzaine d'années que j'utilise un IDE avancé et retomber dans une invite de commande me hérisse le poil.

Je ne trouve pas, mais peut-être que nous ne voyons pas le problème avec la même approche.

Dans un premier temps, pour l'aspect codage de XYL, ça voudrait à priori dire qu'on a besoin d'une notion de boucle et de variable dans le langage. Si c'est un langage de structure et non un langage de programmation, on est devant un problème.

Dans un second temps, je reviens sur mon idée générale (que je t'ai probablement déjà plus ou moins exposée à titre privé) à propos de la gestion des formulaires dans un framework quel qu'il puisse être.  Il y a deux aspects dans un formulaire : l'aspect gestion, validation et traitement des données, et l'aspect visuel. Ces deux aspects peuvent être tous deux disponibles mais à mon sens doivent impérativement être dissociables et je veux pouvoir n'utiliser que la partie gestion des données et validation en gérant autrement la mise en forme. C'est du reste la raison majeure qui m'a fait exclure le Zend Framework du développement sur lequel je bosse depuis presque un an et que je me suis résolu à compléter un package personnel complet de gestion de formulaire. Dans son fonctionnement, il est assez proche de PEAR::Html_QuickForm en ce sens que j'ai un template et le package de gestion qui intercepte et traite les données. Mes templates sont le plus souvent des blocs de HTML dans une syntaxe HEREDOC et je peux arranger le code HTML absolument selon mes besoins les plus précis sans devoir tripatouiller dans une documentation de package PHP pour trouver comment reproduire en HTML tel ou tel élément. Comme mes templates sont en PHP, je peux parfaitement gérer des boucles pour construire à la volée des groupes de champs multiples.
Je t'accorde que mon système est peut-être moins simple encore que le système hoa::xyl mais je peux monter les formulaires les plus tordus, et crois moi j'en ai un ou deux assez gratinés dans mon application.

Ceci m'inspire d'ailleurs une autre question : pour la validation, mon système comporte à la base une classe de méthodes de validation génériques. Cependant, je peux avoir besoin de validations spécifiques pour un élément ou un autre, par exemple, je veux pouvoir vérifier la validité d'une donnée par rapport aux données d'un ou plusieurs autres valeurs du même formulaire. Exemple : dans un formulaire de gestion d'une fiche de collaborateur, j'ai des champs sur la civilité, le nom, le prénom, la date et le lieu de naissance et plus loin un champ ou j'inscris le numéro de sécurité sociale dudit collaborateur. Pour valider en partie ce numéro, je vais ainsi valider le premier chiffre, 1 si la civilité est « Monsieur », 2 si c'est « Madame » ou « Mademoiselle », ensuite je fais un explode sur la date de naissance inscrite et je récupère le mois et l'année pour valider les chiffres 2 à 5, etc... Avec mon propre système, j'écris une classe étendue de la classe de validation générique et j'y ajoute la méthode de validation spécifique. Comment gères-tu ça avec hoa::xyl ?

<mode style="goguenard">
Comment ça je fous la zone ?
</mode>

Dernière fois dit par Cyrano (14 Jan. 2011 16:23)