When we use asp.net pages we can navigate from one page to another via more than one method.
This issue becomes more comlicated when you want to keep the history of current user navigation.
Lets say we have a form. The user will start to fill it, by adding values to one or more fields, but on my case he can create a navigation to another page before we posting-back the current page and thats ofcourse couses the controls to loose its values.
How can i keep the controls states through postbacks between asp.net pages.
Should i use the SessionState or maybe cache it for each user?
thanx
You pretty much have the choice of session state, cookies, or home grown state maintenance using a database. I typically get around this by combining all my pages into separate panels within a single .aspx. That way I can use object persistence and viewstate. Rather than navigating from page to page, I merely have to toggle the .visible property of different panels depending on my users' navigation choices.
RO
The answer mostly different in different application types. For example if you plan that your application will have a lot of people storing in session become an expensive operation, but for small applications it work good.
In all cases you can create some mechanism that will store temporary entered data into database, this approach will work everywhere, but it's slowly than in memory cache.
To give correct advice please explain a bit more about your application.
You could use Session variables or the ASP.NET Cache object to store state so that the user can resume filling in the form after navigating away from the page. However, if the issue is that the data entry is a lengthy process that the user may wish to pause and resume at a later time, give them the option to save their current progress to a database. If the user attempts to navigate away from the page, remind them that they may lose their current work and give them the option to save it.
Related
I recently switched to ASP.NET Web Forms from Windows Forms and I have an issue with something I would not expect. In good Web Forms I could create a field inside my Form class and assign to it. So if I wanted one control to raise a flag on one event (say user button click) I could declare Boolean and assign to it from my form methods. Then I could check the state of the flag from different methods on different events.
It looks like it's not so much in Web Forms. The value of my fields (or global variables if you will) remains unchanged from the moment I initialized them.
This is probably simple thing but for me it's quite a frustrating problem. I could store my vaues in session but I don't think that it would be a right way to do it. The problem is I need to store a lot of variables since I write code for SQL interface applications. Never had a single problem in Windows Forms and in Web Forms I keep pulling my hair.
Ultimately I need to store objects to reuse them like LINQ to SQL classes objects so I would really appreciate some guidance.
I suggest you review PostBacks, Page life-cycle and how ASP.NET processes client requests . In order to better understand ASP.NET forms, you should take time to read up on the page life-cycle, events and the order in which they are fired. That way you understand why it seems your variables are not being updated.
you should also read about State management like viewstate , session ect...
put your page_load contents that you don't want to execute after button click to the following condition:
if (!IsPostBack)
{
// do something
return;
}
I want to pass data directly from one view to another in the two following situations:
Our users are allowed to dock and undock a toolbar that is persistent thoughout our application. I want this state to be saved when the user navigates to another page. The toolbar is docked and undocked using jQuery.
In some cases, after a successful response from an AJAX call we have a full page refresh or a redirect. We want to display a notification to the user after the refresh / redirect (eg. Your action was successful).
My initial thought was to use cookies, specifically using jquery-cookie, but I was then wondering about using the Session[] variable. Given that our JavaScript will be in an external file I don't know if this is possible and if so does it simply complicate the issue?
Have you looked at Lawnchair?
http://brian.io/lawnchair/
Sounds pretty much like what you need. It is used to persist client side data across pages.
My application required me to store many data elements across views an sessions. Rather than pick a storage mechanism up front (mostly because management couldn't decide) I coded my app using persistence.js.
I was able to pick the precise storage mechanism later with minimal impact to my code.
I faced same type of problem.
after workaround I use a jQuery cookie and store the hidden panel id.
and check the cookie in $(document).ready(function(){}); of jQuery that which panels are hidden and after make their display:none.So after postback the cookies are persist and the panels became hidden.
It solved my problem.
You can do this by simply sending your toolbar state information through hidden fields back and forth ( means from MVC view to controller and than from controller to MVC view ).
I have this application:
I want to change the marked area when the user is clicked one of the navBarItems (like Microsoft OUTLOOK). I've been doing some research and a lot of people said that I can add several panels and show/hide them when user is clicked a navBarItem. But the area will contain a lot of gridviews and a lot of other controls. I don't know if I want to initialize all of them when application starts because it's gonna be hard on the cpu and memory to keep all the controls running at the same time. And I don't think it's an elegant solution for this kind of situation. But if I choose to initialize controls when user is clicked to corresponding navBarItem, it's gonna be laggy for the user.
What is the best design approach for this situation?
PS: I can use commercial libraries too.
Thank you.
Does not necessarily have to be laggy. If you show the screen first and then populate the data in the background it may not look too bad for the user. Also, once a particular screen is initialized you might keep it in memory so subsequent times user navigates to it it will be faster.
Also, look at what data you are loading into each control. Is some of the data the same? Can you preload some of the data in the background and keep it around?
Do you have a lot of drop down lists? If so, can you prepopulate or cache some of the drop down list data to improve the performance?
Is there one or two of the panels that will be used a large majority of the time? If so you could preload these panels so the user has a better experience for the panels they will most often navigate to.
Background processing to load data will make your code more complex but that is going to be the best way to get good response time from your app.
Here is an example of running a background thread from the UI using Task.
And another one using the BackgroundWorker.
I have a simple three page asp.net webforms site and having an issue with the back browser button that throws the popup "...Firefox must send any information that will repeat any action.." when hitting back on the step3.aspx.
The flow is: user lands on step1.aspx, session starts, and a user quotes on a product and gets redirected to step2.aspx. On step2.aspx, you confirm the purchase by clicking an asp:Button. The OnClick event handler, btnPurchase_Click, handles the logic for purchase and redirects, Response.Redirect("step3.aspx"), to step3.aspx. Step3.aspx simply displays the confirmation page (receipt details). The session is destroyed on step3 and when the user hits the back browser button, they are prompted with the resubmit post popup. Ideally, I want the user to hit step1 on hitting back without the resubmit prompt. Each page is set to no-cache and redirects to step1 if session is invalid.
Does anyone have a suggestion for a better flow?
This site will eventually be migrated to asp.net mvc/ajax which will most likely make the PRG workflow easier to implement but for now, looking for a relatively simple way.
A simple solution is to never allow a page to render on postback, but instead accept/store whatever information it was posted, and then redirect to the next page (or itself).
That way if a user hits the back button, it is going back to a GET, not a POST, and avoids the popup.
I give this question a try. The flow you mention will obstruct the pages normal function, which you of course already have in mind. Though, i would say it can be dangerous (against the function you expect) and contraproductive. Based on what I can see from your question, I would definitively remove Page2 and Page3 and keep all logic in same and single page.
I would also be happy to hear what you are trying to avoid, with this? Is it double posts? Like a double-post of a content in a shopping cart? Partial / uncomplete inserts of data input? With the described way to affect back-buttons, you may come around one problem but rise another. A big range of browsers that can act completely different on such work-arounds.
I see two good options,
UserControl,
Create three UserControls which every each of them have each page specific logic. You can programmatically load them into the page. I.e. on bnButton_Click Event. Usercontrols are loaded with LoadControl("PathToAscxFileOnDisk.ascx").
Panels,
I would also think about three <asp:PlaceHolder></asp:PlaceHolder> or perhaps better <asp:Panel></asp:Panel> to put all logic into.
In this case you are completely free from the postback issues and can focus on moving your functions into business logic and have use the Code-File to control the flow on show/hide and populate the controls in/out from the panels/usercontrols. You can probably also control the postback / click-URL & push-enter-key.
And you mentioned Ajax,
Ajax is absolutely there to make your page stateless (which means you can work without cache, sessions, viewstate and so on. Though, the problem lies in the users possibility to navigate between pages. I would think even Ajax is of less help, while you keep the three-pages-solution.
I would personally say it is a simple task to move the aspx files into each ascx and create a aspx as a master-container. With that option you even avoid duplicate namings (like if you copy / paste the code into panels) and trouble with Page_Load flow/logic.
If I understand correctly you're not yet using the PRG.
On step 2, temporarily store the information and redirect to show it. How you do so depends a lot on your application: session, database, cookies, etc are all options with different caracteristics.
Then redirect to show that information.
Same goes on step 3.
If you hit back on step 3, you'll go to step 2. But given you're going back to a GET request, there won't be a warning. Like you said, your application destroys the session data on 3, so according to what you said the user would go to step3.
Maybe I'm missing something on what you said.
I am using WPF Page navigation in a c# windows based application. There are a series of pages that I am creating like this
Page TargetPage = new myPage01();
TargetFrame.Navigate(TargetPage);
The first-time page creation and navigation are working fine, and because I am passing by object the pages are kept alive for me to reference at a later point.
When the user hits the last page (all different views of the same data) and clicks the next button I want the UI to "loop" around to the first page. I am trying to figure out how I can redirect the frame to that first page. I do not want to rely on the built-in journal history within the GUI itself. How can I reference the first page previously created or for that matter any of the previously created pages by referring to it in the code. All the page navigation examples I have come accross are always creating the page as new or using the back or next to navigate to other pages.
Thanks
I do not want to rely on the built-in journal history within the GUI itself.
If you do not want to do that you need to keep track of everything yourself, which i would not recommend unless there is something wrong with the build-in functionality. You can probably find the first page to be the last item of the BackStack.