5568 sujets

Sémantique web et HTML

Bonjour,

Tout d'abord j'hésitais à placer ma demande dans cette section ou dans celle concernant le Javascript + DOM + API HTML5. Donc désolé si j'ai mal choisi Smiley smile .

Dans le cadre d'une application Web single page et multi onglets, je suis amené à ouvrir plusieurs fois le même onglet dans la même "page".

Ce qui pose le problème de l'unicité des ID.

Donc pour distinguer les champs, j'ai 2 solutions : soit utiliser un préfixe pour les ID d'un même onglet, soit ajouter une classe avec le nom du champ.


<input id="1234321_monchamp">
et
<input id="4321234_monchamp">


et utiliser le JS suivant pour la validation du formulaire :


$("[id$='_monchamp']", $("le_tab_a_valider")).val();


OU


<input class="monchamp">
et
<input class="monchamp">



$(".monchamp", $("le_tab_a_valider")).val();


Je pense que les 2 fonctionnent mais s'il y a une méthode plus propre/performante/recommandée que l'autre, bah je préfère le savoir Smiley biggrin .

Avis aux spécialistes ! Et déjà un grand merci à ceux qui me liront/répondront.

Heriquet
Modérateur
Bonjour

premièrement, je ne comprend pas comment il peut y avoir collision, les champs décrivant autre chose, ils devraient avoir d'autre noms:
au lieu de "date" on aurait par exemple "birth_date", "created_date", etc.

Sinon les frameworks qui permettent de réaliser des applications web, travaillent souvent en mode verbeux pour éviter les collisions: id="nomDuForm_nomDuGroup_nomDuChamp". Après tout dépend de la quantité, de la taille de l'application et de la quantité d'automatisation.

Donc quelques règles à suivre:

1) Trouver une systématique fonctionnelle qui reste toujours la même. Cela permet de retrouver facilement le nom du champ sans y aller à la touchette avec firebug... de rendre les automatismes plus simples pour d'autres languages (javascript nottement)
2) éviter si possible les id numériques. C'est une horreur au débuggage. Et puis j'adore lancer à un collègue: « j'ai un problème de validation pour le champ 23987423_2223_xksdf, tu pourrais y jeter un coup d'oeil» Smiley biggrin
3) Si c'est juste un problème de sélection js, faire encore plus simple: $('#monConteneur input')
En fait il pourrait y avoir collision car le même formulaire peut être ouvert plusieurs fois.

Par exemple un de mes utilisateurs commence l'encodage d'un contrat, puis il recoit un coup de fil d'un client et doit encoder un autre nouveau contrat sans refermer le premier => tu as 2x le même contenu. Voir 3, 4 etc.

Les onglets de l'application étant créés dynamiquement.

L'avantage que j'avais trouvé en utilisant des classes css pour identifier les champs, c'est qu'il n'y a pas de collision car je travaille avec un sélecteur et que sélectionne ce qui se trouve au sein de mon sélecteur. Donc je n'ai pas de doublon.

Et en nommant les classes CSS avec le même nom que le nom de l'élément dans l'objet JSON qui contient les données à modifier, j'arrive à faire des choses comme ceci (en simplifiant) :


			var tmp = this._relation; // json object
			$.each(tmp, function(elem, i) {
				var v = $('.' + elem, DialogAjouterRelation.dialogForm); // javascript class
				if(v.length > 0)
				{
					tmp[elem] = v.val(); 
				}
			});
			
			this._relation = tmp;


Mais il y a parfois des différences entre les bonnes idées et les fausses bonnes idées donc je préfère demander à ceux qui comme toi ont une expérience là-dedans Smiley smile .

Merci pour ta réponse.
Bonjour,

Les classes sont parfaitement adaptés ici. Ta technique avec les id est en fait une astuce pour imiter certaines caractéristiques des classes, donc autant utiliser des classes. Smiley cligne

Une remarque en passant: pas d'attributs name? Il me semble que la valeur de name doit être unique au sein d'un formulaire donné, mais pas pour autant unique dans le document. Donc name est peut-être bien la meilleure solution.
Heriquet a écrit :
En fait il pourrait y avoir collision car le même formulaire peut être ouvert plusieurs fois.

On dira plutôt qu'il peut y avoir plusieurs formulaires sur le même modèle, ou plusieurs instances d'un modèle de formulaire.

(Un formulaire donné dans le DOM peut être «ouvert» plusieurs fois si on le masque ou l'affiche plusieurs fois successivement dans le temps, par exemple.)
C'est exactement ca.

D'autant que je compte utiliser backbone.js comme librairie MCV et que mon formulaire sera une classe JS qui instanciera plus que probablement des objets "formulaire". (en gros résumé)

Certains formulaire seront affichés/masqués et d'autres seront dupliqués. En fonction de leur role.

Je pense utiliser Mustache.js pour le templating. Donc j'aurais des objets JS sous forme de classes JS + template HTML.

C'est un peu "hybride" tout ca mais je pense que c'est la direction dans laquelle il faut aller, en tout cas pour ce que je dois faire.

J'ai déjà fait quelques tests avec cette technique et si ce n'est pas absolument parfait en touts points, c'est très performant et répond aux besoins/critères de mon équipe.

Nota :

a écrit :
Lu sur le site du W3C : A control's "control name" is given by its name attribute. The scope of the name attribute for a control within a FORM element is the FORM element.


=> name pourrait effectivement être aussi une solution, voir devrait être la solution Smiley smile .

Seule petite objection, si le formulaire contient une sous-liste d'éléments (par exemple un formulaire "company" qui demande l'encodage d'une liste de "employee", on va avoir plusieurs lignes d'employees (si on se limite de demander nom et prénom) et donc des doublons au sein du formulaire non ?). Je cherche la petite bête mais je veux être absolument certain d'avoir LA solution.

Merci pour tes infos fvsch.