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

Bonjour,
C'est une idée qui me vient comme ça, je n'ai pas l'impression qu'il existe déjà quelque chose là-dessus sur alsa.
Mon idée commencerait d'abord par montrer ce qu'il faut et ne faut pas faire avec js dans les formulaires : p.ex onchange sur les select, onsubmit sur <form> à la place d'onclick sur le bouton submit, différencier sur la fonctionnalité plutôt que sur le nom du navigateur... enfin les classiques.
Ensuite, il faudrait peut-être poursuivre avec quelques idées et quelques scripts permettant de vérifier les données d'un formulaire de manière non obstructive.
(Je possède déjà une petite combine à moi dans ce domaine, si le script intéresse quelqu'un, je donnerai l'URL. Je l'ai mis sous license creative common paternité/non commercial/partage à l'identique.)
Et ensuite, si le temps et la motivation est toujours de mise, attaquer la question AJAX ?

Enfin voilà, l'idée est lancée.
A vos commentaires et nos claviers.
Modifié par QuentinC (27 Oct 2006 - 18:57)

Hello QuentinC,

A mon avis, ce serait extrêmement intéressant et utile car les formulaires (et la façon dont ils sont traités) font partie des éléments les plus souvent négligés en terme d'accessibilité.

Je pense qu'on pourrait procéder en plusieurs étapes :
1- ce qui est franchement inaccessible dans un formulaire "classique"
2- une première étape à prendre en compte (le minimum vital en terme d'accessibilité)
3- aller plus loin dans l'accessibilité et dans l'emploi de JavaScript dans les formulaires.

C'est simplement un avis hein

Salut

Peut-être aussi ajouter un mot sur le traitement côté serveur.

Par exemple, comment vérifier les données envoyées par POST et les ré-introduire dans la page en cas d'erreur pour éviter que l'utilisateur soit obligé de tout recommencer.

Et sur le traitement des erreurs, aussi. Je ne sais pas si on peut parler d'accessibilité, mais il me semble important qu'il y ait un retour clair vers l'utilisateur pour lui signaler que tout a bien marché, ou au contraire que telle partie a foiré.

Mais je me rend compte que c'est un gros boulot en plus ...
Modifié par Sopo (29 Aug 2006 - 14:43)

Sopo > Ca pourrait être la deuxième partie du tutorial, une espèce de "suite"... pourquoi pas, s'il y a assez de motivés.
Je me suis rendu compte de trucs assez géniaux ces derniers temps dans ce domaine ... et j'ai appliqué dans mon mini-RPG.

Donc, il faudrait deux grands volets :

Partie I : Bien utiliser javascript dans les formulaires
1. Ce qu'il faut éviter, ce qui n'est pas accessible du tout
2. Accesssibilité de base
3. Vérifier les données saisies en javascript de manière accessible (+scripts)
4. AJAX

Partie II : Bien utiliser php pour vérifier les données envoyées par formulaire
1. Ce qu'il ne faut pas faire
2. Comment signaler les erreurs / Comment ne pas être obligé de resaisir les données en entier

C'est long et ambitieux, mais en s'y mettant à plusieurs, ça peut le faire je pense.

Je vais terminer par la question philoso-sémantique du jour :
Quand faut-il utiliser des groupes de boutons radio plutôt qu'une liste déroulante et inversément pour choisir une option parmi plusieurs possibles ?
Modifié par QuentinC (29 Aug 2006 - 18:07)

Juste une petite intervention : il faut peut-être éviter les grands projets en plusieurs volets et très complexes car, par expérience, ce sont le genre de projets qui n'aboutissent jamais par manque de temps et de motivation.

Je préfère voir un tutoriel "simple" abouti qu'un projet gigantesque qui va s'endormir dans quelques semaines

Alors on oublie le php pour le moment, en tout cas dans les premiers temps. C'est vrai que c'est un peu voir gros...

QuentinC a écrit :
Alors on oublie le php pour le moment, en tout cas dans les premiers temps. C'est vrai que c'est un peu voir gros...

En tous cas, je propose qu'on en reparle lorsque la partie I sera finie

Sopo > Après la partie 1 oui, pourquoi pas.
Mais bon, faut déjà la faire cette partie 1...

Juste un petit post pour vous signaler que j'ai commencé la rédaction du tuto.
Je vous donnerai l'URL quand j'aurai terminé, pour l'instant je suis encore au point 1. Vous êtes déjà prévenu, ça risque d'être assez long à rédiger et à lire...

Voici le plan observé, j'attends vos critiques :
1. Accessibilité de base
label, fieldset, legend, etc. je refais toute la liste pour repartir d'un bon pied.

2. Les erreurs les plus courantes en ce qui concerne javascript
onclick/onsubmit, select et onchange, double-submit, validation du formulaire par la touche entrée et conséquences, etc.

3. Vérifier les informations saisies
No comment

Voilà, merci.
Modifié par QuentinC (05 Sep 2006 - 10:14)

Je suis surpris de voir le peu de réactions que ce plan sucite... cela vous convient-il ? oui ? non ? pourquoi ? des idées à ajouter ou à eenlever ?
Je vous demande ça avant que j'écrive un ramassis de choses inutiles ... En attendant je considère ce silence comme le fait d'être satisfait.

La rédaction avance ! Mais il faut que je me motive pour le finir si possible ce week-end.

Oui, oui, c'est super, Quentin !

Salut,

ayant assez peu d'idées sur ce qu'on peut faire en js sur un formulaire, c'est plutôt par rapport au tutoriel lui même et en le suivant que je donnerai mes impressions.

Lister ce qu'il ne faut pas faire est une bonne chose je pense, mais il faut en parallèle donner les solutions viables qui pourraient correspondre pour l'effet souhaité.

a écrit :

Lister ce qu'il ne faut pas faire est une bonne chose je pense, mais il faut en parallèle donner les solutions viables qui pourraient correspondre pour
l'effet souhaité.

Oui, cela va de soi, du moment qu'il en existe une. Ce n'est pas toujours le cas.

Voilà, vu le temps que ça me prend, je préfère ne pas attendre la fin pour vous montrer le début.

Voici donc le point 1 et le début du point 2. Le reste viendra plus tard... mais c'est déjà relativement long. 18 Ko avec le strict minimum de HTML. Je ne l'ai pas intégré à mon site, je le ferai quand ce sera fini.
Le début du tuto ici

J'attends vos avis éclairés.
Merci.

Salut QuentinC,

C'est pas mal parti, je trouve. Effectivement, çà risque d'être long mais la structure est bonne et j'apprécie beaucoup le contre-exemple suivi du problème posé et de la solution. Ainsi, ça fait ressortir le pourquoi de cette bonne pratique, ce qui n'est pas un mal. Le rappel de l'utilisation des formulaires sur des lecteurs d'écran ou via la navigation clavier est une bonne chose aussi car bien trop méconnue. Bref, le fait de préciser au lecteur qu'il doit toujours avoir à l'esprit qu'il existe différents supports et modes de navigation me semble important.

Je te donne quelques points sur lesquels j'ai accroché ainsi que quelques-unes de mes interrogations.

a écrit :
Bien indiquer et de manière précise à l'utilisateur ce qu'on lui demande

Le style de ce titre est bof bof, moyen clair. Je chercherais une autre tournure de phrase.

a écrit :
Le deuxième problème est uniquement technique et repose sur l'utilisation des bons éléments pour donner la bonne information.

Là, j'aurais dit sémantique et technique. Une petite phrase d'exemple pour être plus explicite me semble judicieuse.

Je pense aussi qu'un rappel sur pourquoi ne pas faire un formulaire sous forme de tableau serait bénéfique.

a écrit :
Voici un exemple d'élément <label> et son champ de formulaire lui correspondant

A cet endroit, tu pourrais montrer les deux styles d'écritures : Le label avant le champ ainsi que celui qui l'englobe.

a écrit :
IL n'est peut-être pas inutile de rappeler que le javascript est un composant optionnel

Si, c'est utile ce rappel. On en croise encore qui ne font les vérif' que par JS... Je pense qu'une précision sur la nécessité de valider du côté serveur est indispensable.

a écrit :
Fonctions de vérification avant soumission et validation au clavier

mmh... ok pour faire passer le onclick d'un input sur le onsubmit du formulaire mais pour çà ?

<input name="valid" value="Valider" onblur="return validation3();" type="submit" />

Ca permettrait de voir son erreur tout de suite plutôt que d'attendre le remplissage complet du formulaire, non ?

Et pourquoi quand je mets onsubmit sur form via DOM, çà ne marche pas ?

Pour l'erreur n°3, on n'a pas encore la réponse mais j'opte pour la sélection automatique du champ à la prise du focus...

Euh... Dernières questions... Comptes-tu laisser tout le code JS en ligne ? Pourquoi ne pas créer un objet global de vérification qui regrouperait toutes ces méthodes ? Ce serait mieux non parce si j'ai quatres formulaires, faut que je retape tout le code JS ?? J'aurais plus vu la constitution progressive de cet objet en guise de solution, par méthode tout au long du tuto puis une récap' complète en fin de tuto.

Et puis, comme moi, je pense qu'il va falloir faire un petit menu d'accès rapide en début de tuto parce qu'on peut vouloir chercher une info bien précise sans vouloir se taper les cents prochains ko de données.

Voilà, en espérant que çà t'aide.
Modifié par koala64 (09 Sep 2006 - 21:19)

koala64 a écrit :

Bien indiquer et de manière précise à l'utilisateur ce qu'on lui demande

Le style de ce titre est bof bof, moyen clair. Je chercherais une autre tournure de phrase.

Effectivement. Quand j'aurai trouvé mieux, je remplacerai.

koala64 a écrit :

Le deuxième problème est uniquement technique et repose sur l'utilisation des bons éléments pour donner la bonne information.

Là, j'aurais dit sémantique et technique. Une petite phrase d'exemple pour être plus explicite me semble judicieuse.

Qu'entends-tu par petite phrase d'exemple ?
ET oui en effet j'ai hésité à placer le mot "sémantique", mais je voulais être sûr, avant de le faire, qu'il soit au bon endroit.

koala64 a écrit :

Je pense aussi qu'un rappel sur pourquoi ne pas faire un formulaire sous forme de tableau serait bénéfique.

C'est pas une mauvaise idée. Le problème c'est que là après on touche un domaine beaucoup plus vaste : l'utilisation des tableaux en général... et je n'aimerais pas trop m'y risquer.
Ensuite, suivant les infos qu'on a à saisir, un tableau peut être pratique.

koala64 a écrit :

Voici un exemple d'élément <label> et son champ de formulaire lui correspondant

A cet endroit, tu pourrais montrer les deux styles d'écritures : Le label avant le champ ainsi que celui qui l'englobe.

Bien vu. Je vais la mettre, mais avec un avertissement : j'ai ouï dire que la syntaxe avec label englobé n'était pas bien supportée par certains navigateurs.

koala64 a écrit :

IL n'est peut-être pas inutile de rappeler que le javascript est un composant optionnel

Si, c'est utile ce rappel. On en croise encore qui ne font les vérif' que par JS... Je pense qu'une précision sur la nécessité de valider du côté serveur est indispensable.

Faudrait voir où je pourrais caser ce rappel-là. Mais il ne faudrait pas que je me mette à mmélanger du script serveur et client, ça risquerait peut-être d'embrouiller le lecteur un peu moins connaisseur.
A propos de langage serveur, j'aimerais m'assurer d'un truc : quand on envoie un formulaire par entrée, le champ correspondant au bouton submit n'est pas transmis, non ? Faudrait peut-être que je le signale dans le cadre de l'erreur n°2.

koala64 a écrit :

Fonctions de vérification avant soumission et validation au clavier

mmh... ok pour faire passer le onclick d'un input sur le onsubmit du formulaire mais pour çà ?

<input name="valid" value="Valider" onblur="return validation3();" type="submit" />

Ca permettrait de voir son erreur tout de suite plutôt que d'attendre le remplissage complet du formulaire, non ?

Là, j'avoue ne pas te suivre. Pourquoi onblur ?

koala64 a écrit :

Et pourquoi quand je mets onsubmit sur form via DOM, çà ne marche pas ?

Qu'as-tu testé ?

koala64 a écrit :

Pour l'erreur n°3, on n'a pas encore la réponse mais j'opte pour la sélection automatique du champ à la prise du focus...

C'est une des deux solutions que je vais proposer.
Je ne sais pas si quelqu'un s'en est déjà aperçu sur mon site, ou alors peut-être que ça marche pas, mais tous les champs input se sélectionnent à la prise du focus... tous. Je pense également que c'est la meilleure solution ... mais il y en a une deuxième.

koala64 a écrit :

Euh... Dernières questions... Comptes-tu laisser tout le code JS en ligne ? Pourquoi ne pas créer un objet global de vérification qui regrouperait toutes ces méthodes ? Ce serait mieux non parce si j'ai quatres formulaires, faut que je retape tout le code JS ?? J'aurais plus vu la constitution progressive de cet objet en guise de solution, par méthode tout au long du tuto puis une récap' complète en fin de tuto.

Heu... rien compris. Je mets le code js directement après le formulaire pour que quand on choisit d'afficher le code directement dans la page, le code js s'affiche aussi.

koala64 a écrit :

Et puis, comme moi, je pense qu'il va falloir faire un petit menu d'accès rapide en début de tuto parce qu'on peut vouloir chercher une info bien précise sans vouloir se taper les cents prochains ko de données.

Bonne suggestion. J'en prends note et je mettrai une TOC quand le tuto sera fini.

koala64 a écrit :

Voilà, en espérant que çà t'aide.

Merci, toutes les critiques constructives sont intéressantes.


Pour le moment, je n'ai pas prévu d'autre "erreur grave".
J'en ajouterai cependant deux petites : le double-submit et l'avalanche de messages d'erreur.
Si vous connaissez des erreurs fréquentes que j'aurais oubliées... allez-y !

Je vais m'occuper de faire tomber le mythe du tabindex et des accesskeys.
Je pense ensuite attaquer le chappitre comment vérifier efficacement et comment indiquer les données erronées.
En ce qui concerne la vérification des données, j'ai déjà un script externalisé disponible ici.
C'est bien pratique, mais ça ne vaut pas les promesses faites par webforms2 et autres xforms... quand est-ce qu'ils seront supportés ceux-là ?

QuentinC a écrit :
Qu'entends-tu par petite phrase d'exemple ?

Ben, du genre l'utilisation des balises label pour identifier les champs (sémantique), l'utilisation de boutons radio ou de listes pour les choix uniques (technique), etc...

a écrit :
C'est pas une mauvaise idée. Le problème c'est que là après on touche un domaine beaucoup plus vaste : l'utilisation des tableaux en général... et je n'aimerais pas trop m'y risquer.
Ensuite, suivant les infos qu'on a à saisir, un tableau peut être pratique.

Si c'est des données tabulaires, oui, pourquoi pas mais c'est plutôt rare et les formulaires complets qui ne justifient pas l'utilisation d'un tableau sont encore monnaie courante. Celà dit, il est vrai que le tuto ne porte pas là-dessus.

a écrit :
Bien vu. Je vais la mettre, mais avec un avertissement : j'ai ouï dire que la syntaxe avec label englobé n'était pas bien supportée par certains navigateurs.

ok, je ne savais pas.

a écrit :
Faudrait voir où je pourrais caser ce rappel-là. Mais il ne faudrait pas que je me mette à mélanger du script serveur et client, ça risquerait peut-être d'embrouiller le lecteur un peu moins connaisseur.

oui, il ne faut pas développer mais simplement dire qu'un script côté serveur est indispensable, y compris pour les novices... C'est à prévoir avant le JS, ce dernier n'étant là que pour soulager le serveur.

a écrit :
A propos de langage serveur, j'aimerais m'assurer d'un truc : quand on envoie un formulaire par entrée, le champ correspondant au bouton submit n'est pas transmis, non ? Faudrait peut-être que je le signale dans le cadre de l'erreur n°2.

C'est pour çà qu'on ajoute un champ caché et qu'on teste la valeur de ce dernier et non celle du bouton submit... enfin je crois bien, je suis un peu juste en php.

a écrit :
Là, j'avoue ne pas te suivre. Pourquoi onblur ?

Parce qu'ainsi, lorsque tu passes au champ suivant, la vérif' s'effectue direct plutôt que de tout faire à la fin. Tu gagnes un peu en vitesse du fait que tu évites une grosse vérif finale et pour l'utilisateur, ça lui évite de tout taper pour s'apercevoir à la fin qu'il a fait 3, 4 erreurs...

a écrit :
Qu'as-tu testé ?

Sans en être sûr à 100%, je crois bien, si tout le script est en non-intrusif (validation finale comprise), que tu dois passer par un onclick sur le bouton submit et non un onsubmit sur l'élément form.

a écrit :
Heu... rien compris. Je mets le code js directement après le formulaire pour que quand on choisit d'afficher le code directement dans la page, le code js s'affiche aussi.

ben ça nous sert lorsqu'on a besoin de regarder le code source mais sinon, c'est plutôt néfaste. L'avantage que je vois à coder en DOM, c'est le même que pour CSS : Réutilisable sur toutes les pages, allégement du code XHTML, respect de la sémantique, etc...

koala64 a écrit :
C'est pour çà qu'on ajoute un champ caché et qu'on teste la valeur de ce dernier et non celle du bouton submit... enfin je crois bien, je suis un peu juste en php.

Ben si tu veux, mais personellement je vérifies simplement la présence des infos sur un autre champ normal.

koala64 a écrit :

Là, j'avoue ne pas te suivre. Pourquoi onblur ?

Parce qu'ainsi, lorsque tu passes au champ suivant, la vérif' s'effectue direct plutôt que de tout faire à la fin. Tu gagnes un peu en vitesse du fait que tu évites une grosse vérif finale et pour l'utilisateur, ça lui évite de tout taper pour s'apercevoir à la fin qu'il a fait 3, 4 erreurs...

Ah ! Je n'avais pas compris ça comme ça.
Dans ce cas, il va falloir ouvrir un débat là-dessus, car c'est une question épineuse : à mon humble avis, chacune des deux façons se justifie, a ses avantages et ses inconvénients. A discuter... je vais peut-être lancer un sujet dans un autre topic.

koala64 a écrit :

Qu'as-tu testé ?

Sans en être sûr à 100%, je crois bien, si tout le script est en non-intrusif (validation finale comprise), que tu dois passer par un onclick sur le bouton submit et non un onsubmit sur l'élément form.

Je ne vois pas où est le problème. document.forms['nom_formulaire'].onsubmit = function () { ... } fonctionne très bien.

koala64 a écrit :

Heu... rien compris. Je mets le code js directement après le formulaire pour que quand on choisit d'afficher le code directement dans la page, le code js s'affiche aussi.

ben ça nous sert lorsqu'on a besoin de regarder le code source mais sinon, c'est plutôt néfaste. L'avantage que je vois à coder en DOM, c'est le même que pour CSS : Réutilisable sur toutes les pages, allégement du code XHTML, respect de la sémantique, etc...
OK, mais je ne vois quand même pas où tu veux en venir avec ça dans le cadre de mon tuto.

Rendez-vous le week-end prochaîn pour voir les nouvelles modifications. Je vous tiens informé.

Rebonjour,


Orientation vers des techniques Ajax

koala64 a écrit :
Pourquoi onblur ?

Parce qu'ainsi, lorsque tu passes au champ suivant, la vérif' s'effectue direct plutôt que de tout faire à la fin. Tu gagnes un peu en vitesse du fait que tu évites une grosse vérif finale et pour l'utilisateur, ça lui évite de tout taper pour s'apercevoir à la fin qu'il a fait 3, 4 erreurs...

QuentinC a écrit :
Ah ! Je n'avais pas compris ça comme ça.
Dans ce cas, il va falloir ouvrir un débat là-dessus, car c'est une question épineuse : à mon humble avis, chacune des deux façons se justifie, a ses avantages et ses inconvénients. A discuter... je vais peut-être lancer un sujet dans un autre topic.

Est-ce réellement la peine d'ouvrir un autre sujet étant donné que tu traites de comment bien utiliser JS au sein des formulaires ?

A réflexi, je pense que si tu ne t'orientes que sur le onblur, la gestion du formulaire risquerait de devenir trop complexe et s'adresserait alors à un public plus averti ; ce n'est pas la meilleure chose à faire... Néanmoins, une intro à cette technique ne me semble pas mauvaise...

En fait, je vois surtout deux manières différentes de traiter la vérification des données... Soit tu laisses la vérification JS en fin de remplissage des données (juste avant la vérif' PHP), soit tu t'orientes sur une vérif' qui se déroule au fur et à mesure du remplissage, quitte à mettre quelques coups d'Ajax pour les opérations un peu plus longues... On y gagne alors en ergonomie...

Le soucis principal de cette méthode est lorsque cette vérification prend un peu plus de temps... (du genre l'utilisateur commence à remplir le champ suivant et l'avertissement apparaît en cours de route du fait de la longueur du traitement). Pour éviter une surprise désagréable, on peut alors mettre un gif qui lui indique qu'il se passe quelquechose en tâche de fond. Celà dit, comme précisé auparavant, mieux vaut ne pas trop complexifier la chose en laissant Ajax de côté pour l'instant, ce qui évitera de perdre les moins aguerris.

Pour préparer le terrain à un hypothétique tuto sur le sujet, 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...


Externalisation complète du script et modèle objet

QuentinC a écrit :
OK, mais je ne vois quand même pas où tu veux en venir avec ça dans le cadre de mon tuto.

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 ? Doit-on considérer Javascript différemment de CSS en ce qui concerne l'intrusion dans le code HTML ? L'externalisation étant aujourd'hui recommandée, pourquoi continuer à diffuser des tutos... déjà faits ?

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...

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à : Ce n'est pas inaccessible ! Autant en CSS, le message est passé, autant en JS, la route est encore longue pour faire changer les mauvaises habitudes... C'est pour çà que je tente de te motiver à t'orienter là-dessus... Je ne sais pas si tu comprends bien mon point de vue mais je trouve que tant qu'on continuera à ne pas montrer comment bien faire et à ne pas multiplier les sources en DOM, les gens n'évolueront pas et regarderont toujours DOM avec des yeux ronds... 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...

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...
Modifié par koala64 (11 Sep 2006 - 21:13)

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)