Discussion :

[Unusual]

Bonjour,
J'aurais voulu savoir s'il était possible de ne pas afficher les url en entier

ex de site : http://www.monsite.fr/monprojet

si on va sur la page http://www.monsite.fr/monprojet/page1.aspx
que cela n'affiche pas le nom de la page aspx, voire les éventuels paramètres passés...

Y a-t-il moyen de le faire par programmation et/ou paramétrage IIS ?

[Ramajb]

Bonjour,
Tu as déjà pris connaissance de ceci : lien
Bonne chance

[Unusual]

Oui, j'ai lu pas mal de chose sur la réécriture d'url...mais tel que je le comprend (mais peut-être que je me trompe après tout), c'est pour rediriger un appel, ce qui n'est pas du tout mon besoin.

Dans mon cas, j'ai une application avec une adresse d'accès du type www.monsite.fr
après il y a une authentification et la navigation se fait uniquement par des menus, il n'y a pas à taper quoi que ce soit comme url...mais les clients ne veulent pas que les url soient visibles lors de la navigation, ils veulent que cela reste comme "figé" avec
www.monsite.fr

Par contre, moi, j'ai besoin de connaître les éventuels paramètres passés aux pages aspx réellement appelées...car je m'en sers bien évidemment

ex : si en réel, l'appel fait est le suivant http://www.monsite.fr/pageexemple.as...n=1&contexte=2

il faudrait que dans le navigateur, cela reste affiché www.monsite.fr mais j'ai besoin de traiter dans le page_load les paramètres fournis (action et contexte dans l'exemple ci-dessus)

c'est "juste" au niveau affichage que je souhaite occulter ce qu'il y a au delà du nom du site...sans rien changer au fonctionnement actuel (ou presque suivant la solution à apporter)

[Ramajb]

Difficile de croire que c'est faisable. a moins que j'ai loupé quelques choses. Si au moins on a la possibilités d'avoir un url avec un query string, alors la c'est différente.

[DotNetMatt]

Je vois 3 solutions à ton problème...

La première c'est de mettre une frame HTML mais ce n'est pas forcément la meilleure option... En fait quand l'utilisateur viendra sur www.monsite.fr il tombera sur la page 'index.html' qui contient la frame HTML. Et cette frame HTML sera pointée vers tes pages. Il te suffira pour naviguer de définir l'URL de la frame.

La seconde solution, c'est de ne plus utiliser de QueryString, mais de passer tes paramètres en mode 'POST' entre les pages.

La troisième solution, c'est d'utiliser les variables de session pour stocker les informations dont tu as besoin. Le risque avec ça, c'est que si ton application pool venait à se recycler, les sessions de tous les utilisateurs seront perdues...

[Unusual]

Merci pour les réponses...Je vais essayer de répondre aux 3 solutions proposées de façon un peu pêle-mêle, mais ce n'est pas si facile à expliquer pourquoi elles ne me conviennent pas (ou peu).

D'abord pour la 3 et la 2 :
J'ai déjà un bon nombre de variables de sessions, l'application regroupe des dizaines d'écrans avec onglets, dont une demi-douzaine de pages maitres différentes. Partout, il y a utilisation potentielle de cartographies Geoportail et Google maps pour afficher des données (unitaires ou sélections) et parfois l'affichage d'autres fenêtres où je fais passer justement des paramètres qui ne servent que contextuellement, mais pouvant servir plusieurs fois en même temps (potentiellement n fois), je ne peux pas vraiment avoir de variables de session pour ces cas là justement...et j'utilise de ce fait les querystring. Qu'entends-tu par passer les paramètres en mode 'post' entre les pages ?...à la base, je suis un développeur Windows (Delphi, C, C++, C#), le web c'est seulement depuis peu, c'est mon premier projet web ASP.NET + C# et pour ce qui est du côté Web, il m'a fallu apprendre sur le tas et je découvre toujours

Pour la solution 1, je trouve aussi que ce n'est pas forcément terrible (mais ai-je une alternative ?) surtout quand j'ai plusieurs fenêtres en même temps...et puis, je risque aussi d'avoir pas mal de galères avec le Javascript, non ? Pour les cartographies, j'ai pas mal de classes pour gérer les couches, faire des impressions, afficher des KML, intercepter les évènements claviers et souris pour les actions de zoom, de déplacements, d'affichages détaillés, de régénération des couches de données selon le contexte, la densité de population, l'échelle...il y a une forte utilisation du DOM et je crains qu'en utilisant cette solution, il y ait pas mal de dysfonctionnements générés...

[DotNetMatt]

D'abord pour la 3 et la 2 :
J'ai déjà un bon nombre de variables de sessions, l'application regroupe des dizaines d'écrans avec onglets, dont une demi-douzaine de pages maitres différentes. Partout, il y a utilisation potentielle de cartographies Geoportail et Google maps pour afficher des données (unitaires ou sélections) et parfois l'affichage d'autres fenêtres où je fais passer justement des paramètres qui ne servent que contextuellement, mais pouvant servir plusieurs fois en même temps (potentiellement n fois), je ne peux pas vraiment avoir de variables de session pour ces cas là justement...et j'utilise de ce fait les querystring. Qu'entends-tu par passer les paramètres en mode 'post' entre les pages ?...à la base, je suis un développeur Windows (Delphi, C, C++, C#), le web c'est seulement depuis peu, c'est mon premier projet web ASP.NET + C# et pour ce qui est du côté Web, il m'a fallu apprendre sur le tas et je découvre toujours

Lorsque tu passes des paramètres entre 2 pages via l'URL, tu utilises en fait la méthode GET du formulaire. Il existe aussi la méthode POST qui permet de passer des paramètres entre 2 pages mais sans utiliser l'URL. Les informations sont en fait stockées dans le header.

Il faut alors utiliser dans la page qui reçoit les informations :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

string myValue = Request.Form("myControl");

Il existe également d'autres façons de procéder qui sont détaillées ici : http://steveorr.net/articles/PassData.aspx

Pour la solution 1, je trouve aussi que ce n'est pas forcément terrible (mais ai-je une alternative ?) surtout quand j'ai plusieurs fenêtres en même temps...et puis, je risque aussi d'avoir pas mal de galères avec le Javascript, non ? Pour les cartographies, j'ai pas mal de classes pour gérer les couches, faire des impressions, afficher des KML, intercepter les évènements claviers et souris pour les actions de zoom, de déplacements, d'affichages détaillés, de régénération des couches de données selon le contexte, la densité de population, l'échelle...il y a une forte utilisation du DOM et je crains qu'en utilisant cette solution, il y ait pas mal de dysfonctionnements générés...

Effectivement la méthode de la Frame peut nécessiter quelques ajustements. Mais la seule solution pour en être sûr, c'est encore de tester

Personnellement, je pense que la Frame n'est à utiliser qu'en dernier recours. ASP.NET offre pas mal de mécanismes permettant de transporter des données donc je pense que tu devrais te pencher sur les solutions offertes par ASP.NET.

Un dernier lien utile : http://msdn.microsoft.com/en-us/library/6c3yckfw.aspx