Hello et la vapeur,
la vapeur c’est parce que vous allez fumer de la tête
Bon, soyons sérieux deux petites secondes, je me reprend.
Un problème connu des applications web, c’est que HTTP est State-Less (sans état), et même les Cookies ne résolve rien à ce problème, parce qu’il sont globaux à une cession. C’est un problème, parce que la notion d’état, est la base de la manière standard d’aborder la conception d’une application.
Il se pose des problèmes par exemple quand un utilisateur soumet plusieurs fois un même formulaire, reviens en arrière et resoumet une première étape après avoir soumis la deuxième, garde en suspend une troisième étape qu’il resoumet des heures après, etc.
C’est le sujet d’un papier sous forme d’une petite thèse, in english : Re-inverser l’inversion de contrôle, ou la programmation basée sur la continuation [*] plutôt que sur les pages (en)
[*] La continuation, c’est une notion de certain langage de programmation (possible en JavaScript par exemple, même s’il faut la faire à la main).
Je vous fait un résumé, parce que l’auteur à l’art d’expliquer d’une manière compliquée des choses simples et naturelles, ce qui m’a fait pensé à une citation de Desproges que j’ai justement posté sur un forum récemment : « Quand un philosophe me répond, je ne comprend plus ma question ».
Pour être simple, la papier suggère que plutôt que de voir le résultat d’une opération comme étant la suite de l’opération précédente, elle même résultat d’une série d’états précédents, il faut voir le résultat d’une opération, comme le calcul d’un résultat à partir d’un seul état dans lequel on trouve tout ce qui est nécessaire au calcul de ce résultat (et ce calcul, n’est pas nécessairement mathématique hein !).
Exemple : au lieu voir somme(somme(1,2), 3), voir somme(1,2,3).
(je l’ai toujours vu comme ça, vu que je considère une page web comme une source de donnée)
Pour lire en survolant, je vous recommande d’aller directement au chapitre 3 qui présente le contexte, de passer au chapitre 5 qui présente le problème et de filer au chapitre 7, qui présente une solution dans des termes concrets.
Mais ce n’est pas une solution miracle non-plus, parce que comme le dit le passage 7.2, ça pose la question de la quantité d’information qu’il faut attacher à chaque « état » qui sont maintenant dissociés les uns des autres (ce n’est pas pour rien si la Contunation est plus utilisée en théorie qu’en pratique dans la programmation). Mais en pratique, il ne devrait pas y avoir de quoi s’inquiéter, parce que si la quantité d’information à associer à chaque page est trop importante, c’est probablement le signe que c’est la fonctionnalité de l’application qui a un problème.
Pour répondre à la question posé dans 7.1, je suis plutôt 100% partisan d’un stockage au sein de la page elle-même : c’est toujours mieux de garder des URL propres, et puis y a des limites à les surcharger, leur capacité limite est rapidement atteinte.
Une autre manière de voir les choses, ce serait de se dire que l’application web s’exécute indépendamment dans chaque page. En JavaScript côté client, c’est parfaitement banal, mais côté serveur, ça nécessite d’associer un état à chaque page, plutôt que d’associer un état à une cession. Et c’est justement en gros la conclusion de ce papier.
Modifié par hibou57 (09 Aug 2010 - 04:59)
la vapeur c’est parce que vous allez fumer de la tête
Bon, soyons sérieux deux petites secondes, je me reprend.
Un problème connu des applications web, c’est que HTTP est State-Less (sans état), et même les Cookies ne résolve rien à ce problème, parce qu’il sont globaux à une cession. C’est un problème, parce que la notion d’état, est la base de la manière standard d’aborder la conception d’une application.
Il se pose des problèmes par exemple quand un utilisateur soumet plusieurs fois un même formulaire, reviens en arrière et resoumet une première étape après avoir soumis la deuxième, garde en suspend une troisième étape qu’il resoumet des heures après, etc.
C’est le sujet d’un papier sous forme d’une petite thèse, in english : Re-inverser l’inversion de contrôle, ou la programmation basée sur la continuation [*] plutôt que sur les pages (en)
[*] La continuation, c’est une notion de certain langage de programmation (possible en JavaScript par exemple, même s’il faut la faire à la main).
Je vous fait un résumé, parce que l’auteur à l’art d’expliquer d’une manière compliquée des choses simples et naturelles, ce qui m’a fait pensé à une citation de Desproges que j’ai justement posté sur un forum récemment : « Quand un philosophe me répond, je ne comprend plus ma question ».
Pour être simple, la papier suggère que plutôt que de voir le résultat d’une opération comme étant la suite de l’opération précédente, elle même résultat d’une série d’états précédents, il faut voir le résultat d’une opération, comme le calcul d’un résultat à partir d’un seul état dans lequel on trouve tout ce qui est nécessaire au calcul de ce résultat (et ce calcul, n’est pas nécessairement mathématique hein !).
Exemple : au lieu voir somme(somme(1,2), 3), voir somme(1,2,3).
(je l’ai toujours vu comme ça, vu que je considère une page web comme une source de donnée)
Pour lire en survolant, je vous recommande d’aller directement au chapitre 3 qui présente le contexte, de passer au chapitre 5 qui présente le problème et de filer au chapitre 7, qui présente une solution dans des termes concrets.
Mais ce n’est pas une solution miracle non-plus, parce que comme le dit le passage 7.2, ça pose la question de la quantité d’information qu’il faut attacher à chaque « état » qui sont maintenant dissociés les uns des autres (ce n’est pas pour rien si la Contunation est plus utilisée en théorie qu’en pratique dans la programmation). Mais en pratique, il ne devrait pas y avoir de quoi s’inquiéter, parce que si la quantité d’information à associer à chaque page est trop importante, c’est probablement le signe que c’est la fonctionnalité de l’application qui a un problème.
Pour répondre à la question posé dans 7.1, je suis plutôt 100% partisan d’un stockage au sein de la page elle-même : c’est toujours mieux de garder des URL propres, et puis y a des limites à les surcharger, leur capacité limite est rapidement atteinte.
Une autre manière de voir les choses, ce serait de se dire que l’application web s’exécute indépendamment dans chaque page. En JavaScript côté client, c’est parfaitement banal, mais côté serveur, ça nécessite d’associer un état à chaque page, plutôt que d’associer un état à une cession. Et c’est justement en gros la conclusion de ce papier.
Modifié par hibou57 (09 Aug 2010 - 04:59)
