Sometimes, if we post a form in page A (to page B), then we refresh the page B.
<!-- page A -->
<form action="page-b.html" method="post">
<input type="text" name="data" />
</form
Then, when we try to refresh on page B, we was prompt to confirm whether submit the POST data again.
So, I'm trying to find a way to detect whether it has some post data (or http method to be post) on page B, something may looked like:
PS: jQuery is welcome
<!-- page B -->
<script>
if(window.has_post_data()) {
// do something in case
}
</script>
There is no way to accomplish that using pure javascript or jquery. Javascript has no record of the HTTP method used to load the page. The best way to work around this issue would involve having the server add some specific variable or markup if the method was post, and search for that variable or markup using javascript.
Related
The best explanation I've found for a postBack is from Wiki.
a postback is an HTTP POST to the same page that the form is on.
While the article does explain how a second page was needed in ASP, but no longer needed in ASP.NET, it doesn't give much detail or background. I am looking for a freakin' tome of information on PostBacks. Much like the simple question of "how can I clean a house" can be addressed by this 900 page book. I don't need 900 pages worth, but details please. I found a nice little tutorial for ASP.NET life cycle, but it seriously glosses over postbacks (amongst other things).
I am looking to the developers who have been around before .NET and really don't take these kinds of things for granted. Books and hyperlinks are reasonable answers or additions to your answer.
So far I've seen the right answer alluded to repeatedly, and almost everyone has come shy of what I consider subjectively to be the mark.
Let's start with the basics:
An HTTP request can be any of the HTTP verbs, but the two that people use most are GET and POST. Well, those are the two a programmer uses most frequently. The others all have some purpose, if they're implemented on the server. When you send information to the server, you can do so either through the use of the URL (to request a page) or within the body of the request (POST, PUT, DELETE, for instance).
Now you'll remark (I'm sure) that the URL in a GET request often contains data, and this is true, but according to W3C, you should not use GET to alter state, and yet we do often. It's sort of a hack that we all agree is an actual use, and not a hack. Whether that makes it a hack or an actual implementation detail I leave up to you.
So when you send the body of the POST (skipping the others for now, you can figure it out from here) with the form elements, you're sending back certain elements. How those elements are defined is up to you and to the environment you're working in. You could post to a server with a JSON element in the body, or with XML, or with form fields. Generally we do posts from a FORM element in the body of the HTML.
Now everyone says, "oh, a postback is a subsequent request to a page." But, that's not true. A postback is when you send data via POST -> back to the server. I say this because the difference between a GET request and a POST request is if data is included in the body (and the verb used, but the client usually knows how to deal with that). You could postback to the page on the first time the page is visited, and in fact ASP.NET has tools for doing that in the library. You could certainly have a desktop client POST data to a server (think Twitter) without showing any webpage at all from the server (ok, so twitter is probably not the best concept to use for an example here, but I want to illustrate that you can use a client that doesn't show the webpage, so no request is necessary).
So really what you should read there in "postback" is "I'm POSTing data BACK to the server for processing". It's presumed that you retrieved the page initially with a GET to show the user the <form> element that has <input> fields for them to interact with, and that at the end you're sending data back. But I hope you can see that it doesn't have to be in that order.
So here's something else to consider:
What if you gave the user a page with a bunch of <input>s and no <form> but instead, had a button wired up in javascript to concat all those <input>s with &value-n= and send them as a GET? Does the same thing, but violates that concept of only using GET for requests. (possibly) ensuing discussion encourages me to reinforce that GET should have no side effects (no updating values)
It's how come you can send someone a link to a google search, for instance. So we don't ALWAYS have to POST BACK to the server to get data.
Hope this helps.
Cheers
See ASP.NET Page Life Cycle Overview on MSDN for a good general introduction about what happens when a requests hits the server.
A PostBack is any request for a page that is not the first request. A PostBack will always be in response to a user action (triggered most commonly by a Button, AutoPostBack control or Ajax).
POSTBACK: Part of ASP.NET's contrived technique for hiding the true stateless nature of the web/HTTP behind a stateful facade. This results in complex code (IsPostback, ...), a hard to understand page lifecycle, many different events, ... and numerous problems (ViewState size, web-farm stickyness, state servers, browser warnings (not using PRG pattern), ...)
See ASP.NET MVC instead.
A post back is round trip from the client (Browser) to the server and then back to the client.
This enables you page to go through the asp engine on the server and any dynamic content to be updated.
here is a nice explanation
ASP.Net uses a new concept (well, new compared to asp... it's antiquated now) of ViewState to maintain the state of your asp.net controls. What does this mean? In a nutshell, if you type something into a textbox or select a dropdown from a dropdownlist, it will remember the values when you click on a button. Old asp would force you to write code to remember these values.
This is useful when if a user encounters an error. Instead of the programmer having to deal with remembering to re-populate each web control, the asp.net viewstate does this for you automatically. It's also useful because now the code behind can access the values of these controls on your asp.net web form with intellisense.
As for posting to the same page, yes, a "submit" button will post to an event handler on the code behind of the page. It's up to the event handler in the code behind to redirect to a different page if needs be (or serve up an error message to your page or whatever else you might need to do).
The Wikipedia definition of postback is pretty good, but I'd add the following:
A postback is a subsequent HTTP POST to the same page that the form is on.
If I have a page with a form on it and, rather than having my Submit button redirect the browser to another page that will process the form, instead have the Submit button refresh the current page (and perform some specific steps to validate/save the page, presumably), then that Submit button is said to have posted back to the current page.
Postbacks can be either full (refresh the entire page) or partial (in a case where AJAX is employed). A partial page postback will re-render only a part of the page (like a single drop-down list, a table, etc.).
In the old HTML, the only way to make something updated on the webpage is to resend a new webpage to the client browser. That's what ASP used to do, you have to do this thing call a "PostBack" to send an updated page to the client.
In ASP .NET, you don't have to resend the entire webpage. You can now use AJAX, or other ASP.NET controls such that you don't have to resend the entire webpage.
If you visit some old website, you would notice that once you click something, the entire page has to be refresh, this is the old ASP. In most of the modern website, you will notice your browser doesn't have to refresh the entire page, it only updates the part of the content that needs to be updated. For example, in Stackoverflow, you see the page update only the content, not the entire webpage.
Simply put this by a little code. Hope it is helpful to you.
When you firstly request the page url. you can view the source code of it in most browser. Below is a sample of it .
The essential of Post Back is actually call the __doPostBack which submit all the form data got from your firstly requested back to the server. (__EVENTTARGET contains the id of the control.)
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>
NHibernate Demo
</title>
<script language="javascript" type="text/javascript">
function dopost() {
__doPostBack('LinkButton1', '');
}
</script>
</head>
<body>
<h1>NHibernate Demo</h1>
<form name="ctl01" method="post" action="Default.aspx" id="ctl01">
<div>
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKLTMxNzcwNTYyMWRkKHoXAC3dty39nROvcj1ZHqZ5FYY=" />
</div>
<script type="text/javascript">
//<![CDATA[
var theForm = document.forms['ctl01'];
if (!theForm) {
theForm = document.ctl01;
}
function __doPostBack(eventTarget, eventArgument) {
if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
theForm.__EVENTTARGET.value = eventTarget;
theForm.__EVENTARGUMENT.value = eventArgument;
theForm.submit();
}
}
//]]>
</script>
<div>
<input type="hidden" name="__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="B2D7F301" />
<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwKZx5vTCgKM54rGBgLM9PumD20dn9KQguomfpAOdTG0r9Psa7al" />
</div>
<a id="LinkButton1" href="javascript:__doPostBack('LinkButton1','')">LinkButton</a>
<input type="button" value="testPostBack" id="testpostback" onclick="dopost();" />
</form>
</body>
</html>
Postback is a request during which ASP restores values of controls' properties from view state.
So I have a website which redirects to another part of the site ie, when pressing a button on "www.test.com" it reditects to "www.test.com/anotherpage". Now my problem is that I only want users to be able to access the second page when using the button and not just typing in "www.test.com/anotherpage" into the search bar.
So, is there any way to setup my page such that it cannot be accessed by the url but only redirected from another part of the website?
document.referrer
The value is an empty string if the user navigated to the page directly (not through a link, but, for example, via a bookmark). Since this property returns only a string, it does not give you DOM access to the referring page.
You need use Php code to login users and check sessions example like exaplain here: Login form and session example
of course you need basic know about Php
You could use a client or a server side technique.
Example of client side is Javascript, reading the document.referrer in the called page as #Barmar pointed out, and redirecting to the home in case the referrer is not from your home page.
The server side way could make use of parameters passed to the page, like a SESSION identifier that will be generate on the home page, for example and checked in the called page.
Actually there are a different ways to accomplish your goal.
You should provide some more info about the environment so we can help.
You can usee PHP. Simply put your button between form tags
<form action="http://www.test.com/anotherpage" method="POST">
<input name="mybutton" type="submit" value="Go to another page">
</form>
and on anotherpage
<?php
if (!isset($_POST['mybutton'])) { //check if the button was clicked
header('Location: index.html'); //forward to index if not
}
?>
I am trying something different to check if it is feasible. Otherwise best alternative way is to send data using querystring.
I have a html page which has list of students. when user clicks on perticular student for edit, this html page should take student ID and redirect to another html page, which will load respective student details for editing.
Here, I want to send data using "POST" method to hide studentID from URL (querystring), so I created a hindden form (method="POST" action="edit.html")on list html and put one hidden field under it. on lcik of edit button on list, I am setting value to hidden field & submitting form.
Now this redirects properly to edit html page and also when I see this flow in chrome developer tool, I can see this form value under headers sections - Form data. Now I am trying to fectch this form data on edit html page load e.g. in JQuery under document ready function or simple in javascript.
with alternative option if I create hindden form (method="GET" action="edit.html") then the hidden field value which I am setting is showing up in query string and also in chrome developer tool, it is showing under headers - query string parameters. This query string parameters can easily be accessed using location.search and then play around and will get expected value.
Here id I have taken just example, however in actual scenario, I need to send multiple values or may be objects which I dont want send thrugh query string. So I thought to submit form with POST method and retrive values on next HTML page load thrugh javascript on jquery.
HTML
<form style="display: none" action="jquerywebapidoestudenteditpoc.html" method="post" id="formEdit"> <input type="hidden" id="id" name="id" value="" /> </form>
JQuery
$(document).on("click", ".edit", function () { var id = $(this).data("id"); $("#id").val(id); event.preventDefault(); $("#formEdit").submit(); });
If anyone came accross this situation or implemented it in very appropriate way, would be very good.
In other words, I would like to implement is:
list.html will post data to server (.NET Web API)
At same time list.html will redirect to edit.html
On load of edit.html, response from server will be loaded on page.
Query string is part of the "identifier" of the subsequently loaded page (or any other resource). As such, it is accessible from the page. Data sent in the body of a POST request are different - they are meant for the server only and are inaccessible from the subsequently loaded page.
However, if you wish to make the data sent using POST available to the next page, you can always inject it into the page manually. Using PHP (as an example), it could look something like this:
<script type="text/javascript">
var postData = <?php json_encode($_POST); ?>;
</script>
If you just want to pass data from one page to another and leave the server out of it, you may either use GET (query string) for exposed communication or use cookies for "hidden" communication.
Bsically, what I understood after going through lot many blogs ans sites, I have to have a client controller (javascript based) which will take care of which view has to load and post data.
This I was able to achieve using AngularJS, where I can configuration can be done for routing and by same, I can post data & receive its whatever output on another view/ form (so called page).
e.g.
$routeProvider.when("/orders", {
controller: "ordersController",
templateUrl: "/app/views/orders.html"
});
AngularJS Rocks !!!
Say, I have a simple form on my website having three fields : name, password and email.
I have to get these information from the users, and keep in my database.
Then redirect to another website and send all these information using post.
I also have to know whether the user was successfully redirected to that site(HTTP STATUS 200).
Here's how I'm doing it:
For Point 1, I'm simply submitting the form.
After the data has been successfully saved in my database, I'm rendering the following form with hidden fields. This gets submitted and user gets redirected to anotherwebsite.com
<form id="form_id" action="https://www.anotherwebsite.com/form" method="POST">
<input type ="hidden" name ="name" value ="$name">
<input type ="hidden" name ="password" value ="$password">
<input type ="hidden" name ="email" value ="$email">
</form>
<script> document.getElementById('form_id').submit(); </script>
Problems:
I don't think my strategy to achieve point 1 and 2 is correct. I need a better solution. Submitting the form, then rendering a page with hidden fields and submitting it again to redirect to another site just doesn't feel right.
I have no clue to achieve the 3rd point.
Based on your question you might try this approach:
create a form with name, password, email fields in a file ( HTML ).
Submit the form to server.
On the server side get the data (including the form attribute in a variable) and save it to database.
then redirect to the given website ( using the variable you've stored in step 3 ).
You can easily know the status ( 202 or any error) using any of server side scripting language.
If you are sending the user to another website, the only way to know that the user was successfully redirected is for that website to notify you in some manner. Once the user leaves your page (and that's what a redirect is - it tells the browser "leave this URI and go to this URI instead"), the scripts on that page stop running, so they can't collect any further information.
If you just need to know that the information was submitted successfully, your script could POST the data in the background, wait for a 200 response, then redirect after the information has been submitted. But that may not meet your requirements, since you still won't know if the redirect succeeded.
Another possibility which does allow you to know whether the page on the other site loaded correctly would be to open it in a new browser window/tab instead of redirecting. This is the only way to keep your page active (and, thus, your scripts able to run) while loading another page. However, it introduces other issues, like what to do with the original page. (Leave it open in the background (likely to confuse the user) or close itself after seeing that the new URI has loaded (could cause undesirable visual artifacts as one window/tab opens and then the original one closes; destroys browser history)?)
If at all possible, having the final destination site notify you when the transaction completes is almost certainly the best way to go.
To achieve point 3 you need to use cookies if you are actually trying to implement a login-cum-membersarea system. Othewise, you simple need a redirect inside a condition statement.
my $cgi = CGI->new;
if (condition) { print $cgi->redirect('https://www.examplesite.com/file.html') }
for a general way of doing point 1-2, you can look at the tutorial here:
http://practicalperl5.blogspot.com/
I have a bit of a tricky work problem I hope to get some help with.
To handle various forms and storing entries, we use an in-house tool which I cannot modify. Basically what happens is:
I enter he URL the original page, and the URL of the destination page after successful submission.
The tool spits out some HTML and Javascript code, the most important of which is a unique URL, let's call it (redactedURL), that goes after the action attribute.
When the form is submitted, the page will refresh to one of two possible destination URLs: the one I inputted if success, or (redactedURL) if error.
I can download all the entries from the tool afterward.
The HTML is quite simple. checkform() is a simple validation script.
<form action="(redactedURL)" name="enenForm" method="POST" onSubmit="return checkForm()">
The issue with this is that I can't style the (redactedURL) error page, which is quite ugly. I am wondering if there is anyway I could
Suspend automatic display results of form submission
Determine the destination URL, and based on that, write out a custom thank you/error message (since I cannot access the server-side script, this seems to be the only solution to determine if the submission is successful or not).
Make sure that tool still properly stores all the entries.
Any help would be much appreciated. Thanks!
Don't use a form. Instead use AJAX. I think this SO Question will provide a start. Basically you use JavaScript to submit data to a server using XMLHttpRequest. The returned HTML is a string which you could either modify or (better yet) normalize and add to the DOM.
For an advanced example jQuery-Mobile does this concept when you click a link instead it gets the HTML from the server as an AJAX request copies the HTML inside the <body> and inserts it into the DOM.
Search for tutorials about AJAX and jQuery (or your prefered JS library). Like this one.