Archive pour mars 2009

Quand les bonnes pratiques se contredisent…

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

Références bibliographiques

, , ,

3 commentaires

Asp.Net tue le programmeur web

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 GET et POST?
  • Qu’est-ce que la balise <select ...>?
  • Qu’est-ce que l’évènement submit en 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
génère coté client?
. En fait, plus souvent qu’autrement, ces contrôles génèrent
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.

Liens d’intérets

,

Un commentaire