Archives de la catégorie Bonnes pratiques
Champ texte avec indice (Textbox hint) de façon accessible
Posté par Jimmy dans Accessibilité, Bonnes pratiques le 29 juin 2010
Il est question ici du texte qui est affiché lorsqu’une zone de texte est vide et disparaît lorsque cette zone est sélectionnée ou si elle contient du texte.
Il existe plusieurs solutions sur le web mais la majorité du temps ça consiste à modifier la valeur de la zone de texte. Ceci cause un problème pour les lecteurs d’écran car l’indice ne sera pas lu comme un texte d’aide tel un label html mais plutôt comme la valeur de la zone de texte. En plus ces solutions demandent une gestion supplémentaire de la valeur de la zone de texte lorsque le formulaire est soumit au serveur.
En html5 ce problème sera résolu avec l’attribut placeholder. Voici un exemple avec placeholder.
Par contre voici, pour l’instant, une alternative qui utilise un label html pour créer l’indice sur la zone de texte.
Le fonctionnement
Le principe est simple. Il suffit de déplacer le label html par dessu la zone de texte. Lorsque la zone est sélectionnée l’indice est caché. Quand la zone perd sa sélection et que celle-ci est vide on ré-affiche l’indice.
Puisqu’un clique sur le label sélectionne la zone de texte il n’est pas nécessaire de gérer le clique sur le label.
Le code
Html
<div>
<label for="emailName">Nom</label>
<input type="text" id="emailName" />
</div>
<div>
<label for="emailaddress">Adresse</label>
<input type="text" id="emailaddress" />
</div>
Javascript (jQuery) et Explications
$("label").each(function () {
//Aller chercher le label et la boîte de texte
var lbl = $(this);
var inputText = $("#" + lbl.attr("for"));
//Créer un conteneur "DIV" qui permettra de positionner correctement le label et la zone de texte
var textboxDivWrapper = $("<div></div>");
textboxDivWrapper.css("position", "relative");
textboxDivWrapper.css("display", inputText.css("display"));
inputText.wrap(textboxDivWrapper);
inputText.before(lbl);
lbl.css("position", "absolute");
lbl.css("left", "0");
//Un peu d'esthétisme
lbl.css({ "color": "#888", "padding": "2px 0px 0px 10px" });
//Simuler du texte lors du "mouse-over" sur le label
lbl.css("cursor", "text");
//Utilisé "left: "-9999" au lieu du "hide()" : Afin que les lecteurs d'écran puisse dicter l'indice.
//La méthode "hide()" à pour résultat d'assigné "display: none" ce qui à pour effet
// de cacher l'indice autant pour le visuel que pour les lecteurs d'écran.
// Donc dans le but que l'indice puisse être lu par les lecteurs d'écran
// il faut simplement sortir le label de l'écran.
inputText.focus(function () {
lbl.css("left", "-9999");
});
inputText.blur(function () {
if ($(this).val().length == 0) {
lbl.css("left", "0");
}
});
});
Plugin jQuery
Voici le même code javascript en version plugin jQuery.
(function ($) {
$.fn.labelToHint = function (options) {
var defaults = {
hintCss: { "color": "#888", "padding": "2px 0px 0px 10px" }
};
var options = $.extend(defaults, options);
return this.each(function () {
var lbl = $(this);
var inputText = $("#" + lbl.attr("for"));
var textboxDivWrapper = $("<div></div>");
textboxDivWrapper.css("position", "relative");
textboxDivWrapper.css("display", inputText.css("display"));
inputText.wrap(textboxDivWrapper);
inputText.after(lbl);
lbl.css("position", "absolute");
lbl.css("left", "0");
lbl.css(options.hintCss);
lbl.css("cursor", "text");
inputText.focus(function () { lbl.css("left", -9999); });
inputText.blur(function () {
if ($(this).val().length == 0) {
lbl.css("left", "0");
}
});
});
};
})(jQuery);
Cliquer ici pour voir un exemple.
Conclusion
Vous pouvez faire votre propre code pour le positionnement et l’apparence du libellé. Ce que je voulais démontrer ici est qu’il est possible d’afficher un indice sur un zone de texte sans modifier la valeur du texte.
Ajax à son plus simple avec Asp.Net
Posté par Jimmy dans Bonnes pratiques le 12 mai 2009
Asp.Net contient plusieurs contrôles permettant de faire du Ajax. Je ne les ai pas testés, mais j’aime bien connaître et contrôler ce qui se passe en arrière plan. C’est pourquoi j’ai décidé d’étudier comment faire du Ajax et de me faire quelques outils pour avoir plein contrôle de la communication client-serveur en Ajax.
Côté serveur
En réalité, côté serveur, il n’y a pas de différence entre une requête normale ou une requête Ajax. Ce qui est important c’est d’avoir le contrôle du texte qui sera retourné au client. Ma première idée était de créer une page aspx et de surcharger la méthode Render. Dans cette méthode il suffit de faire Response.Write("le texte de retour"); et de ne pas appeler base.Render();. Ça fonctionne, mais ce n’est pas très élégant.
Une meilleure méthode est d’utiliser un httpHandler. Pour en savoir plus sur les httpHandler, voici quelques articles intéressants.
Rien ne sert d’expliquer comment faire fonctionner un httpHandler, car ces articles le font très bien. Par contre, je vais démontrer comment l’utiliser pour répondre facilement à une requête Ajax.
Voici, un peu simplifié, ce que fait la méthode ExecuteRequest.
string[] arrPath = context.Request.Path.Split('/');
string pageMethod = Path.
GetFileNameWithoutExtension(arrPath[arrPath.Length - 1]);
string className = "ExempleAjax.Ajax." + pageMethod;
IAjaxRequest pageRequest = (IAjaxRequest)System.Reflection.
Assembly.GetExecutingAssembly().CreateInstance(className, true);
pageRequest.ExecuteRequest(context);
La méthode extrait la partie de l’URL qui sera, en réalité, le nom de la classe à instancier. Cette classe hérite d’une interface qui contient une seule méthode : ExecuteRequest. Son utilité est de prendre en charge la requête, aller chercher l’information nécessaire et retourner le texte qui sera interprété en Javascript par le client.
De cette façon si on veut créer une nouvelle méthode Ajax il suffit d’ajouter une nouvelle classe et d’implémenter l’interface IAjaxRequest.
Côté client
Il est possible de tester la méthode simplement en inscrivant l’URL dans un fureteur. Pour l’utiliser, voici quelques sites qui expliquent comment faire du Ajax.
Par contre, j’aime bien concevoir des outils pour rendre efficace le développement. Donc voici une classe en Javascript qui aidera à faire du Ajax : AjaxHelper.js
Pour l’utiliser, il suffit d’instancier la classe pour ensuite définir les méthodes :
var ah = new AjaxHelper();
ah.OnAjaxRequestComplet = function(txt) {alert(txt);};
ah.StartRequestProcessGET("/HelloWorld.ajax", null);
Voici l’exemple Hello world complet fait avec Visual Studio 2008 : ExempleAjax.zip
Liens d’intérets
Quand les bonnes pratiques se contredisent…
Posté par Samuel Sirois dans Bonnes pratiques le 16 mars 2009
Les standards ouverts du Web aident et facilitent le développement d’applications Web. Ils sont nombreux et il arrive que certaines bonnes pratiques recommandées par un standard contreviennent au respect d’autres bonnes pratiques définies par un autre standard.
Le cas des bonnes pratiques d’internationalisation en est un bon exemple. Du point de vue des bonnes pratiques du protocole HTTP, il est recommandé qu’à une ressource, une seule adresse lui soit associée. Du point de vue des bonnes pratiques de développement pour l’optimisation d’un site Web pour les moteurs de recherches [SEO], il est de bon aloi d’inclure des mots clefs à même l’URI. Il est donc tout à fait normal que l’adresse d’un document écrit en russe, par exemple, ne se retrouve pas à la même adresse que la version française du même document.
Le protocole HTTP
Le protocole HTTP prévoit un code 300 lorsque plusieurs documents correspondent à un URI demandé. Ainsi, pour plusieurs traductions d’un même document, un seul URI existe. Ce n’est pas un hasard si ce code est prévu à l’intérieur du protocole HTTP. Il est important de pouvoir localiser un certain contenu à partir d’une adresse et, si un document est disponible en plusieurs formats ou plusieurs langues, une réponse HTTP avec un code 300 fournit une liste des options sous forme d’URI. Cela simplifie grandement les échanges d’informations.
Une ressource, une adresse.
En configurant mon navigateur Web de façon adéquate, il est possible d’indiquer aux différents serveurs Web les préférences linguistiques de l’agent Web – le navigateur. Par exemple, si un hispanophone envoie l’URL d’un article qu’il a lu à un francophone, en naviguant vers cette URL, il sera possible pour le francophone d’y voir la version française de façon automatique.
Il est beaucoup plus convivial d’échanger une adresse comme « http://www.w3.org/International/questions/qa-i18n.html » que d’avoir à transformer une adresse comme « http://www.w3.org/International/questions/qa-i18n.es.php » et de trouver l’équivalent en anglais « http://www.w3.org/International/questions/qa-i18n.en.html » avant d’envoyer l’hyperlien!
Pour ceux qui souhaiteraient voir le code HTTP 300 dans toute sa splendeur, vous pouvez vous diriger vers l’adresse suivante : http://www.w3.org/International/questions/qa-i18n.php.
Les bonnes pratiques d’optimisation pour les moteurs de recherches
Une bonne pratique d’optimisation d’un site Web pour les moteurs de recherches est d’utiliser des mots clefs pertinents dans la structure même d’un site Web – donc dans l’adresse d’une ressource.
Par exemple, un article sur l’internationalisation devrait se retrouver à l’adresse « http://www.exemple.com/articles/internationalisation.html ». Et comme « articles » et « internationalisation » s’écrivent de la même façon en anglais et en français, il n’y a pas de problème.
Qu’en est-il de la traduction dans une autre langue? Prenons l’exemple du chinois. Afin d’optimiser le référencement sur « http://www.google.cn/, il faudrait très certainement traduire les mots « articles » et « internationalisation » en chinois.
Une ressource, plusieurs adresses.
Là où le bât blesse…
Le hic, c’est qu’en voulant respecter une bonne pratique d’optimisation pour les moteurs de recherches, voilà que nous ne respectons plus un principe de base souhaité par l’inventeur du Web lui-même, Tim Berners-Lee.
Un vent de popularité des bonnes pratiques de développement Web souffle en ce moment sur la communauté de développement Web, tant auprès des intégrateurs que des développeurs. L’évolution du Web est exponentielle et nous voyons émerger de bonnes pratiques auxquelles il aurait été même impossible de penser il y a de cela aussi peu que cinq ans, les technologies sur lesquelles reposent ces bonnes pratiques n’existant même pas à ce moment.
Nul n’est besoin de répéter ici l’ensemble des bénéfices de l’utilisation des bonnes pratiques de développement pour le succès d’un projet, mais serait-il possible que les bonnes pratiques deviennent victimes de leur propre succès? En rédigeant trop rapidement ces pratiques, des incohérences comme celle mise en lumière dans cet article peuvent apparaitre.
Se pourrait-il que la différence entre un développeur Web et un bon développeur Web ne réside plus dans sa capacité à respecter les bonnes pratiques de développement, mais bien dans sa capacité de bien déterminer et prioriser, selon le projet, les bonnes pratiques à utiliser?
Liens d’intérets
- An Introduction to Multilingual Web Addresses
- Introducing Character Sets and Encodings
- La norme HTTP 1.1 [en anglais]
Références bibliographiques
Asp.Net tue le programmeur web
Posté par Jimmy dans Bonnes pratiques le 12 mars 2009
En premier lieu je tiens à mentionner que je ne suis pas contre le Asp.Net.
Je programme depuis des années en Asp.Net/C# et j’adore ça.
Par contre, j’ai eu la chance, et oui je dis bien « la chance »,
de commencer le développement web en ASP 3.
L’idée d’écrire cet article me vient du fait que j’ai reçu quelques questions telles que :
- Comment fait-on pour accéder à une variable du code-behind en javascript?
- Pourquoi je perds la valeur de mes variables du code-behind suite à un post-back?
- (D’un programmeur Asp.Net qui a du faire de la maintenance sur du ASP 3) Comment je fais un « validateur »?
En plus, je vous suggère de demander à un programmeur Asp.Net
- Quel est la différence en
GETetPOST? - Qu’est-ce que la balise
<select ...>? - Qu’est-ce que l’évènement
submiten html?
… il ne devrait pas avoir beaucoup de réponse.
Ce qui m’a fait réaliser que beaucoup de programmeurs ont fait du développement
web seulement avec Asp.Net et beaucoup parmi eux ne connaissent pas vraiment le
principe du web. Donc je me suis dit que je devais mettre en garde les programmeurs
dont leur seule expérience web est le Asp.Net.
D’abord, je tiens à clarifier que le web n’est rien d’autre qu’une requête TEXTE
qui est envoyée d’un client à un serveur et le serveur renvoie une réponse TEXTE
qui est interprétée par le client. Une fois que vous avez bien compris ce concept, il sera
beaucoup plus facile de faire du bon développement web. Ça semble si simple et pourtant…
Asp.net a su abstraire cette notion de façon assez efficace. Et comment il le fait :
Le fameux viewstate
Je dois reconnaître que grâce au viewstate et les nombreux contrôles
de Asp.Net il est très rapide de concevoir un formulaire. Pour récupérer l’information
il suffit de faire
myTextbox.Text;
myDropDownList.SelectedValue;
myCheckBox.Checked;
Par contre en HTML ces contrôles n’existent pas (je viens sûrement d’en surprendre plusieurs),
du moins pas de la manière dont Asp.Net nous les présentent. Je ne vais pas écrire
les bons et mauvais côtés du viewstate, car ce n’est pas le but
de cet article. Grâce au viewstate et les contrôles Asp.Net
beaucoup trop de programmeurs ne se posent pas la question : Qu’est-ce que ce contrôle
. En fait, plus souvent qu’autrement, ces contrôles génèrent
génère coté client?
plus de texte qu’on en a besoins, en plus ils augmentent le viewstate.
Je le sais, car quand j’ai commencé avec Asp.Net je suis tombé dans le piège.
En Asp.Net tout est un POST
Tout post-back est fait avec la méthode HTTP
POST. C’est à dire : le OnClick sur n’importe quel contrôle Asp.Net, le
sort ou le PageIndexChange pour un DataGrid ou
GridView bref environ tout évènement Asp.Net. Le problème est que le
POST en HTTP est plus lourd que le GET et surtout ils n’ont pas la
même fonction.
GET: C’est la méthode la plus courante pour demander une ressource.
Une requête GET est sans effet sur la ressource, il doit être possible de répéter la
requête sans effet.
POST: Cette méthode doit être utilisée pour ajouter une nouvelle
ressource (un message sur un forum ou un article dans un site).
L’URI fournie est l’URI
d’une ressource liée à la nouvelle ressource (comme l’URI du forum ou site)
et non l’URI de la ressource nouvellement crée.source :
Wikipedia
http://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol
Asp.Net utilise de façon assez abusive le POST. Le problème, encore une fois,
c’est qu’aucun programmeur Asp.Net ne va se poser la question :
Est-ce que j’ai besoin du
.GET ou du POST?
Effectivement qu’ils ne se posent pas la question, ils ne peuvent même pas contrôler
ce qu’ils utilisent.
Asp.Net = développement rapide d’application… vraiment ?
Un autre grand problème est qu’il peut être difficile de créer certaine interface
en Asp.Net alors qu’il est si facile de le faire directement en HTML. Par exemple,
faire une liste de boutons radio à l’aide d’un Repeater.
Je sais que le RadioButtonList existe mais parfois le Repeater
est plus pratique. De base il est impossible de faire fonctionner la liste de boutons radio
avec le Repeater. Si on cherche sur Internet, la solution la plus fréquente
est d’utiliser du javascript. Tant qu’a moi la solution la plus simple est d’inscrire directement
dans le Repeater : <input type=radio name=myRadio value=... />
afin de créer la liste de boutons de radio. Ensuite pour récupérer la valeur du bouton sélectionné
il suffit de faire Request.Form["myRadio"]. Ceci est l’équivalent de faire du bon
vieux développement web.
En fait, il suffit de générer du texte qui, côté client, est interprété soit comme du HTML,
du javascript ou simplement des données qui serviront à faire du Ajax. L’idée est que c’est
seulement du TEXTE.
En résumé, je ne dis pas de ne plus utiliser les contrôles Asp.Net car il est vrai que ces
contrôles accélèrent le développement, mais de se poser la question Est-ce que j’ai vraiment
.
besoins d’un contrôle Asp.Net? Serait-ce plus simple d’écrire directement du HTML?
Voici quelques réflexions :
Est-ce que le asp:HyperlinkField ou le asp:LinkButton est vraiment
nécessaire? Ou il est possible simplement de faire
<a href="lapage.aspx">Le page</a>.
Au lieu de créer une page avec beaucoup de asp:Panel peut-être qu’il serait
mieux de créer plusieurs pages qui seront plus légères.
Le GridView (ou DataGrid) est lourd, peut-être il
serait mieux d’utiliser le Repeater. Pour afficher une liste de texte
il peut être utile d’utiliser le BulletList.
Le asp:Label est très utile mais parfois il est plus utile de faire
<%= UneVariableProtectedProvenantDuCodeBehind %> directement dans la page .aspx
Le meilleur truc :
Pour ceux qui ont seulement programmé avec Asp.Net apprenez ASP 3 ou PHP, tenter de
reproduire le principe d’un DataGrid avec pagination, ordonnancement et recherche
et faites un formulaire avec des validations. Après avoir fait ce travail vous
pourrez vous considérer un vrai programmeur web.