I have a page that requires the user to go through several steps, however step is performed on the same ASPX page with different panels being displayed.
However this is a requirement that each step has a different URL, this could be a simple as a query string parameter, for example:
Step 1:
/member/signup.aspx?step=1
Step 2:
/member/signup.aspx?step=2
Step 3:
/member/signup.aspx?step=3
However I don't want to have to redirect the user to the new URL each time they continue to the next step, this would involve a lot of redirecting and also a switch statement on the page load to work out which step the user is on.
It would be better if I could alter the URL that is displayed to the user when the original request is sent back to the user, i.e. the user click "next" on step 1 the page then does some processing and then alters response so that the user then sees the step 2 URL but without any redirection.
Any ideas would be greatly appreciated.
Could you convert your Panels into steps in a Wizard control?
It would be a little more complicated than you probably want, but you could achieve this effect with the PostBackUrl property of the submitting button. I'm assuming each panel has its own "submit" button, and they could all use this property to "advance" the process. The drawback is that in order to get to submitted controls, you'd need to use the Page.PreviousPage property in order to access any controls and their values.
You could programmatically alter the PostbackUrl property of your 'Next' button on each Page_Load, based on the query string value. This is a bit strange though, as you wouldn't be able to use a standard event handler for the button click, and you'd have to use the PreviousPage property of the Page to get the data from the previous tab.
I'd say challenge this requirement. Why would anyone need to jump into the middle step? If it's a case of displaying the progress to the user, do this on the page, not in the URL.
You require that each step has different URL, than Response.Redirect is the only option. As you want to avoid the redirection, you can use IFrame but IFrame URL is not visible to user on his browser. I think redirect option is ugly(for both SERVER and CLIENT) as in this case, you first post on the page and than get that page. The best solution is POST BACK with some varible tracking step.
You could implement a form or url rewriting so that your urls end up being
/member/signup/step1/
/member/signup/step2/
/member/signup/step3/
To do this use the
HttpContext.RewritePath method which means you can rewrite /member/signup/step1/ to /member/signup.aspx?step=1 for example. See an example here.
I would also use the PRG (post request get) pattern so that each next link posts the form data of that step to the session then redirects the user top the correct next url. this will ensure that the user can navigate back and forth through the steps safely and also the url will remain intact in all your posts.
Check out server.transfer
Related
I am building a web application in asp.net and c#, I am storing text of textbox in Session variable like this:
Session["data"]=TextBox1.Text;
and on the button click event I am redirecting user to another page.In the second page I am using this variable Session["data"] and in page2 there is a back button where I am again Redirecting to page1 where the textbox1 is present.Now on the button click event where I am redirecting to page2 and event is code like this,
Session["data"]=TextBox1.Text;
Response.Redirect("page2.aspx");
now when I am accessing the value of the Session["data"] it is giving me the previous value.As the content of TextBox1 may get changed,these changes have not been shown.
Please tell me where I am going wrong.
I dont think the code you are using is worng. You please make a break point and check it again that the values are assigning correctly
Or
You just set the session to null and then assign the textbox value to it on the click event.
Read this I think Respone.Redirect might be causing you to lose your session data
Don't redirect after setting a Session variable (or do it right)
A problem I see over and over again on the ASP.NET forums is the
following: In a login page, if the user and password have been
validated, the page developer wants to redirect to the default page.
To do this, he writes the following code:
Session["Login"] = true;
Response.Redirect("~/default.aspx");
Well, this doesn't work. Can you
see why? Yes, it's because of the way Redirect and session variables
work. When you create a new session (that is, the first time you write
to a Session variable), ASP.NET sets a volatile cookie on the client
that contains the session token. On all subsequent requests, and as
long as the server session and the client cookie have not expired,
ASP.NET can look at this cookie and find the right session. Now, what
Redirect does is to send a special header to the client so that it
asks the server for a different page than the one it was waiting for.
Server-side, after sending this header, Redirect ends the response.
This is a very violent thing to do. Response.End actually stops the
execution of the page wherever it is using a ThreadAbortException.
What happens really here is that the session token gets lost in the
battle. There are a few things you can do to solve this problem.
First, in the case of the forms authentication, we already provide a
special redirect method: FormsAuthentication.RedirectFromLoginPage.
This method is great because, well, it works, and also because it will
return the user to the page he was asking for in the first place, and
not always default. This means that the user can bookmark protected
pages on the site, among other things. Another thing you can do is use
the overloaded version of Redirect:
Response.Redirect("~/default.aspx", false);
This does not abort the
thread and thus conserve the session token. Actually, this overload is
used internally by RedirectFromLoginPage. As a matter of facts, I
would advise to always use this overloaded version over the other just
to avoid the nasty effects of the exception. The non-overloaded
version is actually here to stay syntactically compatible with classic
ASP.
I don't really see what you want to do here. You say it works (the Session["data"] contains the text of TextBox1?) but you don't see any changes? What changes did you expect? Please give us some more information about this part of the question:
As the content of TextBox1 may get changed,these changes have not been shown.
Thanks.
Update:
Try clearing or remove the session and then refill it.
Session.Remove("data");
Session.Clear();
i have a little asp.net web application.
it is a front end to a sql-server-2008 database.
after they fill out all the data, they will press submit and the data will be sent to the database.
after this point if the user refreshes the page, the data is posted again!!! how do i disable this from happening?
Send a Location header back to the user that redirects the browser to another page: refresh will then reload that other page rather than resubmit the old form.
This is caused by the last request being a POST request to the page, what do you need to do is a redirect so the last request becomes a GET.
After you have handled the post data you can just do a redirect to the same page with:
Response.Redirect("~/ThePage.aspx");
This will prevent you from presenting a message to the user straight from the code behind, if you want to present a success message using this method you will need to add a querystring or something similar:
Response.Redirect("~/ThePage.aspx?result=success");
And then check on the page bind if the querystring to present a success message is set, such a check could look something like this:
if (Request.QueryString["result"] != null && Request.QueryString["result"].ToString().ToLower() == "success")
{
//Show success message
}
Another solution which probably is superior but might require some more work is to wrap the form in a updatepanel, you can read more about it here: http://ajax.net-tutorials.com/controls/updatepanel-control/
An updatepanel will make the form submit with AJAX instead of full postback.
You need to follow the Post/Redirect/Get pattern which is explained on WikiPedia and alluded to by Femi. In your code after you've done your processing do a Response.Redirect to the desired page.
See this article about the PRG pattern: http://en.wikipedia.org/wiki/Post/Redirect/Get
In short, after the user POSTs (submits) data to your server, you issue a Response.Redirect to have the users browser GET a page. This way, if the user presses the reload button, it is the GET request that is repeated.
I have used a query string parameter to redirect from Page 1 to Page 2. From Page 2, i wanted to redirect it to Page 3 if Page 2 has been called from Page 1. What should be the condition to check if the querystring is used??
Please help me out!! Thanks guys!
Ram, this is my interpretation of what you wanted: if user accesses Page2 due to redirect from Page1, the user will be redirected automatically to Page3. If user accesses Page2 directly (without visiting Page1), the user will stay in Page2 (no redirect to Page3).
If this is the case, inside Page1, you can set redirect("Page2.aspx?previouspage=page1"), then in Page2, inside Page_load method, check for the querystring, if previouspage exists and equals "page1", redirect to Page3, else do nothing and Page2 will show up.
You may wish to parse the HTTP_REFERER and see if Page 2 has been called from Page 1. Basically, you would build your Page 2 redirection based on the HTTP_REFERER value. In C#, the value is available using the following:
Page.Request.ServerVariables("HTTP_REFERER")
Put something into the query string of page 2 as well, and check that.
However, you should always move to reduce the number or redirects (some browsers limit at 5 - to prevent the case where while not an exact loop, the browser will redirect for ever - if it already took a couple of redirects to get to your site, then part way through this sequence, it'll stop redirecting). In Page 1 you should redirect to Page 3. If you need something done then do it in Page 1 or Page 3, but note that this is only from the browsers perspective; if you do a server.transfer to page 2 then while the logical pattern for your code is 1 -> 2 -> 3, to the browser it looks like 1 -> 3. In this case you can also check the raw URI if you wanted to know that you had got there by coming from page 1.
Looked at from another way, a redirect is part of your UI. If the user was on page 1 to being with this should have made sense, or there's a bug in your UI. If the user ends up on page 3, then this should also have made sense, or there's a bug in your UI. Now considering this, what is the purpose from the user prespective of page 2? I'm not saying there couldn't be one (I can think of cases where multiple redirects make good sense, esp. if they are of different types, e.g. a moved-permanently followed by a see-other makes sense), but chances are it doesn't and a you could deal with part of it while keeping the flow in the server.
Maybe I am not understanding this right .. but why not redirect directly from page 1 to page 3?
I am using jQuery to simulate a popup, where the user will select a series of filters, which I hope to use to rebind a ListView in the original window.
The "popup" is opened via an ajax request and the content is actually a diferent aspx file (the rendered output is injected into a div that acts as the popup).
I have another ListView in this popup, and it has pagination.
My problem is that since the popup is in reality html content inside a div in the same page, when I try to paginate, the whole page postbacks and is replaced with the aspx that has the filters.
How can I fix this?
I tried using an update panel to contain the ListView but it didn't work.
$("div.yourthingie").hide();
Will hide the part you want to show :) Instead of generating the popup on the fly, leave a small part already made, and hide it in the begining, when you need to show, unhide and add the information you need to.
Hope it helps
Either get rid of the HTML "crust" and just produce the <div> with its contents, or use an IFRAME.
First, let's think through what is happening. When you submit the original page, you are taking a "normal" Request/Response trip to get the code. On the page is a JQuery AJAX bit that fires off what is essentially a modal dialog. The desired effect is the user plays with the new page until they have figured out their filters and submits back. The problem is this "modal page" loses information when someone paginates.
The solution to this is fairly simple, in theory. You have to store the "filters" in the popped up page so they can be resent, along with pagination information. OR you have to cache the result set while the user paginates.
What I would do to solve this is create a static page that has the "filters" in place and work out the AJAX kinks separate from having the page post back to a parent page. Once you have all of the AJAX bits working properly, I would then link it into the popup routine and make sure the pagination is still non-problematic. THe final problem is creating a JavaScript routine that sends back to the parent page and allows the parent page to send its JQuery bits back to the server.
I am not sure about the HTML DIV part of the equation and I think you can solve the problem without this solution. In fact, I believe you can make the "modal popup" page without invoking AJAX, if it is possible to either a) submit the filters to apply via the querystring or b) fake a form submit to the second page. The query string is an easier option, but it exposes some info. Faking a form submit is not that difficult, overall, but could be problematic with a popup.
I am just firing off some ideas, but I hope it spurs something for you.
I am designing a winforms based testing app (which is based upon WatiN). I specify a page to test and the value to insert into a textbox, and then click the corresponding button.
Is it possible to add a query string to the request I make (when clicking button) and then get the URL of the next page? Based on this, I need to screen scrape it.
Not sure about Watin syntax, but in Watir (Ruby version) you can get URL of the page displayed in browser with
browser.url
Or do you need to get URL of the next page before you open it?
Based on your comment to AmitK, Ċ½eljko's answer is right.
In WatiN (and C#), the syntax is:
Console.WriteLine("The current page is:" + ie.Url.ToString());
(just in case: 'ie' is the browser reference, use whatever object you use to enter text and click buttons)
What exactly do you mean by "next page" ? Does the form when submitted redirect to another page? If so, you will receive a HTTP 302/303 status code with the URL of the next page.