basically what I am trying to achieve is this (asp.net 4) :
If a user does a postback on an ImageButton or similar control it should cause a page Post, and go through the entire asp life cycle.
If this has just happened, and the user presses F5 or similar to refresh, it should ignore all events from the previous post and just do a regular Get.
If the user clicks Save multiple times it should register only 1 Post and not cause duplicates being created etc.
If there are update panels on the page, a Post should only update the panels data, whereas a Get(refresh) should reload the entire page.
I have had a look around and am currently using the Response.Redirect method (once processing is completed in a post it does a response redirect to the same page to replace the Post with a Get). This is unsatisfactory for a number of reasons
It causes unnecessary overhead doing two page Posts every save
I would like to have regions of the page in Update Panels, and at the moment if you change something and save it in one region, it reloads the entire page.
I found this similar SO question here which highlights a few methods, none of which looks like they will solve my needs. I also found this which is an interesting method, but I was wondering if anyone could tell me if it will solve all my above needs before I try implement it? Also, is the onsubmit event firing the only difference between a Post or a refresh mimicking a Post?
Regarding the 3rd bullet above, I have read about the jQuery .one() function, but I am looking for an application wide solution, as most of the app has been developed without this in mind.
Thanks in advance!
Related
I am forced to use Web Forms in my project, and sadly, Web Forms only allow - If I may - "Strict" Websites to be created.
Whenever you need a Button you need to put it in a form, and then you need another button which has nothing to do with the previous button, and you can't have 2 forms,
And the idea of putting a DIV that fires a server side (C#) method is kind of difficult, okay it may be easy but all I have found are "tricks", not an "official" clean way.
So I have this idea of making a webpage for each action in my websites.
For Example:
Let's say I wanna click on the ARROW that raises the rating of this question, I would put something like this.
HTML
Rate Up
And Some CSS Codes to make it look like a beautiful button...
Okay now this will take me to a page called Rating.aspx with 2 parameters, the first parameter is the ID of the question that I would like to raise its rating, and the second parameter is either UP (+rating) or DOWN(-rating).
On the Page Load method of Rating.aspx, I would update the database, then redirect to the question page.
This will work perfectly, BUT, is it a good approach? is it professional? (put in mind that there will be many actions to preform like that...)
With ASP.NET you better use server controls. Better way of implementing that is using or , that actually renders your anchor tag. But you can attach OnClick event handler to this control (link button) so after clicking there would be automatic POST to server. The same page cycle for the current page will take place (this is called PostBack) and your attached event handler will fire, where you can actually make changes to the database. So you don't even need to create any other pages for tasks like this. Every server control has specific set of events like OnClick for buttons or OnSelectedIndexChanged for dropdown lists. You can even create your own controls or derive from existing ones and create your own events.
Take a look on following links for more information:
Button Click
Event Handling in ASP.NET
ASP.NET Page Life Cycle
I have an ASP.NET form that the user can make lots of changes to, each time they make a change the page PostsBack and the details are updated.
If the user hits the browser back button they go back through all the previous versions of the page.
Is it possible to stop each PostBack being treated by the browser as a new page?
So the would make any changes they like and if they hit the back button it brings them to the previous form and not the same form but a different version?
I know I could use AJAX to update values but I'm not an advanced coder so trying to keep things simple as I haven't used AJAX before.
Ajax is your only solution.
There is no way to remove a page from the browser history. Javascript is explicitly denied the capability.
Now, you could, potentially, stop them from using the back button at all. Although this might result in unhappy users and I'm not 100% certain it works in all browsers.
function body_onload(){
window.history.forward(1);
}
You could use a trick to do it.
On postback you can set a session bit to true saying they submitted that form. On your postback check to see if that value is set. If it is they are trying to do it again and you can just abort it. It wouldn't prevent the postback per se but you could control the logic and prevent it from DOING anything.
I personally would explore ajax as Jquery provides some nice ways to do it and it'd be a learning experience but I suppose this would work as you are asking. On a per session basis. If you only want 1 submission ever use a database to store the activity.
You could use UpdatePanel: http://msdn.microsoft.com/en-us/library/bb386454.aspx
I have a menu on a .aspx page, which will load a specific user control depending on which menu option is clicked. This part is working fine.
The problem I'm running into is when I instantiate a post back from the dynamically loaded user control, the .aspx page is reloaded. Now after researching a few of the other questions on here, I gathered that I have to recreate the User Control each time the post back is instantiated. However, the question I have might be quite simple, but how do I reload the specific User Control (and fire an event such as OnClick) based on what is posted back to the server?
So my question is: What exactly gets passed back to the server on post back, and is there something in the post back request that will allow me to load the specific control? If there is, how would I get to it?
To do it the manual way, you would have to recreate the control(s) before ViewState is reloaded, like during OnInit for example.
There is a control called the DynamicControlsPlaceHolder that takes care of persisting dynamic controls for you. It's a definite time saver, and it makes persisting dynamic content easy.
Here is a link to the control:
http://www.denisbauer.com/ASPNETControls/DynamicControlsPlaceholder.aspx
To better understand what postbacks do, you need to understand the ASP.NET page lifecycle. Here is an MSDN article that explains it in detail:
http://msdn.microsoft.com/en-us/library/ms178472.aspx
Is there any pattern or kind of "least requirements list" to follow for ensuring an asp.NET application to support BACK button of the browser for each aspx page?
thanks
In general, the back button on the browser will take you to the previous HTML GET or POST that occurred. It navigates by page-wide transactions, so anything done dynamically cannot be navigated that way. Also, the back button doesn't rewind code execution, so if you are determining something based off of a Session variable or something similar, that won't be rewound either. Obviously, it won't rewind database transactions either.
In general, if you want to support the back button, you'll need to make sure to divide everything you need to navigate between with said button is divided by an HTML transaction of some sort.
Again, you're going to run into issues if your page display is dependent on server-side control that changes from one post to the next. This is one reason you see some forms feed a 'Page has expired' error when you try to navigate back to them.
Not really... It depends on your application flow.
There are things that make supporting the back button more awkward.
for example using pure ajax to change the majority of the content on the page,
will look like a 'new' page but wont be compatible with the back button (though you can fudge it)
another example is posting back to the same page more than once, as this can make it appear like the back button is not working, and at the same time re-doing your request (and therefore database transactions)
Fundamentally it depends on your application requirements.
How can I perform a redirect with Server.Transfer() to the same page that is currently shown?
I want to have A cleared form after submit.
What other/better methods can I use to achieve the same?
Why Server.Transfer? Response.Redirect(Request.RawUrl) would get you what you need.
http://en.wikipedia.org/wiki/Post/Redirect/Get
The most common way to implement this pattern in ASP.Net is to use Response.Redirect(Request.RawUrl)
Consider the differences between Redirect and Transfer. Transfer really isn't telling the browser to forward to a clear form, it's simply returning a cleared form. That may or may not be what you want.
Response.Redirect() does not a waste round trip. If you post to a script that clears the form by Server.Transfer() and reload you will be asked to repost by most browsers since the last action was a HTTP POST. This may cause your users to unintentionally repeat some action, eg. place a second order which will have to be voided later.