par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la programmation
evenementielle, mais ca me donne l'impression que je code comme un porc...
exemple :
ca se soigne ? si oui, comment ? j'ai tente de faire des fonctions, comme en
programmation imperative, mais ca colle pas trop a la logique... exemple :
l'affichage des donnees ne doit se faire que lorsque la fonction
sauvegarder_donnees() aura recu le retour de son appel ajax. donc, cet
affichage est defini A L'INTERIEUR de la fonction sauvegarder_donnees(); par
consequent, logiquement, le nom de la fonction est faux. il faudrait plutot la
nommer comme ca :
mais bon, ca veut dire que la fonction n'a pas une tache unique, et plus le
programme grossit, plus j'ai des fonctions qui font 50 taches, plus j'ai du mal
a decouper le programme en petites entites simples.
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la programmation evenementielle, mais ca me donne l'impression que je code comme un porc... exemple :
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la
programmation
evenementielle, mais ca me donne l'impression que je code comme un porc...
exemple :
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la programmation evenementielle, mais ca me donne l'impression que je code comme un porc... exemple :
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la programmation evenementielle, mais ca me donne l'impression que je code comme un porc... exemple :
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la
programmation
evenementielle, mais ca me donne l'impression que je code comme un porc...
exemple :
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la programmation evenementielle, mais ca me donne l'impression que je code comme un porc... exemple :
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la programmation evenementielle, mais ca me donne l'impression que je code comme un porc... exemple :
Je ne comprends pas cet exemple (il est vrai que je ne parle pas le jquery ...) tu fais appeler de l'ajax par de l'ajax et encore et encore ???? ça ne peut se traiter en 1 fois côté serveur ?
Là, chez moi à la campagne, je sens que je vais pouvoir m'énerver en attendant que les ajaxionnages aient fini leurs allers et retours (entre chez moi et le serveur et à travers mon mauvais ADSL)
ca se soigne ? si oui, comment ?
on jette jquery ou bien on tente de ne pas en rester/devenir esclave ?
j'ai tente de faire des fonctions, comme en programmation imperative, mais ca colle pas trop a la logique...
non ! récup(|) +----> sauve(|) +----> affiche() À mon idée, l'ajaxionnage n'a rien à y voir question découpe des fonctions
l'affichage des donnees ne doit se faire que lorsque la fonction sauvegarder_donnees() aura recu le retour de son appel ajax.
oui if (httpRequest.status == 200) { affiche() } else alert('kput');
donc, cet affichage est defini A L'INTERIEUR de la fonction sauvegarder_donnees(); par consequent, logiquement, le nom de la fonction est faux. il faudrait plutot la nommer comme ca :
ben non, à L'INTERIEUR il n'y a pas à définir la fonction, il n'yaka l'appeler, hop !
jquery ça déforme l'entendement ! à croire.
revoir le B A BA du httpRequest ? <https://developer.mozilla.org/fr/docs/AJAX:Premiers_pas>
mais bon, ca veut dire que la fonction n'a pas une tache unique,
si, la fonction de récup des données peut être assez unique, (on lui passe les paramètres (où trouver les données) l'url vers où envoyer et un indice pour la fonction à employer en fin de job).
Celle d'affichage ... ça dépend de ce qui est récupéré à la suite de la requête si c'est du HTML il n'y a qu'à l'innerHTLMLer si c'est du fragment DOM, yaka l'appender ou la childRemplacer
plus le programme grossit, plus j'ai des fonctions qui font 50 taches,
Ha Ben ! Pour sûr. (50 taches ou 50 fonctions ... ce qui revient à du pareil au même, non?)
plus j'ai du mal a decouper le programme en petites entites simples.
Quand on jQuerie on n'emploie plus le mot "simple" ! ! ! c'est antinomique !
-- Stéphane Moriaux avec/with iMac-intel
Le 27/11/12 13:30, luc2 a écrit :
bonjour,
Salut Lucedé,
en programmation imperative, si on fait beaucoup de fonctions, le code parait
lisible, propre, simple... exemple :
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la programmation
evenementielle, mais ca me donne l'impression que je code comme un porc...
exemple :
Je ne comprends pas cet exemple
(il est vrai que je ne parle pas le jquery ...)
tu fais appeler de l'ajax par de l'ajax et encore et encore ????
ça ne peut se traiter en 1 fois côté serveur ?
Là, chez moi à la campagne, je sens que je vais pouvoir m'énerver en
attendant que les ajaxionnages aient fini leurs allers et retours (entre
chez moi et le serveur et à travers mon mauvais ADSL)
ca se soigne ? si oui, comment ?
on jette jquery
ou bien on tente de ne pas en rester/devenir esclave ?
j'ai tente de faire des fonctions, comme en
programmation imperative, mais ca colle pas trop a la logique...
non !
récup(|)
+----> sauve(|)
+----> affiche()
À mon idée, l'ajaxionnage n'a rien à y voir question découpe des fonctions
l'affichage des donnees ne doit se faire que lorsque la fonction
sauvegarder_donnees() aura recu le retour de son appel ajax.
oui
if (httpRequest.status == 200) {
affiche()
}
else alert('kput');
donc, cet
affichage est defini A L'INTERIEUR de la fonction sauvegarder_donnees(); par
consequent, logiquement, le nom de la fonction est faux. il faudrait plutot la
nommer comme ca :
ben non, à L'INTERIEUR il n'y a pas à définir la fonction, il n'yaka
l'appeler, hop !
jquery ça déforme l'entendement ! à croire.
revoir le B A BA du httpRequest ?
<https://developer.mozilla.org/fr/docs/AJAX:Premiers_pas>
mais bon, ca veut dire que la fonction n'a pas une tache unique,
si, la fonction de récup des données peut être assez unique,
(on lui passe les paramètres (où trouver les données) l'url vers où
envoyer et un indice pour la fonction à employer en fin de job).
Celle d'affichage ... ça dépend de ce qui est récupéré à la suite de la
requête
si c'est du HTML il n'y a qu'à l'innerHTLMLer
si c'est du fragment DOM, yaka l'appender ou la childRemplacer
plus le programme grossit, plus j'ai des fonctions qui font 50 taches,
Ha Ben ! Pour sûr.
(50 taches ou 50 fonctions ... ce qui revient à du pareil au même, non?)
plus j'ai du mal a decouper le programme en petites entites simples.
Quand on jQuerie on n'emploie plus le mot "simple" ! ! !
c'est antinomique !
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la programmation evenementielle, mais ca me donne l'impression que je code comme un porc... exemple :
Je ne comprends pas cet exemple (il est vrai que je ne parle pas le jquery ...) tu fais appeler de l'ajax par de l'ajax et encore et encore ???? ça ne peut se traiter en 1 fois côté serveur ?
Là, chez moi à la campagne, je sens que je vais pouvoir m'énerver en attendant que les ajaxionnages aient fini leurs allers et retours (entre chez moi et le serveur et à travers mon mauvais ADSL)
ca se soigne ? si oui, comment ?
on jette jquery ou bien on tente de ne pas en rester/devenir esclave ?
j'ai tente de faire des fonctions, comme en programmation imperative, mais ca colle pas trop a la logique...
non ! récup(|) +----> sauve(|) +----> affiche() À mon idée, l'ajaxionnage n'a rien à y voir question découpe des fonctions
l'affichage des donnees ne doit se faire que lorsque la fonction sauvegarder_donnees() aura recu le retour de son appel ajax.
oui if (httpRequest.status == 200) { affiche() } else alert('kput');
donc, cet affichage est defini A L'INTERIEUR de la fonction sauvegarder_donnees(); par consequent, logiquement, le nom de la fonction est faux. il faudrait plutot la nommer comme ca :
ben non, à L'INTERIEUR il n'y a pas à définir la fonction, il n'yaka l'appeler, hop !
jquery ça déforme l'entendement ! à croire.
revoir le B A BA du httpRequest ? <https://developer.mozilla.org/fr/docs/AJAX:Premiers_pas>
mais bon, ca veut dire que la fonction n'a pas une tache unique,
si, la fonction de récup des données peut être assez unique, (on lui passe les paramètres (où trouver les données) l'url vers où envoyer et un indice pour la fonction à employer en fin de job).
Celle d'affichage ... ça dépend de ce qui est récupéré à la suite de la requête si c'est du HTML il n'y a qu'à l'innerHTLMLer si c'est du fragment DOM, yaka l'appender ou la childRemplacer
plus le programme grossit, plus j'ai des fonctions qui font 50 taches,
Ha Ben ! Pour sûr. (50 taches ou 50 fonctions ... ce qui revient à du pareil au même, non?)
plus j'ai du mal a decouper le programme en petites entites simples.
Quand on jQuerie on n'emploie plus le mot "simple" ! ! ! c'est antinomique !
-- Stéphane Moriaux avec/with iMac-intel
Paul Gaborit
À (at) Wed, 28 Nov 2012 00:41:07 +0100, SAM écrivait (wrote):
Le 27/11/12 13:30, luc2 a écrit :
en programmation imperative, si on fait beaucoup de fonctions, le code parait lisible, propre, simple... exemple :
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la programmation evenementielle, mais ca me donne l'impression que je code comme un porc... exemple :
Je ne comprends pas cet exemple (il est vrai que je ne parle pas le jquery ...) tu fais appeler de l'ajax par de l'ajax et encore et encore ???? ça ne peut se traiter en 1 fois côté serveur ?
Là, chez moi à la campagne, je sens que je vais pouvoir m'énerver en attendant que les ajaxionnages aient fini leurs allers et retours (entre chez moi et le serveur et à travers mon mauvais ADSL)
ca se soigne ? si oui, comment ?
on jette jquery ou bien on tente de ne pas en rester/devenir esclave ?
En lisant cela (et la suite de votre message), je pense qu'on comprend que vous n'appréciez pas jQuery.
Mais la question posée, n'a strictement rien à voir avec jQuery. Elle pourrait se poser de la même manière avec n'importe quel bibliothèque ou même si on code tout soi-même en Javascript.
j'ai tente de faire des fonctions, comme en programmation imperative, mais ca colle pas trop a la logique...
non ! récup(|) +----> sauve(|) +----> affiche() À mon idée, l'ajaxionnage n'a rien à y voir question découpe des fonctions
Et pourtant, c'est bien là le nœud du problème.
l'affichage des donnees ne doit se faire que lorsque la fonction sauvegarder_donnees() aura recu le retour de son appel ajax.
oui if (httpRequest.status == 200) { affiche() } else alert('kput');
donc, cet affichage est defini A L'INTERIEUR de la fonction sauvegarder_donnees(); par consequent, logiquement, le nom de la fonction est faux. il faudrait plutot la nommer comme ca :
ben non, à L'INTERIEUR il n'y a pas à définir la fonction, il n'yaka l'appeler, hop !
Et voilà: en programmation "impérative classique", un appel de fonction se termine lorqu'elle a terminée son calcul et on peut immédiatement récupérer le résultat pour le traiter ensuite à la suite de l'appel. Ici, du fait du fonctionnement *asynchrone* des requêtes au serveur, la fonction qui y fait appel se termine sans qu'on ait le résultat (la fonction a juste posté la requête). Et on doit créer une *autre* *fonction* de traitement qui sera appelée lors de la réception de la réponse.
jquery ça déforme l'entendement ! à croire.
Rien à voir avec jQuery !
En revanche, il faut penser son programme de manière asynchrone. Et cela peut poser quelques problèmes. Surtout si le côté serveur n'est pas modifiable.
Les deux algorithme ci-dessous sont assez simples à coder en programmation classique peuvent aboutir à une implémentation relativement similaire :
=== Algo 1 == liste <- récuperer_liste() pour chaque élément de liste faire traitement(élément) fin
=== Algo 2 == liste <- récuperer_liste() a <- initialisation pour chaque élément de liste faire a <- combine(a, traitement(élément)) fin
Dans un contexte asynchrone où la fonction 'traitement()' fait appel au serveur pour obtenir des informations, c'est un peu moins évident. Dans le premier cas, le traiment des éléments peut se faire en parallèle de manière asynchrone. Dans le deuxième cas, il faut prévoir une fonction de traitement qui déclenche aussi l'appel à la suite de la boucle (l'appel à 'combine' et les traitements suivants).
Or si on a plusieurs dizaines d'algorithmes du type "Algo 2" (avec une fonction 'combine' différente), cela peut amener à coder des dizaines de fonctions spécifiques qui font l'appel à 'traitement' pius enchaîne la suite des boucles. Ce qui est assez inefficace.
En s'en sort en analysant correctement ses algorithmes pour extraire ce qui est commun à tous dans des fonctions génériques et en ne conservant en fonction locale (en tant que "closure") que les parties spécifiques à chacun des algorithmes.
C'est de la factorisation mais sur les aspects asynchrones. Ce concept n'a rien d'évident au départ et n'a rien à voir avec l'utilisation ou non de jQuery (et n'a même rien de spécifique à Javascript).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 28 Nov 2012 00:41:07 +0100,
SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> écrivait (wrote):
Le 27/11/12 13:30, luc2 a écrit :
en programmation imperative, si on fait beaucoup de fonctions, le code parait
lisible, propre, simple... exemple :
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la programmation
evenementielle, mais ca me donne l'impression que je code comme un porc...
exemple :
Je ne comprends pas cet exemple
(il est vrai que je ne parle pas le jquery ...)
tu fais appeler de l'ajax par de l'ajax et encore et encore ????
ça ne peut se traiter en 1 fois côté serveur ?
Là, chez moi à la campagne, je sens que je vais pouvoir m'énerver en
attendant que les ajaxionnages aient fini leurs allers et retours (entre
chez moi et le serveur et à travers mon mauvais ADSL)
ca se soigne ? si oui, comment ?
on jette jquery
ou bien on tente de ne pas en rester/devenir esclave ?
En lisant cela (et la suite de votre message), je pense qu'on comprend
que vous n'appréciez pas jQuery.
Mais la question posée, n'a strictement rien à voir avec jQuery. Elle
pourrait se poser de la même manière avec n'importe quel bibliothèque ou
même si on code tout soi-même en Javascript.
j'ai tente de faire des fonctions, comme en
programmation imperative, mais ca colle pas trop a la logique...
non !
récup(|)
+----> sauve(|)
+----> affiche()
À mon idée, l'ajaxionnage n'a rien à y voir question découpe des fonctions
Et pourtant, c'est bien là le nœud du problème.
l'affichage des donnees ne doit se faire que lorsque la fonction
sauvegarder_donnees() aura recu le retour de son appel ajax.
oui
if (httpRequest.status == 200) {
affiche()
}
else alert('kput');
donc, cet
affichage est defini A L'INTERIEUR de la fonction sauvegarder_donnees(); par
consequent, logiquement, le nom de la fonction est faux. il faudrait plutot la
nommer comme ca :
ben non, à L'INTERIEUR il n'y a pas à définir la fonction, il n'yaka
l'appeler, hop !
Et voilà: en programmation "impérative classique", un appel de fonction
se termine lorqu'elle a terminée son calcul et on peut immédiatement
récupérer le résultat pour le traiter ensuite à la suite de
l'appel. Ici, du fait du fonctionnement *asynchrone* des requêtes au
serveur, la fonction qui y fait appel se termine sans qu'on ait le
résultat (la fonction a juste posté la requête). Et on doit créer une
*autre* *fonction* de traitement qui sera appelée lors de la réception
de la réponse.
jquery ça déforme l'entendement ! à croire.
Rien à voir avec jQuery !
En revanche, il faut penser son programme de manière asynchrone. Et cela
peut poser quelques problèmes. Surtout si le côté serveur n'est pas
modifiable.
Les deux algorithme ci-dessous sont assez simples à coder en
programmation classique peuvent aboutir à une implémentation
relativement similaire :
=== Algo 1 == liste <- récuperer_liste()
pour chaque élément de liste faire
traitement(élément)
fin
=== Algo 2 == liste <- récuperer_liste()
a <- initialisation
pour chaque élément de liste faire
a <- combine(a, traitement(élément))
fin
Dans un contexte asynchrone où la fonction 'traitement()' fait appel au
serveur pour obtenir des informations, c'est un peu moins évident. Dans
le premier cas, le traiment des éléments peut se faire en parallèle de
manière asynchrone. Dans le deuxième cas, il faut prévoir une fonction
de traitement qui déclenche aussi l'appel à la suite de la boucle
(l'appel à 'combine' et les traitements suivants).
Or si on a plusieurs dizaines d'algorithmes du type "Algo 2" (avec une
fonction 'combine' différente), cela peut amener à coder des dizaines de
fonctions spécifiques qui font l'appel à 'traitement' pius enchaîne la
suite des boucles. Ce qui est assez inefficace.
En s'en sort en analysant correctement ses algorithmes pour extraire ce
qui est commun à tous dans des fonctions génériques et en ne conservant
en fonction locale (en tant que "closure") que les parties spécifiques à
chacun des algorithmes.
C'est de la factorisation mais sur les aspects asynchrones. Ce concept
n'a rien d'évident au départ et n'a rien à voir avec l'utilisation ou
non de jQuery (et n'a même rien de spécifique à Javascript).
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
par contre, avec l'ajax, je sais pas si c'est ca qu'on appelle la programmation evenementielle, mais ca me donne l'impression que je code comme un porc... exemple :
Je ne comprends pas cet exemple (il est vrai que je ne parle pas le jquery ...) tu fais appeler de l'ajax par de l'ajax et encore et encore ???? ça ne peut se traiter en 1 fois côté serveur ?
Là, chez moi à la campagne, je sens que je vais pouvoir m'énerver en attendant que les ajaxionnages aient fini leurs allers et retours (entre chez moi et le serveur et à travers mon mauvais ADSL)
ca se soigne ? si oui, comment ?
on jette jquery ou bien on tente de ne pas en rester/devenir esclave ?
En lisant cela (et la suite de votre message), je pense qu'on comprend que vous n'appréciez pas jQuery.
Mais la question posée, n'a strictement rien à voir avec jQuery. Elle pourrait se poser de la même manière avec n'importe quel bibliothèque ou même si on code tout soi-même en Javascript.
j'ai tente de faire des fonctions, comme en programmation imperative, mais ca colle pas trop a la logique...
non ! récup(|) +----> sauve(|) +----> affiche() À mon idée, l'ajaxionnage n'a rien à y voir question découpe des fonctions
Et pourtant, c'est bien là le nœud du problème.
l'affichage des donnees ne doit se faire que lorsque la fonction sauvegarder_donnees() aura recu le retour de son appel ajax.
oui if (httpRequest.status == 200) { affiche() } else alert('kput');
donc, cet affichage est defini A L'INTERIEUR de la fonction sauvegarder_donnees(); par consequent, logiquement, le nom de la fonction est faux. il faudrait plutot la nommer comme ca :
ben non, à L'INTERIEUR il n'y a pas à définir la fonction, il n'yaka l'appeler, hop !
Et voilà: en programmation "impérative classique", un appel de fonction se termine lorqu'elle a terminée son calcul et on peut immédiatement récupérer le résultat pour le traiter ensuite à la suite de l'appel. Ici, du fait du fonctionnement *asynchrone* des requêtes au serveur, la fonction qui y fait appel se termine sans qu'on ait le résultat (la fonction a juste posté la requête). Et on doit créer une *autre* *fonction* de traitement qui sera appelée lors de la réception de la réponse.
jquery ça déforme l'entendement ! à croire.
Rien à voir avec jQuery !
En revanche, il faut penser son programme de manière asynchrone. Et cela peut poser quelques problèmes. Surtout si le côté serveur n'est pas modifiable.
Les deux algorithme ci-dessous sont assez simples à coder en programmation classique peuvent aboutir à une implémentation relativement similaire :
=== Algo 1 == liste <- récuperer_liste() pour chaque élément de liste faire traitement(élément) fin
=== Algo 2 == liste <- récuperer_liste() a <- initialisation pour chaque élément de liste faire a <- combine(a, traitement(élément)) fin
Dans un contexte asynchrone où la fonction 'traitement()' fait appel au serveur pour obtenir des informations, c'est un peu moins évident. Dans le premier cas, le traiment des éléments peut se faire en parallèle de manière asynchrone. Dans le deuxième cas, il faut prévoir une fonction de traitement qui déclenche aussi l'appel à la suite de la boucle (l'appel à 'combine' et les traitements suivants).
Or si on a plusieurs dizaines d'algorithmes du type "Algo 2" (avec une fonction 'combine' différente), cela peut amener à coder des dizaines de fonctions spécifiques qui font l'appel à 'traitement' pius enchaîne la suite des boucles. Ce qui est assez inefficace.
En s'en sort en analysant correctement ses algorithmes pour extraire ce qui est commun à tous dans des fonctions génériques et en ne conservant en fonction locale (en tant que "closure") que les parties spécifiques à chacun des algorithmes.
C'est de la factorisation mais sur les aspects asynchrones. Ce concept n'a rien d'évident au départ et n'a rien à voir avec l'utilisation ou non de jQuery (et n'a même rien de spécifique à Javascript).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
luc2
merci d'avoir explicite ma question, je ne l'aurais pas fait mieux moi-meme, ca fait plaisir de voir que quelqu'un ait compris...
merci d'avoir explicite ma question, je ne l'aurais pas fait mieux moi-meme, ca
fait plaisir de voir que quelqu'un ait compris...
merci d'avoir explicite ma question, je ne l'aurais pas fait mieux moi-meme, ca fait plaisir de voir que quelqu'un ait compris...
Olivier Miakinen
Le 29/11/2012 10:17, luc2 répondait à Paul Gaborit :
merci d'avoir explicite ma question, je ne l'aurais pas fait mieux moi-meme, ca fait plaisir de voir que quelqu'un ait compris...
Non seulement il a explicité la question, mais en plus il y a répondu : ce qui rend cette programmation si différente de la programmation impérative « classique », c'est le côté asynchrone des requêtes au serveur.
Cordialement, -- Olivier Miakinen
Le 29/11/2012 10:17, luc2 répondait à Paul Gaborit :
merci d'avoir explicite ma question, je ne l'aurais pas fait mieux moi-meme, ca
fait plaisir de voir que quelqu'un ait compris...
Non seulement il a explicité la question, mais en plus il y a répondu :
ce qui rend cette programmation si différente de la programmation
impérative « classique », c'est le côté asynchrone des requêtes au
serveur.
Le 29/11/2012 10:17, luc2 répondait à Paul Gaborit :
merci d'avoir explicite ma question, je ne l'aurais pas fait mieux moi-meme, ca fait plaisir de voir que quelqu'un ait compris...
Non seulement il a explicité la question, mais en plus il y a répondu : ce qui rend cette programmation si différente de la programmation impérative « classique », c'est le côté asynchrone des requêtes au serveur.
