none
Changement de page : astuce ? RRS feed

  • Question

  • Bonjour tout le monde,

    J'ai eu un petit souci avec le passage par code à une autre page, alors je suis allé lire la FAQ sur le sujet .

    J'ai vu que Server.Transfer était sur-dimensionné puisque je passe les arguments sur l'URL, j'ai donc utilisé Response.Redirect, et du coup j'ai évité d'utiliser un chemin virtuel, puisque Response.Redirect est utilisé depuis le navigateur client, et ne connaît donc pas les chemins du serveur.

    Donc, j'ai utilisé un chemin relatif à partir de la page appelante, donc puisque la page appelée était dans le répertoire ascendant, le chemin commence par deux points.

    La page voulue a bien été appelée, a bien reçu les bons arguments, mais le seul petit souci, est que la barre d'adresse (sous IE) continuait à faire apparaître l'URL de la page appelante, au lieu de celle de la page appelée.

    J'ai solutionné cela en plaçant, dans le page_load :

    string str = this.IsCallback.ToString();

    Je me demande si c'est prévu comme ça ...

    Apparemment, le fait de solliciter cette zone mémoire, a rafraîchi l'URL dans la barre d'adresse. Je m'attendais à devoir tenir compte de IsCallBack pour rafraîchir ou pas la page, même pas besoin. Ou dois-je me méfier selon le navigateur utilisé ?

    • Type modifié Aurel Bera vendredi 8 mars 2013 09:16 Question
    jeudi 7 mars 2013 18:16

Réponses

  • Alors si je ne m'abuse, Response.Redirect, c'est la commande que je mentionnais dans mon premier message ...

    J'avais trois points de confusion :

    • pour ce qui est de l'emploi de MapPath avec Server.Transfer, c'est ma mémoire qui m'a joué des tours, ou ça sert dans certains cas ? En fait, MapPath, OK ça sert à connaître le chemin physique sur le serveur, mais, sauf si la deuxième hypothèse est la bonne pour la question précédente, serait-il possible d'en citer un exemple pratique d'utilisation ?
    • j'avais bien en tête qu'on pouvait utiliser un chemin commençant par ~ en argument de MapPath, mais je viens de découvrir qu'on pouvait aussi s'en servir en argument de Server.Transfer ou de Response.Redirect. A vrai dire, par endroits, un renvoi depuis les pages d'aide concernées serait bienvenu me semble-t-il.
    • parmi mes tâtonnements avant de lancer ce fil, j'ai essayé la bonne syntaxe, mais avec une faute de frappe sur le nom de la page : je m'en suis rendu compte en voyant que ce qui pouvait m'envoyer sur Default.aspx ne fonctionnait pas pour ConsulterAnnoncesParRegion.aspx. Il vaut mieux être sûr de savoir où on va pour être capable de corriger ses erreurs.

    Il reste donc le choix entre Server.Transfer et Response.Redirect. D'après la FAQ, la première fonctionne sur le serveur, comme l'indique le nom de l'objet, et la deuxième sur le navigateur. Il est donc souhaitable d'utiliser la première si on a besoin, dans la page appelée, de faire appel aux données de la page appelante. Etant donné que là, la seule donnée à transférer l'était dans l'URL par QueryString, Response.Redirect fait l'affaire, et on peut supposer que c'est plus économe en ressources. Avantage supplémentaire, effectivement, avec Response.Redirect l'URL se met à jour dans la barre d'adresse. Avec Server.Transfer non, sauf en insérant dans le page_load une instruction qui semble n'avoir rien à voir (voir en tête de ce fil), comme si ça donnait à une ressource le temps de s'exécuter.

    Et effectivement Response.Redirect ne met pas à jour la barre d'adresse si l'adresse appelée est relative à la page appelante, mais le problème est résolu en commençant l'adresse par ~ pour se référer à la racine du site.


    Merci pour les précieuses indications qui m'ont guidé pour faire le point.

    vendredi 8 mars 2013 17:31

Toutes les réponses

  • Bonjour,

    Cela ne doit pas être cela. Response.Redirect indique au navigateur l'adresse de la nouvelle page et c'est le navigateur qui va chercher ce qui se trouve à cette adresse donc par principe aucun besoin de rafraichir l'adresse car le navigateur la connait déjà.

    Server.Transfer ne dit rien au client et donc le navigateur n'a aucun moyen de savoir à quelle adresse on se trouve réellement...

    J'essaierai avec deux pages toutes bêtes l'une faisant un redirect vers l'autre peut-être d'abord dans le même dossier (on devrait constater que l'adresse est actualisée sans aucune intervention) puis à nouveau avec une page dans le répertoire parent (avec les .. puis dans un deuxième temps en donnant l'adresse depuis la racine) pour voir si on a bien le même comportement dans les 3 cas.

    Je me demande si les .. ne pourraient pas jouer un rôle. C'est souvent désactivé pour des raisons de sécurité (et donc sans doute à éviter de toute façon) mais il serait bizarre que du coup IE s'autorise à aller chercher la page sans pour autant l'afficher dans la barre d'adresse...


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

    • Proposé comme réponse Aurel Bera vendredi 8 mars 2013 09:16
    jeudi 7 mars 2013 18:40
    Modérateur
  • Bonjour,

    J'ai aussi créé une page TouteBete.aspx dans le répertoire 1, avec un bouton qui exécute l'instruction, que j'ai apprise en premier :

     Server.Transfer(this.MapPath("~/ConsulterAnnoncesParRegion.aspx"));
    Je me demande si je n'aurais pas oublié d'initialiser quelque chose, car cette instruction déclenche l'exception suivante :

    System.ArgumentException: Chemin d'accès non valide pour la demande enfant

    'C:\Sites\AffairesSansRisque6\ConsulterAnnoncesParRegion.aspx'.

    Un chemin d'accès virtuel est attendu.

    Si je copîe le chemin vers une fenêtre de lignes de commandes en argument de la commande DIR, en remplaçant les apostrophes par des guillemets, on m'affiche bien la taille du fichier, ce qui confirme que le chemin physique est correct.

    En premier lieu j'avais essayé de passer un argument en QueryString, aussi je me suis méfié que j'aie pu me tromper de syntaxe à ce niveau, mais sans argument comme ci-dessus, j'ai la même erreur.

    Même résultat, au chemin affiché près, avec :

            Server.Transfer(this.MapPath("~/Default.aspx"));
    

    La page Default.aspx ne contient que sa référence à la page maîtresse (TouteBete n'a pas de page maîtresse).

    L'outil de configuration d'ASP.Net m'affiche "Application:/AffairesSansRisque6" (la sécurité n'est pas encore définie).

    Arborescence dans l'explorateur de solutions



    • Modifié Gloops vendredi 8 mars 2013 14:38
    vendredi 8 mars 2013 14:05
  • Cela ne doit pas être cela. Response.Redirect indique au navigateur l'adresse de la nouvelle page et c'est le navigateur qui va chercher ce qui se trouve à cette adresse donc par principe aucun besoin de rafraichir l'adresse car le navigateur la connait déjà.

    Il peut y avoir des petits soucis d'implémentation au niveau du navigateur : je me suis rendu compte que Firefox, au moins pour ce qui est de sa version 18, parfois affiche bien la bonne page, mais la barre d'adresse apparaît vide. Il reste possible de connaître l'URL visitée, mais en allant chercher la commande propriétés quelque part dans les menus (à vrai dire j'avais l'habitude de la consulter dans le panneau latéral via une extension). En revanche j'ai toujours considéré que c'était aléatoire, à défaut de plus de corrélations ...

    Si ça arrive à Firefox, pourquoi pas quelque chose d'approchant à IE ...


    • Modifié Gloops vendredi 8 mars 2013 15:02
    vendredi 8 mars 2013 14:56
  • Supprimer je pense l'appel à MapPath qui permet de transformer un chemin "virtuel" (disons une "adresse web sur le site en cours") vers l'emplacement physique du fichier correspondant sur le disque du serveur (c:\mon dossier\mapage.aspx") Donc ce n'est pas à utiliser quand on veut juste "naviguer" vers une autre page web.

    Eventuellement comme suggéré par Gloops, indiquer peut-être la version d'IE testée des fois que (personnellement je n'ai jamais remarqué ce problème).

    Egalement je croyais dans le premier message que l'on utilisait actuellement Redirect plutôt que Transfer (ou votre but est de tester l'un et l'autre pour voir la différence donc Redirect qui devrait actualiser l'adresse de la page sur le client sans aucune intervention supplémentaire et Transfer qui ne devrait pas le permettre).


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

    vendredi 8 mars 2013 15:26
    Modérateur
  • Effectivement, pendant le redémarrage de ma machine, j'ai réalisé que si je mettais en cause le navigateur il manquait des infos :

    IE Version    8.0.6001.18702
    Numéro       86001

    De toute manière, on dirait que j'ai mal compris l'utilité de MapPath. Mais alors sans ça, je mets un chemin qui commence par \ pour désigner la racine du site ? J'ai bien fait de creuser la question on dirait ...

    Le temps que mon bourrin ait fini de paginer j'essaie Redirect et je vous dis ...

    vendredi 8 mars 2013 16:00
  • Alors si je ne m'abuse, Response.Redirect, c'est la commande que je mentionnais dans mon premier message ...

    J'avais trois points de confusion :

    • pour ce qui est de l'emploi de MapPath avec Server.Transfer, c'est ma mémoire qui m'a joué des tours, ou ça sert dans certains cas ? En fait, MapPath, OK ça sert à connaître le chemin physique sur le serveur, mais, sauf si la deuxième hypothèse est la bonne pour la question précédente, serait-il possible d'en citer un exemple pratique d'utilisation ?
    • j'avais bien en tête qu'on pouvait utiliser un chemin commençant par ~ en argument de MapPath, mais je viens de découvrir qu'on pouvait aussi s'en servir en argument de Server.Transfer ou de Response.Redirect. A vrai dire, par endroits, un renvoi depuis les pages d'aide concernées serait bienvenu me semble-t-il.
    • parmi mes tâtonnements avant de lancer ce fil, j'ai essayé la bonne syntaxe, mais avec une faute de frappe sur le nom de la page : je m'en suis rendu compte en voyant que ce qui pouvait m'envoyer sur Default.aspx ne fonctionnait pas pour ConsulterAnnoncesParRegion.aspx. Il vaut mieux être sûr de savoir où on va pour être capable de corriger ses erreurs.

    Il reste donc le choix entre Server.Transfer et Response.Redirect. D'après la FAQ, la première fonctionne sur le serveur, comme l'indique le nom de l'objet, et la deuxième sur le navigateur. Il est donc souhaitable d'utiliser la première si on a besoin, dans la page appelée, de faire appel aux données de la page appelante. Etant donné que là, la seule donnée à transférer l'était dans l'URL par QueryString, Response.Redirect fait l'affaire, et on peut supposer que c'est plus économe en ressources. Avantage supplémentaire, effectivement, avec Response.Redirect l'URL se met à jour dans la barre d'adresse. Avec Server.Transfer non, sauf en insérant dans le page_load une instruction qui semble n'avoir rien à voir (voir en tête de ce fil), comme si ça donnait à une ressource le temps de s'exécuter.

    Et effectivement Response.Redirect ne met pas à jour la barre d'adresse si l'adresse appelée est relative à la page appelante, mais le problème est résolu en commençant l'adresse par ~ pour se référer à la racine du site.


    Merci pour les précieuses indications qui m'ont guidé pour faire le point.

    vendredi 8 mars 2013 17:31
  • Bonjour,

    Pouvons-nous considérer que vous avez résolu votre problème ? 

    Désormais, nous marquons les solutions proposées. N'hésitez pas à revenir et supprimer la réponse marquée si la solution n’est pas correcte. Merci !

    Cordialement,


    Aurel BERA, Microsoft
    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    mercredi 13 mars 2013 08:03
  • Oui, ça marche, merci.

    Maintenant, je vais pouvoir regarder du côté de WCF :)

    mercredi 13 mars 2013 09:30