|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| AWP : Code d'initialisation des pages exécuté trop souvent |
| Débuté par Marc LAZZARINI, 28 mai 2015 09:33 - 9 réponses |
| |
| | | |
|
| |
Membre enregistré
232 messages
Popularité : +23 (23 votes) |
|
Posté le 28 mai 2015 - 09:33 |
Bonjour c'est encore moi...., avec deux questions au sujet des pages awp.
1/ Pourquoi le code d'initialisation des pages awp est exécuté 2 fois à l'ouverture de la page ?
2/ Pourquoi le code d'initialisation des pages awp est exécuté à chaque fois qu'on fait une action sur la page ? Quand je clique sur un bouton qui a du code serveur, alors même que l'Ajax automatique est activé, le code d'init de la page est exécuté. Mais la valeur des champs est conservée... Résultat, je ne peux pas utiliser de variables globales, car elles sont systématiquement réinitialisée...
Merci d'avance.
Cordialement,
Marc. |
| |
| |
| | | |
|
| | |
| |
Posté le 28 mai 2015 - 13:42 |
Bonjour Marc
tout vient du fait que les pages awp n'ont pas de contexte... LE tout
est de bien comprendre ce que ca veut dire :
1- l'utilisateur demande l'affichage d'une page
2- le serveur la prépare
3- le serveur l'envoit au navigateur
4- le serveur n'a plus aucune information sur cette page
5- l'utilisateur fait une action sur la page qui appelle le serveur (ou
un champ le fait automatiquement). Du fait du point 4, le serveur DOIT
refaire l'init de la page pour savoir ce qu'il y a dessus et construire
un contexte dans lequel exécuter le code demandé... Sans celà, il ne
saurait pas quelles valeurs sont ou...
Ca se voit (ou se découvre) de plein de façons auxquelles on ne pense
pas forcément...
Par exemple (je n'ai pas testé si c'est toujours le cas en 20),
une table ajax sur une page awp... L'utilisateur clique sur l'entete
d'une colonne pour changer le tri, puis sélectionne une ligne (disons la
ligne 5)...
Clic sur un bouton et code serveur qui traite la ligne 5... Le serveur
refait l'init de page et remplit la table... mais ne la trie pas comme
l'utilisateur (vu que c'est une action navigateur seulement)
La ligne 5 traitée est celle dans le tri d'origine, pas dans le tri
choisi par l'utilisateur...
Il faut donc systématiquement gérer cette situation pour tout site awp.
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
Disponible : WXShowroom.com, WXReplication (open source)
Bientôt : WXEDM (open source)
Plus d'information sur http://fabriceharari.com
On 5/28/2015 1:33 AM, Marc LAZZARINI wrote:
Bonjour c'est encore moi...., avec deux questions au sujet des pages awp.
1/ Pourquoi le code d'initialisation des pages awp est exécuté 2 fois à
l'ouverture de la page ?
2/ Pourquoi le code d'initialisation des pages awp est exécuté à chaque
fois qu'on fait une action sur la page ? Quand je clique sur un bouton
qui a du code serveur, alors même que l'Ajax automatique est activé, le
code d'init de la page est exécuté. Mais la valeur des champs est
conservée... Résultat, je ne peux pas utiliser de variables globales,
car elles sont systématiquement réinitialisée...
Merci d'avance.
Cordialement,
Marc. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
841 messages
Popularité : +19 (27 votes) |
|
Posté le 28 mai 2015 - 16:12 |
Bonjour,
Je ne sais pas comment on fait en WebDev mais en php il y a une solution pour échanger des variable entre serveur et navigateur.
On crée une variable de session pour ce paramètre, je suppose qu'en Webdev c'est une variable globale au projet.
La page XXX s'affiche avec la variable avec paramètre par défaut ( disons 12 ) on modifie ce paramètre coté navigateur (disons 14), on transmet ce paramètre à une procédure js ( donc du code navigateur pour WebDev ). Ce code appelle une page intermédiaire en post par exemple ( formulaire ) ensuite cette page intermédiaire affecte la variable globale avec la valeur reçue et appelle de nouveau la page XXX qui affichera 14 ( en php c'est header:location il y a surement un équivalent en WebDev ).
Ce n'est pas une limite de WebDev mais le web fonctionne comme ça les pages n'affichant que du html c'est à dire du texte.
Ca parait compliqué au premier abord mais tout le système Ajax est basé sur ce principe une page est appelé en arrière plan pour effectuer le travail puis on reaffiche la page ou on reaffiche une partie de la page. Si on comprend ce principe tout devient plus clair et on est moins frustré.
--
Miro |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
232 messages
Popularité : +23 (23 votes) |
|
Posté le 28 mai 2015 - 18:03 |
Bonjour Fabrice et Camus, et merci pour vos éclairages. J'en déduis alors qu'il est inutile d'utiliser des variables globales serveur au niveau des pages.
Comme le dis Camus, je pourrais utiliser une variable globale au projet, mais là ça deviendrait compliqué car il faudrait que j'inclue dans mon contexte awp toutes les variables globales de chaque page. Ce qui alourdirait considérablement le contexte.
Mais il me revient à l'esprit l'exemple MémoriserChamp_AWP qui sert à mémoriser la valeur des champs d'une page en stockant dans un tableau global au projet le nom du champ et sa valeur. Je crois que je vais appliquer ce principe aux variables globales des pages, ça me semble être une solution légère et souple.
Encore merci à tous les deux.
Cordialement,
Marc. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
135 messages
Popularité : +8 (8 votes) |
|
Posté le 29 mai 2015 - 09:45 |
Bonjour,
Pour mémoriser le contexte en AWP je fais ainsi :
Je déclare une structure OU une classe qui gère le contexte. Par exemple la classe cl_contexte
cl_contexte_projet est une classe
ClientCourant est un cl_client dynamique
Panier est un cl_panier()
MessageAAfficher est une chaîne
etc..
etc..
FIN
Et dans le code d'init du projet je fais
ConfigureContexteAWP(ctxDisque,ctxIDCookieURL)
Gbp_Contexte_Projet est un cl_contexte_Projet()
DéclareContexteAWP(Gbp_Contexte)
Et c'est tout...
Je veux délogguer l'user
Gbp_Contexte_Projet:ClientCourant=null
Je veux vider le panier
Gbp_Contexte_Projet:Panier:Vider()
Je veux supprimer le contexte du projet
AnnuleContexteAWP(Gbp_Contexte_Projet)
Une nouvelle info à mémoriser dans le contexte ? Il suffit d'ajouter un membre à la structure ou à la classe.
Ce principe est également utilisable avec une page.. Tu fais une structure ou une classe qui contient les éléments du contexte d'une page et tu la déclare au niveau de la page comme je le fais ci dessus pour le projet.
Gbw_Contexte_Page_xxxx est un cl_contexte_page_xxxx()
DéclareContexteAWP(Gbw_Contexte_Page_xxxx)
--
Dominique DAUSSY
http://www.serviceinfo76.com |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
232 messages
Popularité : +23 (23 votes) |
|
Posté le 29 mai 2015 - 20:12 |
Bonjour Dominique,
Merci pour ta réponse, ça rejoint, mais en plus élaboré, l'exemple MémoriserChamps dont je parlais précédemment.
Par contre, au sujet du contexte de page dont tu parles en fin de ton message, est-ce qu'en faisant cela on ne réinitialise pas le contexte à chaque chargement de page ? Vu que l'init est appelé à chaque action Ajax réalisée dans la page, ça pourrait être pénalisant.
Cordialement,
Marc. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
135 messages
Popularité : +8 (8 votes) |
|
Posté le 30 mai 2015 - 06:54 |
Bonjour,
Dans tous les cas, le contexte est rechargé à chaque appel d'une page AWP.. que la déclaration se trouve dans l'init du projet ou dans le code d'init d'une page. Le rechargement du contexte avec DeclareContexteAwp peut être placé ou tu veux, cela dépend de ce que tu cherches à faire.
Exemple avec un autre site qui a 2 parties, une partie client et une partie admin.
J'ai, dans ce cas, créé deux classes de contexte, une pour le client et une autre pour l'admin MAIS je ne recharge pas le contexte dans l'init du projet. Je déclare bien ces 2 classes dans le code d'init du projet en global mais le chargement du contexte avec DeclareContexteAWP ce fait ici dans le modèle de page respectif de chaque partie.
- Le modèle de page de base de la partie client déclare le contexte client.
- Le modèle de page de base de la partie admin déclare le contexte admin.
Petite précision également, je cherche à optimiser également la taille du contexte, dans tout ce que j'ai pu réaliser je n'ai jamais constaté de lenteur à cause du rechargement du contexte.. Je n'ai jamais fait le test mais déclare simplement un tableau de chaines ou d'objets dans ton contexte que tu charges un max et tu verras si le chargement du contexte provoque un ralentissement..
--
Dominique DAUSSY
http://www.serviceinfo76.com |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
1 603 messages
Popularité : +64 (70 votes) |
|
Posté le 01 juin 2015 - 08:35 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
232 messages
Popularité : +23 (23 votes) |
|
Posté le 01 juin 2015 - 09:09 |
Bonjour François.
Effectivement cette solution semble à la fois très intéressante et très facile à mettre en oeuvre. Ça evite pas mal d'aller-retours vers le serveur.
Cordialement,
Marc. |
| |
| |
| | | |
|
| | |
| |
Posté le 01 juin 2015 - 14:25 |
Bonjour,
perso, j'ai un enreg de session dans ma base, l'id de session dans les
paramètres de chaque page, et tous mes paramètres (valeur de variable ou
autre) stockées dans un mémo texte de l'enreg session, façon fichier ini...
Aucun cookie ou que ce soit, aucun blocage possible
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
Disponible : WXShowroom.com, WXReplication (open source)
Bientôt : WXEDM (open source)
Plus d'information sur http://fabriceharari.com
On 6/1/2015 1:09 AM, Marc LAZZARINI wrote:
Bonjour François. Effectivement cette solution semble à la fois très
intéressante et très facile à mettre en oeuvre. Ça evite pas mal
d'aller-retours vers le serveur.
Cordialement,
Marc. |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|