Il est plus que temps que je commence à vous parler de WebDev ! Et comment mieux commencer qu'avec cet article sur la différence de philosophie de développement entre WebDev et WinDev. La philosophie WebDev est TRES différente de la philosophie 'normale' WinDev. Si vous n'en êtes pas conscient, les problèmes vous attendent.

Le passage de WinDev à WebDev devrait être sans douleur, et sur beaucoup de plans, il l'est. Un gros problème reste : la philosophie du développement. Cela peut paraître un grand mot, mais vous allez voir que considérer les choses sous cet angle peut vous faire faire des progrès très rapides.

Lors du développement d'un programme classique (avec WinDev par exemple), le développeur a littéralement tout sous la main : le code et l'interface sont fondues l'un dans l'autre, et tout est toujours accessible…

Dés qu'on ouvre l'éditeur de code de WebDev, on se rend compte qu'il se passe quelque chose : code navigateur d'un coté, code serveur de l'autre, fonctions disponibles d'un coté et pas de l'autre, ordre d'exécution des codes… Il y a de quoi se poser des questions, et à juste titre…

WebDev essaye d'atténuer les difficultés de programmation 'web' et il y réussit sur bien des points (voir article sur le mode AWP, en particulier)… Mais il n'en demeure pas moins que sans un mode de raisonnement différent, vos sites WebDev vous feront tourner en bourrique.

La grosse différence qu'il faut réussir à se mettre en tête, c'est qu'un site Web n'est PAS un programme… Même si du code est exécuté !

Un site web, c'est plutôt une collection de programmes qui discutent entre eux :
- un gros (c'est le programme exécuté sur le serveur)
- plein de petits (c'est chaque page html, exécutée indépendamment sur la machine client, en javascript)

Si vous arrivez à penser de cette façon, tout va s'éclaircir :
- toutes les zones code navigateur d'une page sont en fait un petit programme quasi indépendant
- les zones code serveur d'une page sont une partie du gros programme…

En fait, par rapport à un programme traditionnel, c'est un peu comme si chaque fenêtre était compilée dans un exe séparé, et que tout le code d'accès aux fichiers et autre soit dans un gros exe à part… Ajoutez des communications entre eux, et voila…

Mais prenons un exemple concret : info(" MonMessage ") est une instruction des plus basiques… Mais si vous l'utilisez sans y réfléchir sérieusement en code serveur, elle ne va pas s'exécuter… En tout cas pas tout de suite… Elle ne s'exécutera que lorsque la prochaine page sera envoyée du serveur à la machine cliente ou tout affichage a lieu.

Donc, quand en WinDev un info est bloquant, il ne l'est pas en WebDev code serveur… Surprise ! En tout cas si vous continuer à penser en terme de programmation classique !

Par contre, si vous avez en tête des programmes séparés, ça devient parfaitement normal…

Prenons un autre exemple :
Dans une page, vous voulez afficher certains champs en fonction des actions de l'utilisateur. Jusque la tout est simple, nous sommes en plein cas de code navigateur…

Mais vos conditions dépendent aussi du contenu de certains fichiers. Ce qui signifie que vous devez envoyer les actions utilisateurs (cases cochées par exemples) au serveur pour examiner des fichiers… Nous parlons donc maintenant de code serveur…

C'est le mélange des deux qui va poser problème si vous n'y pensez pas de la bonne façon… Combien de fois voit-on passer sur des forums des questions sur la façon d'exécuter du code navigateur depuis le serveur…

Voici comment les choses doivent se passer :
- l'utilisateur clique sur des cases à cocher
- cette information est envoyée au serveur par le biais d'un bouton 'submit' ou de code que vous avez caché dans les champs en question
- le serveur examine les fichiers, compare avec les valeurs des champs, et décide de faire apparaître trois nouveaux champs, d'y afficher des messages, de passer de nouvelles valeurs à une applet java, etc…
- le serveur prépare donc le travail, en mettant des flags (variable globales par exemple) à une certain valeur, en stockant des valeurs à afficher, etc
- le serveur REaffiche la page initiale
- Dans le code d'init de la page, en fonction des valeurs des flags et des variables globales, du code conditionnel va faire apparaître les champs, passer des valeurs à une applet java, etc, etc,…

Bien sur, ce fonctionnement a provoqué un réaffichage de la page (c'est cet effet de flash très disgracieux commun sur la plupart des pages webs)… Et la réponse à ce problème la est… AJAX… Mais un petit conseil… Si vous en êtes encore au stade ou vous avez du mal à concevoir un site web comme je viens de l'expliquer, oubliez ajax pour l'instant…

Faite du classique, comprenez BIEN comment ça se passe, et on parlera d'ajax plus tard…

Compliqué ? Oui et non… Encore une fois, la philosophie de la chose est deux programmes qui dialoguent via le web… Imaginez les deux ordinateurs reliés par deux modems et vous vous ferez une bien meilleure idée de ce qui doit être fait ou…

Prenons un autre exemple des différences profondes entre un programme classique et un site web… Dans un programme classique, il n'est pas rare d'avoir une fenêtre principale qui ouvre des fenêtres secondaires qui ouvrent des fenêtres tertiaires, etc… Si ces fenêtres sont modales, l'utilisateur ne peut accéder qu'à une fenêtre à la fois et revient forcémnt sur ses traces… Si elles ne sont pas modales, en général, l'utilisateur est perdu, donc revoyez votre interface…

Dans un site web, vous pouvez aussi ouvrir de multiples navigateurs (ou des popup)… Mais la notion de fenêtre modale n'existe pas… Ce qui a deux conséquences :
- l'utilisateur peut agir sur n'importe laquelle de ces fenêtres, avec les risques que l'on connaît sur les traitements de votre appli
- s'il a le choix, l'utilisateur ira sur un AUTRE site web que le votre, ou l'interface sera moins compliquée… Les utilisateurs ont HORREUR des popups.

Pensez donc à votre application web comme un programme qui n'a qu'une fenêtre ouverte à la fois… Tout ce qui est nécessaire à votre traitement devrait donc se trouver dans des variables globales (ou de classes) et dans la fenêtre courante… Ne comptez sur rien d'autre que ça et tout ira bien mieux…