[Nouveau tuto] Bien utiliser js dans les formulaires [en attente]

(reprise du message précédent)

Laissons AJAX de côté pour le moment, je n'ai pas envie d'embrouiller les moins expérimentés.
Peut-être que j'y viendrai au moment de parler de listes déroulantes liées.
Quant au onblur, j'aime pas trop le principe d'être dérangé toutes les 30 secondes à peine je remplis un champ. Je ne sais pas, ça me semble plus naturel de faire la vérification à la fin.
Quand on remplit un formulaire papier, celui à qui il est destiné ne lit pas sur tes épaules ... il te le retourne s'il est mal rempli, après coup.
Je sais, c'est peut-être idiot comme comparaison...
Je vais rentrer dans un autre débat, mais c'est un peu comme la pagination sur le web : pourquoi on l'utilise, c'est tout simplement parce qu'on est habitué à tourner des pages quand on lis sur papier. Personnellement, je trouve que c'est absurde, il existe des scrollbars, et ça m'énerve de cliquer sans arrêt sur page suivante. Si ça ne tenait qu'à moi, je supprimerais purement et simplement pour tout mettre sur la même page. Surtout qu'avec une TOC, on règle le problème de la navigation rapide.

koala64 a écrit :

Externalisation complète du script et modèle objet
Où je souhaite en venir ?

ben... Te viendrait-il à l'idée de proposer un tuto avec des styles définis au sein des balises HTML pour montrer comment centrer une boîte CSS ?

Alors dans le cadre d'un tuto, oui. C'est plus simple de consulter le code de chaque exemple de cette manière, je trouve.
Par contre, évidemment que pour un site, non, j'ai pris l'habitude de séparer CSS et HTML et de profiter des avantages que cela suppose, c'est pas pour revenir à du <font>.
Le vrai avantage du CSS, c'est de pouvoir faire le design en un seul fichier, et de ne plus avoir à s'en préoccuper après. Une fois le CSS écrit, il n'y a plus qu'à structurer logiquement et le design se fait tout seul.
Le design d'un site est le même sur toutes les pages, c'est ce qui rend CSS si pratique.
Pour le javascript, c'est plus compliqué : il y a des fonctions qui sont constantes sur toutes les pages et là, j'adhère au même principe de séparation : un seul fichier pour modifier le comportement de tout le site.
Mais parralèlement, il existe une multitude de fonctions qui sont différentes sur toutes les pages : c'est notamment le cas des fonctions de vérification de formulaire. Ils sont tous différents, et il nécéssitent donc une fonction de vérification js propre à chacun.
Je ne vois pas l'intérêt d'externaliser ces fonctions étant donné qu'elles sont différentes pour chaque page, et que, par conséquent, cela entraînerait une multiplication des fichiers .js. Pourquoi charger systématiquement deux fichiers au lieu d'un ? aucun intérêt : on doit écrire autant de code, et on ne profite pas de la mise en cache.
Quand le code ne doit pas être réutilisé sur plusieurs pages, je n'en vois pas l'intérêt, c'est aussi simple que ça.

J'ai déjà essayé de généraliser mes fonctions de vérification de formulaire notamment en utilisant l'attribut class, comme le prouve mon script form-checker. Mais cela se révèle insuffisant pour la plupart des formulaires complexes en fait. Et en passant des informations par l'attribut class, quelque part, j'esquisse tout de même le comportement ...
A quand un xforms ou un webforms2 ? en réalité une fois qu'ils seront supportés, mon tuto n'aura plus aucun intérêt.

Donc en résumé : un petit <style>...</style> ou un petit onclick orphelin n'a jamais fait de tort à personne. Ca ne sert à rien de faire un fichier .js (ou .css, même débat) juste pour 2-3 lignes de code qui ne sont utilisés que sur une seule page.

koala64 a écrit :

Il ne s'agit pas de faire tout un cours sur DOM mais la manière dont on lie les éléments d'un formulaire à un script, à savoir mettre des id et des class sur les balises HTML et se servir d'instructions telles que getElementById, getElementsByTagName, className ou encore window.onload dans le script devraient faire partie des notions prérequises...

Le problème c'est qu'après le lecteur va peut-être avoir du mal à trouver l'info qu'il souhaite.
Entre trouver un script de 10 lignes juste en-dessous d'un formulaire d'exemple et chercher une fonction de 10 lignes dans un code de 20 Ko, je préfère la première. D'autant plus que les fonctions présentées ne sont jamais réutilisées ailleurs et que justement c'est à titre d'exemple.

Koala64 a écrit :

J'ai commencé à coder en JS par là, il y a un an, et je n'ai aujourd'hui jamais recours à l'intrusion d'un code JS dans le HTML, pas même un onclick ou quoi que ce soit d'autre. Je te confirme qu'on peut donc commencer son apprentissage du JS par là :

Vite, l'url de ton site, je veux voir ça. Pas un seul onXXX, j'ai quand même du mal à y croire. Tu en as forcément besoin quelque part... non ?
Autre question, combien as-tu de fichiers .js qui font moins de 1 Ko, juste par curiosité ? je serais prêt à parier sur "beaucoup".

Koala64 a écrit :

Je considère donc qu'avant de lire ton tuto, les utilisateurs doivent en connaître d'autres tels que celui-ci. Ce n'est franchement pas la mer à boire et celà permettra de s'orienter enfin sur des pratiques réellement standards...

Merci pour ce tuto extrêmement intéressant... mais j'ai quand même du mal à être convaincu du bien fondé de la séparation qu'on pourrait qualifier d'extrêmiste.

Koala64 a écrit :

A la rigueur, les points que je développe dans mon tuto tels que le modèle objet et la constitution de bonnes méthodes sont (je l'admets) optionnels mais je peux te dire qu'un bouquin tel que celui-là part des bases JS et s'oriente vite là dessus pour ne coder plus qu'en suivant ce modèle... Ce n'est pas pour rien qu'il apparaît comme une référence...

Bref, pour être à jour, c'est ce que j'en dit...

Ok, OK... mais je ne suis toujours pas 100% convaincu.
Modifié par QuentinC (12 Sep 2006 - 06:51)

Salut,

QuentinC a écrit :
Laissons AJAX de côté pour le moment, je n'ai pas envie d'embrouiller les moins expérimentés.

Dans la partie que j'ai intitulé Orientation vers des techniques Ajax ( nommée à tort... ), j'ai écris ceci :

koala64 a écrit :
tu pourrais néanmoins introduire cette notion du onblur en te contentant de donner un petit exemple via l'apparition d'un avertissement lorsqu'un champ est obligatoire.

Celà amènerait alors à une seconde notion... Les avertissements et leur positionnement dans le formulaire... Je te laisse en juger...

J'ai bien dit que nous laissions Ajax de côté mais c'est surtout celà dont je voulais te faire part, ce qui précède n'étant là que pour t'expliquer pourquoi le onblur ne me semble pas négligeable. La gestion des avertissements me semble aussi importante à traiter.

a écrit :
Je ne sais pas, ça me semble plus naturel de faire la véréfication à la fin.

Lorsque, plus tard, tu en viens à Ajax, le onblur est très utile. Tu n'es pas obligé de lancer l'alerte au moment où tu passes au champ suivant. Tu peux parfaitement réunir tous les avertissements à la soumission. La différence est que tu ne fais pas toutes les vérif' à la fin mais que tu n'écris que quelques lignes.

a écrit :
Alors dans le cadre d'un tuto, oui. C'est plus simple de consulter le code de chaque exemple de cette manière, je trouve.
Par contre, évidemment que pour un site, non, j'ai pris l'habitude de séparer CSS et HTML et de profiter des avantages que cela suppose, c'est pas pour revenir à du <font>.

J'ai du mal avec ce que tu dis là. Ce que je vois, c'est que le schéma serait toujours le même, que tu peux ajouter des commentaires et que tu peux faire ressortir l'élément dont tu parles dans ton tuto... Non, désolé mais, pour moi, ça vaudrait le coup de présenter les vérif' sous cette forme :

var o =
{
	_VerifEnCours: function(id)
	{
		var oNom = document.getElementById(id);
		oNom.onblur = function()
		{ ... }
	}
};

pour donner un script final ressemblant à ceci :

var o =
{
	_Init: function()
	{
		o._VerifEnCours('nom');
		o._VerifEnCours('prenom');
		etc...
		o._VerifFinale();
	},
	_VerifEnCours: function(id)
	{
		var oNom = document.getElementById(id);
		oNom.onblur = function()
		{ ... }
	},
	_VerifFinale: function()
	{
		var oSubmit = document.getElementById('submit');
		oSubmit.onclick = function()
		{ ... }
	}
};
window.onload = o._Init;

Ce n'est qu'une méthode à suivre, la difficulté étant vraiment relative. Je pense que c'est surtout son côté inhabituel qui dérange.

a écrit :
un seul fichier pour modifier le comportement de tout le site.

Je n'ai pas parlé de faire plusieurs fichier. Par contre d'un objet qui regroupe toutes tes méthodes, oui.

a écrit :
un petit <style>...</style> ou un petit onclick orphelin n'a jamais fait de tort à personne.

Mis à part le W3C ; ce n'est pas ce qu'il préconise.

a écrit :
Pour un élément isolé, je n'en vois pas l'intérêt.
Pour moi, <span onclick="mafonction();"> ne me paraît pas plus « moche » que <span id="monobjetacliquer">

Pour cet exemple, l'id peut, à la fois, servir à la fonction JS mais aussi à l'affectation de styles CSS. C'est aussi pour çà que je lui donne mes faveurs. Tu vas me dire que l'id est optionnel mais on peut aussi accéder à l'élément via getElementsByTagName auquel cas, tu te retrouves avec <span>.

a écrit :
Le problème c'est qu'après le lecteur va peut-être avoir du mal à trouver l'info qu'il souhaite.
Mais encore une fois c'est vrai que pour mon site, pour les onclick et autres joyeusetés, je préfère, quand je peux, utiliser un js externe.

Comme je te l'ai dit auparavant, les manières d'accéder à l'élément et d'affecter une fonction à l'événement sont toujours les mêmes. Vu que tu sais que ce n'est pas la meilleure pratique, pourquoi faire un tuto sur le sujet et procéder autrement de ton côté ? C'est faire croire au lecteur que ce qu'il fait est le meilleur parce qu'il va consulter ce tuto sur Alsacréations alors que tu sais que ce ne sera pas vrai.

a écrit :
Vite, l'url de ton site, je veux voir ça. Pas un seul onXXX, j'ai quand même du mal à y croire. Tu en as forcément besoin quelque part... non ?

Non, j'ai bien dit jamais et je confirme. Je ne code pas JS autrement. Pour le site, je suis en train de le faire donc plus tard.

a écrit :
Autre question, combien as-tu de fichiers .js qui font moins de 1 Ko, juste par curiosité ? je serais prêt à parier sur "beaucoup".

Non, au final, j'en ai peu... Un par objet utilitaire. La vérif d'un formulaire, ça fait 1 fichier et je n'ai pas à la répéter sur les autres pages.

a écrit :
Entre trouver un script de 10 lignes juste en-dessous d'un formulaire d'exemple et chercher une fonction de 10 lignes dans un code de 20 Ko, je préfère la première.

Oui... et il laissera le code en dessous du formulaire. Quant au fichier de 20ko, je trouve que tu exagères. Si on fait la somme de toutes les déclarations onclick qui se trouveront dans la partie XHTML avec tes fonctions, la différence sera minime quand bien même tu auras certainement quelques lignes en moins. Je n'atteindrais assurémment pas 20ko et l'avantage que j'aurais, c'est que ce sera plus propre, plus portable et plus sémantique au final quand bien même tout celà te semble optionnel.

Alsacréations est orienté standard, pourquoi ne pas donner l'exemple ?

a écrit :
j'ai quand même du mal à être convaincu du bien fondé de la séparation qu'on pourrait qualifier d'extrêmiste.

Oui, comme CSS.

a écrit :
Ok, OK... mais je ne suis toujours pas 100% convaincu.

Je vois çà, oui, mais un jour viendra... J'espère.
Modifié par koala64 (12 Sep 2006 - 07:10)

Vu les difficultés que l'utilisateur peut rencontrer, ce dont tu fais état dans tes propos, on pourrait peut-être à la rigueur sortir un tuto sur comment accéder aux éléments d'une page.
Modifié par koala64 (12 Sep 2006 - 07:44)

koala64 a écrit :
Salut,



Dans la partie que j'ai intitulé Orientation vers des techniques Ajax ( nommée à tort... ), j'ai écris ceci :
J'ai bien dit que nous laissions Ajax de côté mais c'est surtout celà dont je voulais te faire part, ce qui précède n'étant là que pour t'expliquer pourquoi le onblur ne me semble pas négligeable. La gestion des avertissements me semble aussi importante à traiter.

Qu'est-ce que tu entends par gestion des avertissements au fait ?
Parce que je n'ai jamais rien fait d'autre que de balancer des alert et placer le focus au bon endroit quand une erreur est trouvée.

Koala64 a écrit :

Lorsque, plus tard, tu en viens à Ajax, le onblur est très utile. Tu n'es pas obligé de lancer l'alerte au moment où tu passes au champ suivant. Tu peux parfaitement réunir tous les avertissements à la soumission. La différence est que tu ne fais pas toutes les vérif' à la fin mais que tu n'écris que quelques lignes.

Ca complique les choses ... mais pourquoi pas.

Koala64 a écrit :

Alors dans le cadre d'un tuto, oui. C'est plus simple de consulter le code de chaque exemple de cette manière, je trouve.
Par contre, évidemment que pour un site, non, j'ai pris l'habitude de séparer CSS et HTML et de profiter des avantages que cela suppose, c'est pas pour revenir à du <font>.

J'ai du mal avec ce que tu dis là. Ce que je vois, c'est que le schéma serait toujours le même, que tu peux ajouter des commentaires et que tu peux faire ressortir l'élément dont tu parles dans ton tuto... Non, désolé mais, pour moi, ça vaudrait le coup de présenter les vérif' sous cette forme :

var o =
{
	_VerifEnCours: function(id)
	{
		var oNom = document.getElementById(id);
		oNom.onblur = function()
		{ ... }
	}
};

pour donner un script final ressemblant à ceci :

var o =
{
	_Init: function()
	{
		o._VerifEnCours('nom');
		o._VerifEnCours('prenom');
		etc...
		o._VerifFinale();
	},
	_VerifEnCours: function(id)
	{
		var oNom = document.getElementById(id);
		oNom.onblur = function()
		{ ... }
	},
	_VerifFinale: function()
	{
		var oSubmit = document.getElementById('submit');
		oSubmit.onclick = function()
		{ ... }
	}
};
window.onload = o._Init;

Ce n'est qu'une méthode à suivre, la difficulté étant vraiment relative. Je pense que c'est surtout son côté inhabituel qui dérange.

Finalement je crois que tu dois avoir raison, je capitule.
Un script .js spécial pour le tuto.
Par contre, la notation que tu adoptes me paraît excessivement complexe pour ce qu'elle a à faire. je me contenterai d'un window.onload simple pour initialiser les onsubmit et onclick et autres.

Koala64 a écrit :

un seul fichier pour modifier le comportement de tout le site.

Je n'ai pas parlé de faire plusieurs fichier. Par contre d'un objet qui regroupe toutes tes méthodes, oui.

Beuh... même chose. Ca ne sert à rien de mettre dans un global.js un script qui n'est utilisé que sur une petite ppage de rien du tout, c'est faire charger du script tout en ayant peu de chance que la personne visite la page où est utilisé le script.

Koala64 a écrit :

un petit <style>...</style> ou un petit onclick orphelin n'a jamais fait de tort à personne.

Mis à part le W3C ; ce n'est pas ce qu'il préconise.

Pour CSS, oui. Pour js, je n'ai jamais vu qu'ils ne préconisaient pas.
Toujours est-il que ça dépanne bien dans certains cas uniques.

Koala64 a écrit :

Pour un élément isolé, je n'en vois pas l'intérêt.
Pour moi, <span onclick="mafonction();"> ne me paraît pas plus « moche » que <span id="monobjetacliquer">

Pour cet exemple, l'id peut, à la fois, servir à la fonction JS mais aussi à l'affectation de styles CSS. C'est aussi pour çà que je lui donne mes faveurs. Tu vas me dire que l'id est optionnel mais on peut aussi accéder à l'élément via getElementsByTagName auquel cas, tu te retrouves avec <span>.

Ben non, pas getElementsByTagName : s'il y a plusieurs span, c'est fini, sauf si tu veux appliquer un truc particulier à tous les span, ce qui m'étonnerais puisque span est tellement générique.

Koala64 a écrit :

Le problème c'est qu'après le lecteur va peut-être avoir du mal à trouver l'info qu'il souhaite.
Mais encore une fois c'est vrai que pour mon site, pour les onclick et autres joyeusetés, je préfère, quand je peux, utiliser un js externe.

Comme je te l'ai dit auparavant, les manières d'accéder à l'élément et d'affecter une fonction à l'événement sont toujours les mêmes. Vu que tu sais que ce n'est pas la meilleure pratique, pourquoi faire un tuto sur le sujet et procéder autrement de ton côté ? C'est faire croire au lecteur que ce qu'il fait est le meilleur parce qu'il va consulter ce tuto sur Alsacréations alors que tu sais que ce ne sera pas vrai.

OK, je capitule. Un fichier js pour le tuto, un !

Koala64 a écrit :

Vite, l'url de ton site, je veux voir ça. Pas un seul onXXX, j'ai quand même du mal à y croire. Tu en as forcément besoin quelque part... non ?

Non, j'ai bien dit jamais et je confirme. Je ne code pas JS autrement. Pour le site, je suis en train de le faire donc plus tard.
Je suis quand même très surpris.

Koala64 a écrit :

Autre question, combien as-tu de fichiers .js qui font moins de 1 Ko, juste par curiosité ? je serais prêt à parier sur "beaucoup".

Non, au final, j'en ai peu... Un par objet utilitaire. La vérif d'un formulaire, ça fait 1 fichier et je n'ai pas à la répéter sur les autres pages.

Oui, et si tu as 15000 formulaires, tu as 15000 fichiers. C'est ce que je voudrais éviter... là je parle pour mon site en général et non plus uniquement du tuto.

Koala64 a écrit :

Entre trouver un script de 10 lignes juste en-dessous d'un formulaire d'exemple et chercher une fonction de 10 lignes dans un code de 20 Ko, je préfère la première.

Oui... et il laissera le code en dessous du formulaire. Quant au fichier de 20ko, je trouve que tu exagères. Si on fait la somme de toutes les déclarations onclick qui se trouveront dans la partie XHTML avec tes fonctions, la différence sera minime quand bien même tu auras certainement quelques lignes en moins. Je n'atteindrais assurémment pas 20ko et l'avantage que j'aurais, c'est que ce sera plus propre, plus portable et plus sémantique au final quand bien même tout celà te semble optionnel.

Alsacréations est orienté standard, pourquoi ne pas donner l'exemple ?

Tu as raison après tout.

Koala64 a écrit :

j'ai quand même du mal à être convaincu du bien fondé de la séparation qu'on pourrait qualifier d'extrêmiste.

Oui, comme CSS.

Non, pas tout àf ait comme CSS. Dans la mesure où le design d'un site web entier rest identique pour toutes les pages, ce qui n'est pas le cas du comportement à cause par exemple des formulaires, si différents qu'il est impossible de les généraliser en un fichier js.

Koala64 a écrit :

Ok, OK... mais je ne suis toujours pas 100% convaincu.

Je vois çà, oui, mais un jour viendra... J'espère.

It's on progress ...
C'est peut-être bête, je me rappelle encore du gars qui m'avait convaincu de passer de la <font> attitude au CSS et là tu es un clone presque parfait... j'avais fini par être convaincu puisque je fais du 1.0 strict maintenant.

a écrit :
Qu'est-ce que tu entends par gestion des avertissements au fait ?
Parce que je n'ai jamais rien fait d'autre que de balancer des alert et placer le focus au bon endroit quand une erreur est trouvée.

Il y a effectivement l'obtention du focus mais aussi encadrer le champ d'une couleur voyante par exemple et/ou placer un texte à côté du champ (ex. : "Veuillez remplir ce champ", "Veuillez ne rentrer que des chiffres", etc... ) plutôt que de lancer une alerte type "popup", etc...

a écrit :
Ca complique les choses ... mais pourquoi pas.

C'est pour çà que je parlais d'un champ non rempli où la vérif' est simple et permet de se concentrer sur le onblur. Pour l'avertissement, il reste à déterminer si on le met à la soumission ( moins perturbant ) ou en cours ( évite de revenir sur certains champs alors que l'utilisateur pensait avoir fini. )

a écrit :
Finalement je crois que tu dois avoir raison, je capitule.
Un script .js spécial pour le tuto.
Par contre, la notation que tu adoptes me paraît excessivement complexe pour ce qu'elle a à faire. je me contenterai d'un window.onload simple pour initialiser les onsubmit et onclick et autres.

Heureux de te l'entendre dire. Effectivement, on peut rester avec des fonctions, tout ce qu'il y a de plus habituel, pour ne pas faire peur au lecteur. Le principal, c'est surtout l'externalisation.

a écrit :
Beuh... même chose. Ca ne sert à rien de mettre dans un global.js un script qui n'est utilisé que sur une petite ppage de rien du tout, c'est faire charger du script tout en ayant peu de chance que la personne visite la page où est utilisé le script.

Je ne suis pas sûr qu'on se soit bien compris... et pour cause, je n'ai pas tout déballé.

- Par exemple, si je fais un script de vérif' du formulaire, je n'en ai besoin que sur ma page de contact. Je fais donc un fichier JS contenant un objet qui n'apparaît que sur la page voulue.

- mmh... un styleswitcher, çà, j'en ai besoin sur chaque page... Je fais un second fichier avec un second objet et je le mets sur chaque page.

- La fonction de chargement... C'est principalement celà que je n'ai pas développé même si on en a touché quelques mots.
Lorsqu'on a qu'un fichier, un window.onload convient. Si, en revanche, on en a plusieurs, il vaut mieux passer par des addEventListener (DOM) / attachEvent (IE). Ca permet de lancer plusieurs fonctions sur le onload sans que l'une ne vienne écraser la précédente... ( vu qu'on part du principe qu'on a plusieurs fichiers séparés ). A l'heure actuelle, il est, là encore, préférable de faire un fichier à part dédié à lancer tes fonctions car si tu dois avoir recours au window.onload pour les navigateurs ne comprenant ni addEventListener ni attachEvent, je ne vois pas d'autre manière de faire que de tout centraliser ( pour que le window.onload soit encore possible )

a écrit :
Pour CSS, oui. Pour js, je n'ai jamais vu qu'ils ne préconisaient pas.
Toujours est-il que ça dépanne bien dans certains cas uniques.

Les recommendations s'orientent dans ce sens mais ils n'interdisent pas pour autant la déclaration en ligne vu que c'est parfois utile ( aux lecteurs d'écrans entre autres ) : Question de compatibilité ascendante.

a écrit :
Ben non, pas getElementsByTagName : s'il y a plusieurs span, c'est fini, sauf si tu veux appliquer un truc particulier à tous les span, ce qui m'étonnerais puisque span est tellement générique.

Ben si, ce n'est pas fini pour autant... getElementsByTagName est un tableau donc rien ne t'empêche d'accéder à un span particulier via :

var aSpan = document.getElementsByTagName('span')[0];

Celà dit, c'est aussi pour çà que getElementById est bien pratique... Il n'est pas nécessaire de compter les éléments.

a écrit :
Oui, et si tu as 15000 formulaires, tu as 15000 fichiers. C'est ce que je voudrais éviter... là je parle pour mon site en général et non plus uniquement du tuto.

Ben non. Si tu as 15000 formulaires ( çà aussi, c'est extrêmiste ! ), le principe est le même que pour CSS. Ton fichier est réutilisable. C'est aussi pour çà que les méthodes d'initialisation et le passage des variables en tant qu'arguments sont bien pratiques. En faisant deux méthodes d'initialisation différentes, tu peux utiliser le même objet avec un enchaînement de méthodes totalement différent. Si c'était la méthode en cours qui lançait la suivante, le déroulement serait figé et ton objet moins portable. En gros, la méthode d'initialisation, c'est le chef d'orchestre.

a écrit :
Non, pas tout àf ait comme CSS. Dans la mesure où le design d'un site web entier rest identique pour toutes les pages, ce qui n'est pas le cas du comportement à cause par exemple des formulaires, si différents qu'il est impossible de les généraliser en un fichier js.

Si tu réutilises ton objet de vérif' pour deux formulaires forts différents, il y aura certainement des méthodes inutiles... comme CSS. Tous les styles que tu affectes ne te servent pas forcémment sur toutes les pages.

a écrit :
It's on progress ...
C'est peut-être bête, je me rappelle encore du gars qui m'avait convaincu de passer de la <font> attitude au CSS et là tu es un clone presque parfait... j'avais fini par être convaincu puisque je fais du 1.0 strict maintenant.

Bestiole is unique !
Modifié par koala64 (12 Sep 2006 - 12:08)

koala64 a écrit :
Qu'est-ce que tu entends par gestion des avertissements au fait ?
Parce que je n'ai jamais rien fait d'autre que de balancer des alert et placer le focus au bon endroit quand une erreur est trouvée.

Il y a effectivement l'obtention du focus mais aussi encadrer le champ d'une couleur voyante par exemple et/ou placer un texte à côté du champ (ex. : "Veuillez remplir ce champ", "Veuillez ne rentrer que des chiffres", etc... ) plutôt que de lancer une alerte type "popup", etc...

Ah, je comprends pourquoi je n'ai jamais fait ce genre de traitement alors.
Marquer les champs d'une couleur, toujours très utile dans un lecteur d'écran... ET la gestion dynamique du DOM n'est de loin pas parfaite.
L'alert, c'est simple, ça saute aux yeux, un lecteur d'écran la lit immédiatement lors de son apparition...

Cela dit, pourquoi pas mettre un exemple de ce type, effectivement.
Faisons simple pour le changement de couleur, un changement de classe CSS.

Que préfères-tu, personnellement : l'alert surgissante, ou un message disons... moins direct ?

Koala64 a écrit :

Beuh... même chose. Ca ne sert à rien de mettre dans un global.js un script qui n'est utilisé que sur une petite ppage de rien du tout, c'est faire charger du script tout en ayant peu de chance que la personne visite la page où est utilisé le script.

Je ne suis pas sûr qu'on se soit bien compris... et pour cause, je n'ai pas tout déballé.
- Par exemple, si je fais un script de vérif' du formulaire, je n'en ai besoin que sur ma page de contact. Je fais donc un fichier JS contenant un objet qui n'apparaît que sur la page voulue.
- mmh... un styleswitcher, çà, j'en ai besoin sur chaque page... Je fais un second fichier avec un second objet et je le mets sur chaque page.

Ah, je comprends mieux maintenant. Vu comme ça, c'est moins terrible que je pensais, effectivement.
A propos des formulaires, que penses-tu d'indiquer les modalités de remplissage des champs succintement dans l'attribut class ? Trouves-tu que c'est utile, ou au contraire c'est faire du boulot inutile ?

Koala64 a écrit :

- La fonction de chargement... C'est principalement celà que je n'ai pas développé même si on en a touché quelques mots.
Lorsqu'on a qu'un fichier, un window.onload convient. Si, en revanche, on en a plusieurs, il vaut mieux passer par des addEventListener (DOM) / attachEvent (IE). Ca permet de lancer plusieurs fonctions sur le onload sans que l'une ne vienne écraser la précédente... ( vu qu'on part du principe qu'on a plusieurs fichiers séparés ). A l'heure actuelle, il est, là encore, préférable de faire un fichier à part dédié à lancer tes fonctions car si tu dois avoir recours au window.onload pour les navigateurs ne comprenant ni addEventListener ni attachEvent, je ne vois pas d'autre manière de faire que de tout centraliser ( pour que le window.onload soit encore possible )

Je n'utilise jamais attachEvent/addEventListener. Une rumeur dit que ces fonctions ne permettent pas d'utiliser le pointeur this alors que objet.onXXX le permet. Pour window.onload aucune importance bien sûr, mais pour le reste, ça peut rapidement le devenir.

Sinon, j'ai ma petite trouvaille pour le window.onload non écrasant : ça s'appelle Function.prototype.appendCode ... malheureusement mon post deviendrait vite long si j'en exposais le code ici. Si ça t'intéresse, envoie-moi un mail ou un MP avec ton mail.

Koala64 a écrit :

Ben non, pas getElementsByTagName : s'il y a plusieurs span, c'est fini, sauf si tu veux appliquer un truc particulier à tous les span, ce qui m'étonnerais puisque span est tellement générique.

Ben si, ce n'est pas fini pour autant... getElementsByTagName est un tableau donc rien ne t'empêche d'accéder à un span particulier via :

var aSpan = document.getElementsByTagName('span')[0];

Celà dit, c'est aussi pour çà que getElementById est bien pratique... Il n'est pas nécessaire de compter les éléments.

Oui, évidemment qu'on peut compter, mais je préfère avoir getElementById que getElementsByTagName(...)[44] par exemple.
Le problème c'est qu'en y allant en comptant et qu'on fait une modif, on est obligé de recompter...

Koala64 a écrit :
Oui, et si tu as 15000 formulaires, tu as 15000 fichiers. C'est ce que je voudrais éviter... là je parle pour mon site en général et non plus uniquement du tuto.

Ben non. Si tu as 15000 formulaires ( çà aussi, c'est extrêmiste ! ), le principe est le même que pour CSS. Ton fichier est réutilisable. C'est aussi pour çà que les méthodes d'initialisation et le passage des variables en tant qu'arguments sont bien pratiques. En faisant deux méthodes d'initialisation différentes, tu peux utiliser le même objet avec un enchaînement de méthodes totalement différent. Si c'était la méthode en cours qui lançait la suivante, le déroulement serait figé et ton objet moins portable. En gros, la méthode d'initialisation, c'est le chef d'orchestre.

Je vois mal comment tu peux réutiliser des fonctions de vérification de formulaires complexes, hormis la base genre checkURL, checkEmail,...

Koala64 a écrit :
Non, pas tout àf ait comme CSS. Dans la mesure où le design d'un site web entier rest identique pour toutes les pages, ce qui n'est pas le cas du comportement à cause par exemple des formulaires, si différents qu'il est impossible de les généraliser en un fichier js.

Si tu réutilises ton objet de vérif' pour deux formulaires forts différents, il y aura certainement des méthodes inutiles... comme CSS. Tous les styles que tu affectes ne te servent pas forcémment sur toutes les pages.

Je serais curieux de voir un exemple de tout ce que tu avances, juste un exemple.

Koala64 a écrit :

Bestiole is unique !

C'est vrai qu'un koala équipé d'un processeur 64 bits, ça ne court pas les rues.

Pour qu'on est du concret, je t'ai effectivement fait un exemple... Ce n'est qu'une ébauche juste pour expliquer le principe mais on peut bien sûr l'améliorer.

Pour simplifier la chose, je pars du principe que dans ton tuto, tu ne parles pas des événements tels que addEventListener & co. mais seulement des onload, onclick, etc...
De même, la segmentation en plusieurs fichiers, on ne s'en sert pas.

Dans l'exemple suivant, on a deux formulaires :

- un qui réagit au onblur
- un autre à la validation finale

Les deux utilisent la même méthode de validation mais sont initialisés par des méthodes différentes suivant l'endroit où se passe l'événement.

Le test consiste à savoir si le champ contient le bon nombre de caractères sur les champs numériques.

N'ayant pas de lecteur d'écran, je ne peux pas tester.
Disons que le truc rédhibitoire, c'est si ça les fait buguer mais vu que je teste les méthodes, ça ne devrait pas être le cas.
S'il ne se passe rien, c'est que, pour eux, la vérif' se fera en PHP (dans un sens, je trouve çà pas si mal, on évite les risques et on respecte le fait que de toute façon JS est optionnel).
Au mieux, ça passe.

Ce qu'il faut voir, c'est où faire apparaître les alertes dans le code source. Je suis un peu dans le flou de ce point de vue.
Pour le moment, celles-ci apparaîssent tout le temps en fin de formulaire (mais on peut le changer). Via CSS, je les place où je veux.

Pour tester le script, passe de champ en champ (sans rien remplir) via la touche tab jusqu'au bouton du deuxième formulaire puis clique sur celui-ci.

Tu peux voir l'exemple à cette adresse :

http://koalnet.com/divers/verif-Form/ ( Je ne laisse pas le code ici, ça fait trop long )

A vrai dire, je trouve la méthode du onblur et celle de la validation finale aussi intéressante l'une que l'autre. S'il y a problème avec les éléments dotés d'une classe, on pourrait faire un mix de deux méthodes... à savoir laisser ces éléments avec class sur le onblur parce que visuellement parlant, çà apporte un réel plus, et lancer une alerte (type popup) à la validation finale... A voir ! L'alerte finale, c'est vraiment si l'utilisateur s'entête à poursuivre...

a écrit :
A propos des formulaires, que penses-tu d'indiquer les modalités de remplissage des champs succintement dans l'attribut class ? Trouves-tu que c'est utile, ou au contraire c'est faire du boulot inutile ?

Je ne suis pas sûr d'avoir compris... Est-ce ce que je fais dans mon exemple via les onblur ? Si c'est le cas, je trouve çà pas mal, oui.

a écrit :
Sinon, j'ai ma petite trouvaille pour le window.onload non écrasant : ça s'appelle Function.prototype.appendCode ... malheureusement mon post deviendrait vite long si j'en exposais le code ici. Si ça t'intéresse, envoie-moi un mail ou un MP avec ton mail.

Oui, çà m'intéresse toujours mais à la rigueur, tu pourrais peut-être mettre ta fonction en ligne des fois que ça intéresse du monde.

A ce sujet, Simon Willison ( http://simon.incutio.com/ ) nous a pondu une fonction qui ne réécrit pas sur l'événement et qui est la suivante :

function addLoadEvent(func)
{
	var oldonload = window.onload;
	if(typeof window.onload != 'function')
	{
		window.onload = func;
	}
	else
	{
		window.onload = function()
		{
			oldonload();
			func();
		}
	}
}

Je vois mal comment tu peux réutiliser des fonctions de vérification
de formulaires complexes, hormis la base genre checkURL, checkEmail,...

En se débrouillant bien, les fonctions complexes sont plutôt rares. On a plutôt à faire, dans ce cas, à une succession de petites méthodes si on se sert de méthodes d'initialisation pour enchaîner les différentes actions.
Modifié par koala64 (13 Sep 2006 - 00:15)

De même, la segmentation en plusieurs fichiers, on ne s'en sert pas.

Si je mets le tuto un jour sur mon site, je vais être obligé de m'en servir

Koala64 a écrit :

N'ayant pas de lecteur d'écran, je ne peux pas tester.
Disons que le truc rédhibitoire, c'est si ça les fait buguer mais vu que je teste les méthodes, ça ne devrait pas être le cas.

Arf... si tu ne m'avais pas prévenu que le message d'erreur s'affichait après le formulaire, je ne l'aurais peut-être jamais trouvé. C'est pour ça que je préfère ces bonnes vieilles alert, simples et percutantes.
JE suis donc contre le principe de la fausse popup.
En fait, où que tu positionnes, ça ne changera rien. AVec l'alert, on sait tout de suite ce qui est faux.
Remarque c'est quand même toujours mieux en fin ou en début de formulaire qu'entre les champs.

Koala64 a écrit :
Ce qu'il faut voir, c'est où faire apparaître les alertes dans le code source. Je suis un peu dans le flou de ce point de vue.
Pour le moment, celles-ci apparaîssent tout le temps en fin de formulaire (mais on peut le changer). Via CSS, je les place où je veux.

Ne pas oublier non plus de bien les place dans le code, si tu utilises cette technique.

Koala64 a écrit :
Tu peux voir l'exemple à cette adresse :
http://koalnet.com/divers/verif-Form/ ( Je ne laisse pas le code ici, ça fait trop long )

Tu fais une erreur grave, celle du onclick sur le bouton submit. Mauvaise pratique à éxterminer (et c'est un euphémisme) le plus rapidement possible.

Koala64 a écrit :

A vrai dire, je trouve la méthode du onblur et celle de la validation finale aussi intéressante l'une que l'autre. S'il y a problème avec les éléments dotés d'une classe, on pourrait faire un mix de deux méthodes... à savoir laisser ces éléments avec class sur le onblur parce que visuellement parlant, çà apporte un réel plus, et lancer une alerte (type popup) à la validation finale... A voir ! L'alerte finale, c'est vraiment si l'utilisateur s'entête à poursuivre...

J'adhère pas trop au principe. Avec un lecteur d'écran, il faut que je commence à taper dans le deuxième champ pour que l'indication sur le premier s'affiche.
Ceci dit, un changement de classe pour mettre un fond rouge par exemple peut être intéressant, pour bien montrer que la donnée est fausse. Malheureusement, je ne pourrai jamais tester...

Koala64 a écrit :

A propos des formulaires, que penses-tu d'indiquer les modalités de remplissage des champs succintement dans l'attribut class ? Trouves-tu que c'est utile, ou au contraire c'est faire du boulot inutile ?

Je ne suis pas sûr d'avoir compris... Est-ce ce que je fais dans mon exemple via les onblur ? Si c'est le cas, je trouve çà pas mal, oui.

Non, c'est pas de ça que je parlais.
VA voir sur cette page et regarde comment je me sers de l'attribut class dans le formulaire d'exemple.
Remarque je pourrais faire la même chose, mais avec l'attribut accept. C'est du contournement d'utilisation, mais ...

Koala64 a écrit :

Sinon, j'ai ma petite trouvaille pour le window.onload non écrasant : ça s'appelle Function.prototype.appendCode ... malheureusement mon post deviendrait vite long si j'en exposais le code ici. Si ça t'intéresse, envoie-moi un mail ou un MP avec ton mail.

Oui, çà m'intéresse toujours mais à la rigueur, tu pourrais peut-être mettre ta fonction en ligne des fois que ça intéresse du monde.

A ce sujet, Simon Willison ( http://simon.incutio.com/ ) nous a pondu une fonction qui ne réécrit pas sur l'événement et qui est la suivante :

function addLoadEvent(func)
{
	var oldonload = window.onload;
	if(typeof window.onload != 'function')
	{
		window.onload = func;
	}
	else
	{
		window.onload = function()
		{
			oldonload();
			func();
		}
	}
}

Pas mal. J'utilise le même genre de principe, mais plus généralisé.
Finalement, j'opte pour copier-coller le code, le voici-ci-dessous :

Function.prototype.append  = function (f) {
var t = (/^function.*?\((.*?)\)\s*{(.*)}$/mg).exec(this.toString().split(/\r\n|\r|\n/).join(" "));
var f1 = t[2];
var args = t[1];
var f2 = f.toString().split(/\r\n|\n|\r/).join(" ");
if (typeof(f)=="function") {
f2 = (/^function.*?\((.*?)\)\s*{(.*)}$/mg).exec(f2)[2];
}
return new Function(args, f1+" "+f2);
}

Pour appondre un évènement, ça s'utilise de la manière suivante :

function addLoadEvent (f) {
window.onload = (window.onload? f:window.onload.append(f));
}

On peut évidemment l'utiliser pour n'importe quel évènement, et pour n'importe quelle fonction...
Modifié par QuentinC (13 Sep 2006 - 06:31)

Bonjour,

Attention à ne pas orienter ce tutoriel vers l'accessibilité réduite aux lecteurs d'écran

Salut,

a écrit :
J'ai écrit :
De même, la segmentation en plusieurs fichiers, on ne s'en sert pas.

a écrit :
Tu as répondu :
Si je mets le tuto un jour sur mon site, je vais être obligé de m'en servir

ok, le principe est le suivant :

J'ai un objet utilitaire (oVerif) que je pilote via un autre objet (oInitVerif) et auquel j'associe des messages d'erreurs (cMsg).

Je sépare mes objets en trois fichiers. Le but, c'est d'alléger et de donner un plus de souplesse. En fait, pour un formulaire sur une autre page, je pourrais parfaitement utiliser un autre fichier pilote qui, par exemple, pourrait combiner les méthodes d'un autre objet utilitaire et de celui qui est déjà présent ou encore affecter d'autres messages d'erreurs sans avoir à ajouter du code supplémentaire. Je remplace le fichier à modifier, c'est tout.

En repartant de l'exemple précédent et en ne prenant plus que le premier formulaire (où je combine toutes les méthodes), çà donne :

XHTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
	<head>
		<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
		<title>Formulaires</title>
		<style type="text/css" media="screen, projection">
			@charset "iso-8859-1";
			@import url(style.css);
		</style>
		<!-- Ordre des liaisons aux fichiers Javascript TRES important -->
		<script type="text/javascript" src="msg.js"></script>
		<script type="text/javascript" src="initVerif.js"></script>
		<script type="text/javascript" src="verif.js"></script>
	</head>	
	<body>

		<form id="form1" action="">
			<div>
				<fieldset><legend>Compte bancaire</legend>
					<label for="num">Numéro</label>
					<input type="text" id="num" name="num" />
					<label for="cle">Clé</label>
					<input type="text" id="cle" name="cle" />
				</fieldset>
			</div>
			<div>
				<input type="submit" id="submitCpt" value="transmettre" />
			</div>
		</form>	
	</body>
</html>

CSS

*
{
	padding: 0;
	margin: 0;
}
body
{
	background-color: #000;
	color: #000;
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: 100%;
}
form
{
	position: relative;
	padding: 10px;
	margin: 30px;
	font-size: .75em;
}
form *
{
	margin: 3px;
}
fieldset
{
	padding: 5px 10px 10px;
	border: 1px solid #555;
}
legend
{
	color: #000;
}
label
{
	display: block;
	text-align: center;
}
input
{
	display: block;
	margin: 3px auto;
}
#form1
{
	background-color: #FD3;
	width: 200px;
	padding-right: 300px;
	border: 2px solid #CA0;
}
#form2
{
	background-color: #3DF;
	width: 200px;
	border: 2px solid #0AC;
}
.num
{
	position: absolute;
	top: 53px;
	left: 217px;
	width: 270px;
	color: #000;
	background-color: #3DF;
	border: 2px solid #0AC;
	font-weight: bold;
}
.cle
{
	position: absolute;
	top: 92px;
	left: 217px;
	color: #000;
	background-color: #3DF;
	border: 2px solid #0AC;
	width: 270px;
	font-weight: bold;
}
.alerteFinale
{
	background-color: #FD3;
	padding: 2px;
	border: 2px solid #CA0;
	margin-top: 10px;
	color: #000;
	font-weight: bold;
}

JS -> msg.js

var cMsg =
{
	'num': "Votre compte doit contenir 21 chiffres",
	'cle': "Votre clé doit contenir 2 chiffres"
};

JS -> initVerif.js

var oInitVerif =
{
	_load: function()
	{
		if( !document.getElementById ||
			!document.createElement ||
			!document.createTextNode ) return false;

		var d = document,
			oNum = d.getElementById('num'),
			oCle = d.getElementById('cle'),
			oForm1 = d.getElementById('form1');

		oNum.onblur = oInitVerif._num;
		oCle.onblur = oInitVerif._cle;
		oForm1.onsubmit = oInitVerif._finale;
	},
	_num: function()
	{
		var oNum = document.getElementById('num');
		oVerif._num(oNum, 21, cMsg['num'], 'form1', 'num');
	},

	_cle: function()
	{
		var oCle = document.getElementById('cle');
		oVerif._num(oCle, 2, cMsg['cle'], 'form1', 'cle');
	},

	_finale: function()
	{
		var oForm = document.getElementById('form1'),
			oP = document.getElementsByTagName('p');
			
		if(oP) oVerif._finale(oP);
	}
};
window.onload = oInitVerif._load;

JS -> verif.js

var oVerif =
{
	_num: function(elem, num, text, form, clas)
	{
		var iTest = elem.value.length;

		if( num != iTest )
		{
			var d = document,
				oForm = d.getElementById(form),
				oCont = d.createElement('p'),
				oAlert = d.createTextNode(text);

			oCont.className = clas;
			oCont.appendChild(oAlert);
			oForm.insertBefore(oCont,oForm.firstChild);
		}
	},
	_finale: function(elem)
	{
		var iI = elem.length - 1,
			sMsg = '';
		
		for(iI; iI >= 0; iI--) sMsg += elem[iI].firstChild.nodeValue + '\n';
		
		alert(sMsg);
		return false;
	}
};

Désolé, je file le code ici, même si çà fait long, vu que je ne peux pas le mettre sur mon site là tout de suite maintenant.

a écrit :
J'ai écrit :
N'ayant pas de lecteur d'écran, je ne peux pas tester.
Disons que le truc rédhibitoire, c'est si ça les fait buguer mais vu que je teste les méthodes, ça ne devrait pas être le cas.

a écrit :
Tu as répondu :
Arf... si tu ne m'avais pas prévenu que le message d'erreur s'affichait après le formulaire, je ne l'aurais peut-être jamais trouvé. C'est pour ça que je préfère ces bonnes vieilles alert, simples et percutantes.
JE suis donc contre le principe de la fausse popup.
En fait, où que tu positionnes, ça ne changera rien. AVec l'alert, on sait tout de suite ce qui est faux.
Remarque c'est quand même toujours mieux en fin ou en début de formulaire qu'entre les champs.

Mis à part pour les lecteurs d'écran, j'y trouve un certain avantage. Dans le code que je viens de te donner (pas très solide au passage donc à peaufiner), on a des avertissements qui ne perturbent pas trop le visiteur et qui l'informent d'une erreur sans attendre la fin du remplissage du formulaire : L'utilisateur n'est pas obligé de cliquer systématiquement sur entrée pour faire disparaître l'alerte et l'erreur est expliquée. C'est moins contraignant et tout aussi informatif pour ceux qui se servent des navigateurs courants. Lorsqu'on soumet le formulaire, tous les messages d'erreurs sont récapitulés mais dans une vrai alerte, cette fois ; tous le monde dispose donc des avertissements, y compris les lecteurs d'écrans.

a écrit :
J'ai écrit :
Ce qu'il faut voir, c'est où faire apparaître les alertes dans le code source. Je suis un peu dans le flou de ce point de vue.
Pour le moment, celles-ci apparaîssent tout le temps en fin de formulaire (mais on peut le changer). Via CSS, je les place où je veux.

a écrit :
Tu as répondu :
Ne pas oublier non plus de bien les place dans le code, si tu utilises cette technique.

Vu que les avertissements sont répétés, (paragraphes + alerte), pas forcémment non. Les avertissements sur le onblur ne sont destinés qu'aux navigateurs "habituels" pour améliorer le confort d'utilisation. Si je trouve çà intéressant, c'est parce que je pense que c'est plus explicite qu'un simple encadré rouge sur le champ fautif. Sur un même champ, on peut avoir plusieurs types d'erreurs différentes, ce qui permet defaire la différence. Vu que l'impact recherché est essentiellement visuel, il m'est techniquement parlant, plus simple de placer les paragraphes en début ou en fin de formulaire (au début pour ci-dessus) tout en restant aussi efficace. Pour le lecteur d'écran, on se contente simplement de l'alerte finale.

a écrit :
Tu as écrit :
Tu fais une erreur grave, celle du onclick sur le bouton submit. Mauvaise pratique à éxterminer (et c'est un euphémisme) le plus rapidement possible.

Instinctivement, je te suis car, après tout, il est vrai que c'est le rôle du onsubmit. Mais en quoi est-ce si grave ? Je disposais de la navigation à la souris tout comme au clavier. Le danger venait peut-être du fait que si je soumets le formulaire en cours de route, ma protection sautait et pas la tienne mais bon... c'est pas courant un formualaire qui accepte celà. Bref, dans le doute, j'ai corrigé.

a écrit :
Tu as écrit :VA voir sur cette page et regarde comment je me sers de l'attribut class dans le formulaire d'exemple.
Remarque je pourrais faire la même chose, mais avec l'attribut accept. C'est du contournement d'utilisation, mais ...

Ton code est un peu complexe. Je ne suis pas sûr d'en avoir bien compris le principe. A priori, il me semble que tu ais affecté une fonction à un type de champ et une classe à chaque avertissement. Si tel est le cas, j'aurais trouvé plus judicieux d'affecter une classe à chaque fonction et que celle-ci dispatche sur les avertissements. Ainsi, on peut personnaliser les avertissements en fonction de l'erreur trouvée (s'il y a lieu). Peut-être ai-je mal compris mais quoiqu'il en soit, oui, la manière dont tu te sers des classes est intéressante. Si tu comptes t'en servir, je pense néanmoins qu'il faudrait simplifier un peu parce que je t'avoue que je trouve çà un peu compliqué, particulièrement dans le cas où tu proposes ce principe aux plus novices. La trame est bonne mais il faut le rendre plus lisible.

a écrit :
Tu as écrit :

Function.prototype.append  = function (f) {
var t = (/^function.*?\((.*?)\)\s*{(.*)}$/mg).exec(this.toString().split(/\r\n|\r|\n/).join(" "));
var f1 = t[2];
var args = t[1];
var f2 = f.toString().split(/\r\n|\n|\r/).join(" ");
if (typeof(f)=="function") {
f2 = (/^function.*?\((.*?)\)\s*{(.*)}$/mg).exec(f2)[2];
}
return new Function(args, f1+" "+f2);
}

a écrit :
Pour appondre un évènement, ça s'utilise de la manière suivante :

function addLoadEvent (f) {
window.onload = (window.onload? f:window.onload.append(f));
}

Oui, bien bien cette fonction. Digne d'un grand chef !
Modifié par koala64 (13 Sep 2006 - 14:51)

Tu a écrit :

Mis à part pour les lecteurs d'écran, j'y trouve un certain avantage. Dans le code que je viens de te donner (pas très solide au passage donc à peaufiner),
on a des avertissements qui ne perturbent pas trop le visiteur et qui l'informent d'une erreur sans attendre la fin du remplissage du formulaire : L'utilisateur
n'est pas obligé de cliquer systématiquement sur entrée pour faire disparaître l'alerte et l'erreur est expliquée. C'est moins contraignant et tout aussi
informatif pour ceux qui se servent des navigateurs courants. Lorsqu'on soumet le formulaire, tous les messages d'erreurs sont récapitulés mais dans une
vrai alerte, cette fois ; tous le monde dispose donc des avertissements, y compris les lecteurs d'écrans.

Ah ! C'est que j'ai aucun moyen de savoir ce qui se passe ailleurs à l'écran pendant que je remplis les champs.
Alors conçu comme ça, c'est vrai que c'est génial comme approche, ça me fait penser un peu à une barre d'information contextuelle dont le texte change en fonction de la situation.
Le truc qu'il faudrait peaufiner, évidemment, c'est qu'un seul message ne s'affiche à la fois.
J'adopte la combinaison du onblur+onsubmit pour mes prochaîns formulaires, c'est sûr.

Tu a écrit :

Vu que les avertissements sont répétés, (paragraphes + alerte), pas forcémment non. Les avertissements sur le onblur ne sont destinés qu'aux navigateurs
"habituels" pour améliorer le confort d'utilisation. Si je trouve çà intéressant, c'est parce que je pense que c'est plus explicite qu'un simple encadré
rouge sur le champ fautif. Sur un même champ, on peut avoir plusieurs types d'erreurs différentes, ce qui permet defaire la différence. Vu que l'impact
recherché est essentiellement visuel, il m'est techniquement parlant, plus simple de placer les paragraphes en début ou en fin de formulaire (au début
pour ci-dessus) tout en restant aussi efficace. Pour le lecteur d'écran, on se contente simplement de l'alerte finale.

Tu as parfaitement raison, c'est sûr que c'est plus explicite qu'un champ qui se peinture d'un coup en rouge.
Du coup là tu m'as convaincu, prochaîn formulaire que je programme, je combine onblur et onsubmit.

Tu a écrit :

Instinctivement, je te suis car, après tout, il est vrai que c'est le rôle du onsubmit. Mais en quoi est-ce si grave ? Je disposais de la navigation à la
souris tout comme au clavier. Le danger venait peut-être du fait que si je soumets le formulaire en cours de route, ma protection sautait et pas la tienne
mais bon... c'est pas courant un formualaire qui accepte celà. Bref, dans le doute, j'ai corrigé.
cligne

Pas besoin d'avoir un lecteur d'écran pour faire sauter la protection. Essaie en passant d'un champ à l'autre par tab et en appuyant sur espace pour valider une fois que le bouton a le focus. Certains utilisateurs détestent gesticuler entre la souris et le clavier...

Tu a écrit :
Ton code est un peu complexe. Je ne suis pas sûr d'en avoir bien compris le principe. A priori, il me semble que tu ais affecté une fonction à un type de
champ et une classe à chaque avertissement. Si tel est le cas, j'aurais trouvé plus judicieux d'affecter une classe à chaque fonction et que celle-ci dispatche
sur les avertissements. Ainsi, on peut personnaliser les avertissements en fonction de l'erreur trouvée (s'il y a lieu). Peut-être ai-je mal compris mais
quoiqu'il en soit, oui, la manière dont tu te sers des classes est intéressante.
cligne Si tu comptes t'en servir, je pense néanmoins qu'il faudrait simplifier un peu parce que je t'avoue que je trouve çà un peu compliqué, particulièrement
dans le cas où tu proposes ce principe aux plus novices. La trame est bonne mais il faut le rendre plus lisible.

Là je ne suis pas sûr de te suivre complètement, surtout tes dernières phrases. Pourrais-tu expliquer ?

En fait, le principe de base est simple : le window.onload est chargé de parcourir les attributs class des éléments de formulaire, et de générer dynamiquement une fonction de vérification exécutée sur le onsubmit. Le contenu de cette fonction générée dépend des indications que je donne dans l'attribut class, autrement dit, en gros : le type (chaîne, entier, réel, e-mail, date, etc.) et quelques paramètres (valeur minimum, maximum, etc.) de chaque champ.

Je pensais à utiliser l'attribut accept au lieu de class, car il me permettrait d'être plus libre dans la syntaxe des déclarations (je pourrais parfaitement imaginer <input .... accept="integer between 0 and 100" ... />). La syntaxe deviendrait alors tellement simple qu'un novice n'aurait qu'à inclure le script sans forcément savoir dans le détails ce qu'il fait. L'attribut accept n'étant utilisé que dans le cadre des input file, dans les autres cas, on peut à priori y mettre n'importe quoi, ce qui n'est pas le cas de l'attribut class (le navigateur risque de perdre les pédales si je lui donne un class="integer between 0 and 100" par exemple)

Début balises de citations

Tu a écrit :

Oui, bien bien cette fonction. Digne d'un grand chef !
ravi

C'est surtout que le code de machin que tu as proposé tout à l'heure ne fonctionnera que deux fois.
Je m'explique : première fois, window.onload = null, on se contente d'une simple affectation à onload.
Deuxième fois, window.onload est déjà rempli, on déplace le pointeur vers window.oldOnload et on réattribue une nouvelle fonction à window.onload combinant l'ancienne et celle qu'on rajoute.
Troisième fois, window.oldOnload est écrasé ...

EDIT : Non, erreur : j'ai zappé un mot-clé très important qui change tout : var !
Modifié par QuentinC (13 Sep 2006 - 18:00)

En fait, ce à quoi je pense doit revenir approximativement au même mais fait de manière différente donc, en fonction de tout ce qu'on a dit, je te donne ce qui me passe par la tête... Bien entendu, tu n'es pas obligé de tout respecter mais c'est tel que je vois les choses.




Déjà, si on récapitule, on peut voir :

- que les classes sur chaque champ donnent plus de souplesse que les identifiants,
>> (réutilisables dans une page, permettent plusieurs valeurs)

- qu'une association de méthodes simples est plus souple qu'une compliquée qui fait tout,
>> (méthodes réutilisables sur plusieurs champs, modulables en fonction du type de champ)

- que des fichiers séparés offrent le même avantage,
>> (fichiers plus concis, réutilisables dans plusieurs méthodes/pages, modulables suivant les pages)

- que la vérif' via les onblur améliore l'ergonomie,
>> (avertit immédiatement l'utilisateur, personnalise en fonction du champ quitté)

- que l'alerte finale est nécessaire aux lecteurs d'écran.

- qu'un objet contenant des méthodes minimise les risques d'interactions.
(Regarde dans l'exemple de cet aprem', on a deux méthodes _num différentes mais comme c'est deux objets différents, ça ne pose pas de problème)




L'idée, c'est qu'au risque de multiplier les fichiers JS et les méthodes, je privilégie la souplesse d'utilisation et la portabilité.
Effectivement, on profite moins du cache mais comme :

- les fichiers sont concis,
- on a des méthodes parfois communes à nos différentes pages,
- et surtout, on ne charge que le nécessaire,

ça ne me semble pas si préjudiciable au vu des bénéfices.

Je commence donc par créer et déclarer respectivement :

- un fichier (classe) contenant tous les avertissements et ordres de priorité de ces avertissements (j'explique après),
- un fichier (objet) orchestrant le déroulement du script avec sa méthode chargement (window.onload ou autre),
- un fichier répertoriant toutes les méthodes de vérification d'un formulaire.

C'est ce qui me semble minimal mais la plus grande souplesse étant obtenue avec :

- un fichier contenant une classe vide,
- un fichier par propriété/méthode de cette classe.

(Je dis çà pour toi mais pas spécialement pour le tuto, l'essentiel étant de donner le principe et non d'optimiser à l'excès vu qu'ici, ce n'est pas utile)




En terme de réalisation, je dispose, par exemple, de champs comme ceci :

<input type="text" name="email" class="valeur email" />

Lorsque le focus est donné au champ, je vérifie qu'il n'existe pas déjà un avertissement contenant "valeur" ou "email", auquel cas, je le supprime. (méthode)
>> Ca permet, lorsque l'utilisateur corrige une erreur, de faire disparaître l'avertissement.

Je laisse donc l'utilisateur remplir son champ puis au onblur, je lance la vérif'.

Dans un premier temps, je répertorie toutes les classes du champ. (méthode)
De là, je donne au préalable un ordre de propriété pour chacune des classes du champ (classe),
puis j'envoie, dans l'ordre de priorité (ex. : valeur->1 , email->2), des méthodes associées à chacune d'entre elles. (méthode)

Lorsque je rencontre une classe "valeur", la méthode associée m'oriente vers une méthode d'écriture d'avertissement si le champ est vide et stoppe la vérif' du champ ou bien laisse poursuivre la vérification du champ s'il n'y a pas de problème.

Ca permet de n'envoyer qu'un seul avertissement (paragraphe) contenant :
"Le champ est vide."

... plutôt que deux avertissements contenant respectivement :
"Le champ est vide." et "Votre email n'existe pas."

... le deuxième avertissement étant forcémment vrai si le premier avertissement existe.

On passe donc de champ en champ en suivant le même principe.

A la soumission du formulaire, on renvoie une alerte contenant tous les paragraphes générés.




Diverses choses auxquelles il faut penser :

- Si l'utilisateur corrige son erreur avant la soumission, comme dit auparavant, l'avertissement doit disparaître,
- Il faut sélectionner la valeur du champ à la prise du focus (s'il n'est pas vide).
- Si l'utilisateur revient au champ précédent pour corriger, il faut supprimer l'avertissement généré sur le champ en cours lorsqu'on le quitte.




Pour récapituler, le principe est donc d'associer une méthode à chaque classe du champ et que celle-ci détermine la nature de l'avertissement à envoyer. En poussant un peu, on peut même personnaliser chaque alerte, visuellement parlant, grâce la classe qui a lancé l'action ou/et grâce au type d'avertissement envoyé.

Voilà... A toi de juger de la pertinence de tout ce que je viens d'énoncer pour le tuto (et tes prochains scripts)

Sur ce, va falloir que je me renseigne sur l'attribut accept parce que je n'ai pas bien compris le fonctionnement.
Modifié par koala64 (14 Sep 2006 - 00:53)

BOnjour,

Petite remarque à propose de l'attribut accept : son contenu est très précisément défini en HTML et ne peut admettre que des types de medias eux mêmes normalisés ("text/html", "image/png", etc). Il est en fait destiné à permettre une vérification native par le navigateur.

Son utilisation sous la forme proposée ci-dessus est donc exclue ("<input .... accept="integer between 0 and 100" ... />").
Modifié par Laurent Denis (14 Sep 2006 - 06:15)

Au fait, pourquoi attendre onblur pour donner un message ?
Au moment où l'utilisateur donne le focus, on pourrait faire apparaître un message genre « Votre nom d'utilistaeur doit contenir uniquement des lettres ». Ce serait bien entendu un message à titre informatif, sans vérifier si ce que contient le champ est bon ou mauvais, à ce moment-là.
C'est juste que je trouverais peut-être bizarre de voir « Votre e-mail est incorrect » pendant que je remplis le champ pseudo...

Pour ce qui est d'accept : pour un input file, permet d'indiquer les types de fichier à envoyer (type MIME)
Pour les autres input, cet attribut est inutilisé, d'où l'idée de m'en servir à la place de class. Le truc un peu bête c'est que cet attribut ne pourrait pas être utilisé avec les textarea et les select...
Au contraire ce qui est con avec class, c'est que je ne peux pas mettre n'importe quoi en guise de valeur. Je vois déjà les navigateurs perdre les pédales si je donne des instructions genre class="number between 0 and 100" ou "required string between 4 and 15 chars" ou "date betwwen 01/01/2004 and 01/01/2006" ou encore "pattern ^\d{2}-\d{3}-\d{5}$". Car j'aimerais arriver à des méthodes de vérification assez souples pour supporter ce genre de syntaxe. C'est aller un pas plus loin dans ton idée d'associer une méthode par class, avec ici la possibilité d'avoir en quelque sorte des paramètres.
IL faudrait pouvoir tester que ce type de contenu dans l'attribut class ne provoque pas le plantage du moteur CSS dans la plupart des navigateurs courants. D'après ce que je sais, normalement, si une classe n'existe pas, elle est ignorée, mais ici c'est une autre paire de manche puisque j'utilise potentiellement des caractères incorrects.

Attention: une classe ne sera ignorée que dans le traitement d'une feuille de style (Plus exactement, la ligne CSS où figure la syntaxe erronée sera ignorée). Cela ne joue donc pas ici.

Lors du traitement du code HTML où figurent tes classes, le navigateur n'a pas de règles normatives sur le traitement d'erreurs de ce type. J'imagine déjà ce que les lecteurs du tutos seront susceptibles d'y mettre ("$foo > 10", fatalement )... Donc, incertitude totale sur le résultat actuel et futur, et problématique classique de la nécessiter de valider son HTML.

Il serait préférable de préciser très exactement dans votre tuto les limites de cette utilisation des classes. Voire d'adapter de manière à n'y inclure que des noms de classe valides à tous points de vue, permettant de récupérer les conditions de vérification présentes dans le script externe en tant que variables, par exemple. Ceci satisferait mieux aux principes de séparation structure / dynamisme.

Ce n'est pas tout à fait pour rien que les champs cachés sont utilisés
Modifié par Laurent Denis (14 Sep 2006 - 06:27)

QuentinC a écrit :

Au moment où l'utilisateur donne le focus, on pourrait faire apparaître un message genre « Votre nom d'utilistaeur doit contenir uniquement des lettres ».

Pitié, restez simples et directs, et ne succombez pas aux délices du "techniquement possible et élégant" perdant de vue le pourquoi des choses

Ce type d'information doit figurer simplement "en dur" dans le contexte du formulaire, si possible dans le label, pour être perceptible avant que l'utilisateur ne décide de remplir le formulaire... Et pour éviter de transformer le formulaire en "bidule qui gigote dès que je fais quelque-chose"...
Modifié par Laurent Denis (14 Sep 2006 - 06:44)

Hello,

Laurent Denis a écrit :
Pitié, restez simples et directs, et ne succombez pas aux délices du "techniquement possible et élégant" perdant de vue le pourquoi des choses

Effectivement... A bien y regarder, on s'oriente de plus en plus sur des notions qui vont être difficiles à appréhender.

Déjà, pour simplifier la chose, on peut déterminer les règles implicites.

- Par exemple, un champ type text doit obligatoirement tester si la valeur est vide ou non.
>> Du coup, on peut déjà faire une vérif' directement sur le tag plutôt que d'ajouter une classe.

- L'identifiant, quant à lui, permet de rendre le champ unique.
>> Pour le passage des paramètres, c'est donc adapté ( un identifiant = une liste de paramètres )

- La classe servirait pour le reste.
>> çàd pas une vérif en fonction du champ ni un critère unique -> cas plutôt rare en somme

Le but reste quand même d'être le moins verbeux possible.

La séparation des fichiers complexifie la compréhension du tuto aussi... Vu que j'en parle dans le mien, c'est, il est vrai, inutile de s'en servir ici, çà va alourdir.

La souplesse... oui mais dans une certaine mesure... Pour le tuto, il faut privilégier la compréhension de celui qui va lire avant toute chose. Si on parle chinois (désolé pour eux !), on n'atteint pas le but recherché.

De même pour le modèle objet. Ca permet surtout d'éviter les interactions mais pour l'objectif de ce tuto, c'est inutile.

Personnellement, je conserverais :

- la séparation structure / comportement,
>> un id suffit, pas besoin de onclick, onblur, etc... en ligne. Chaque fonction commence par identifier le tag à vérifier.

- l'association onblur + onsubmit,
>> pratique et ergonomique

- plusieurs petites fonctions plutôt qu'une grande,
>> facilement développable lors du tuto et souple à l'utilisation

- une fonction directrice qui appelle les autres.
>> permet de bien comprendre le raisonnement adopté (simplifie la lecture et améliore la souplesse)

QuentinC a écrit :
Au moment où l'utilisateur donne le focus, on pourrait faire apparaître un message genre « Votre nom d'utilistaeur doit contenir uniquement des lettres ».

Laurent Denis a écrit :
Ce type d'information doit figurer simplement "en dur" dans le contexte du formulaire, si possible dans le label, pour être perceptible avant que l'utilisateur ne décide de remplir le formulaire...

oui, plus c'est clair, moins il y a risque d'erreurs.

Donc, faire souple et élégant, oui MAIS faire simple avant tout ET bien utiliser JS aussi (c'est une partie de l'objectif à atteindre).
Il faut trouver le juste milieu.
Modifié par koala64 (14 Sep 2006 - 07:44)

Vous avez raison, je vais trop loin là.

Donc je vais me contenter du onblur+onsubmit.
+ un fichier js qui associe id et propriétés de vérification

Ce que je suis en train de préparer, aussi bien pour mon tuto que pour mes futurs scripts en fait :

- Un fichier form-checking-core.js définissant un objet contenant 1/différents messages prédéfinis, 2/des fonctions de vérification de base.

Extrait fictif :

// fco pour form checking object
fco = {
MSG_XXX : "Bla bla bla",
MSG_YYY : "Bla bla bla",
checkXXX : function () {
if (this.value.length != 5) {
alert(this.msgError);
return false;
}
return true;
}

}

Et il y aura un fichier par page attribuant les fonctions et messages aux objets, par exemple :

var o = document.getElementById('champ');
o.check = fco.checkXXX;
o.msgError = o.msgYYY;
...

Bon, évidemment, ici, ce n'est qu'un extrait.
Que pensez-vous de cette manière de découper ?

Perso, ça me convient bien... Après, le tout, c'est de correctement l'expliquer...

Hello,

Cette idée de tutoriel est-elle toujours d'actualité ?