I've been designing a site that is used to collect data, but the person I'm designing for wants some form of redundancy just in case the window is closed or the system shuts down. Is there any way to take data that's been collected and write it to a MYSQL database if the user is disconnected for a certain amount of time, or if they shut the browser window/shut the system down without submitting the data?
The web is stateless and disconnected - so all data will (or rather: should be) persisted between page requests.
I assume you have a web-page generated by PHP that contains a lengthy data-entry form, and you want to save the data in that form in the event the user closes their browser window - the solution is to use a client-script that polls the server with the current data in the form, or at the very least hooks on to the window close event.
Actual implementation is a task left up to the OP.
This can't be done just with a pure HTML page - if the user doesn't submit the form, your server doesn't know what they've typed.
However, you could put some Javascript on the page that made an AJAX call every few seconds (or every few key-stokes or clicks). The idea would be for the JavaScript to invisibly submit the whole form to a PHP page which saved it into a sort of "holding area".
If the user then submitted the form, the holding area could be cleared out, but if they never did, then the data in the holding area would show you where they got to.
The most common techniques to partially prevent this szenario is that web apps work with a heartbeat-function which fires via javascript in a constant interval and sends a request to the server, p.e. to show that the user is still logged on - or, in your case, maybe to submit data already typed into form fields, too.
Think of it as an ajax-powered auto-save-function!
You have to add some javascript to your code for this, but the commonly used javascript libraries, like jquery or mootools, are well documented and offer alot of examples how to do something like this.
Related
I've designed a forum on my website that operates through AJAX requests therefore the URL does not change at all. You click a button, the AJAX requests a PHP file, and the response updates the client. This works for me - however, I need to know if it's possible to redirect a user through a series of AJAX requests after a form submission.
User enters forum.php page
User clicks on topic button (AJAX request to load threads)
User clicks on thread title (AJAX request to load replies)
User clicks on reply button (AJAX request to load text editor)
User clicks on submit (AJAX request to submit form)
At this point I want to redirect the user back to that specific thread - therefore I believe they would need to be directed through a series of AJAX requests. Is this possible?
Extra: Also if you believe this forum process is not efficient please let me know your opinions.
Seems you have a few options:
continue to use Ajax for the submit, so no need to redirect. (EDIT: sounds like you are already doing this, so the problem is probably you are discarding the content you want to display, rather than just hiding it temporarily)
implement a way to load a page directly to the forum. This would be in addition to the ajax call. You would track the forum ID, include it in $_POST parameters, and have the server redirect to the appropriate URL.
Generate javascript (or approriate fields/data for your fixed javascript to use) that will cause the page, when reloaded, to automatically make the necessary AJAX calls.
Skip Ajax and just use full page loads for everything
Mixing things up, by sometimes using Ajax and sometimes using a page load isn't ideal, but it is sometimes difficult to avoid completely.
Keep in mind what happens when user hits the BACK button or history in the browser. Do you want them to leave your app when hitting back? They can end up in a weird place mixing ajax/page loads. For this reason, people favor (4)
(2) is probably a lot of work.
(1) would be ok, and BACK button will just always take the user WAY BACK to some other website. Personally, that wouldn't bother me.
(3) would be a pain and also be slow, and then you get pretty weird forward/back behavior. Avoid.
(4) might just be best.
I'm making a simple mobile web app where users should be able to login/authenticate to sign up for private events.
I love the way JQuery mobile looks and feels, but want PHP to do everything in the backend: Handle form processing, talk to the DB and so on.
I currently have no authentication, but want to add that.
Wrapping the current solution in Phonegap actually worked, but I suspect the authentication/session handling is going to crash with that.
My hope is that I can exchange data with a PHP script when:
- the form loads (to check for PHP user session etc), and
- a "submit" button is clicked.
I covered the submit button part, and it works. Data is sent to, and returned from my PHP processing script to the JQuery front-end.
For handling the submit event, for some reason this code worked:
$(document).ready(function(){
as opposed to an onclick thing which didn't work.
This baffles me, as I read that document.ready is an event that occurs when the document has completed loading.
Q1: Could this have something to do with me using Jquery mobile sections (
Q2: What would be the correct JQuery event/trigger to use prior to loading, to control form "context"? (based on data from backend PHP).
Q3a: Is it a viable solution to rely on PHP sessions in such a case?
Q4: Also considering that I'd like to Phonegap it...will a PHP session be able to "see" the Jquery-based, phonegap-wrapped app like a client session just like if it was someone using a web-browser?
4b. When does a Phonegap app user session "end"? (When does the user have to log in again...).
I know similar questions have been raised several times, but please consider I'm a gullible idiot that knows too little to understand which case is similar enough to mine. There are some concepts here that I need to grasp before I can decide what to investigate and ask about :-)
Here's to tolerance and understanding! Cheers!
Eivind
You can store mobile id and users id in database with flag logged_in when they first logged in. Then again if user open that app, you can check the mobile id with the record in database whether user is exists or not and if exists then whats his/her status.
There might be some cases that your request takes long time because
of some problems with your client internet connection or your server
connection. So since the client doesn't want to wait he clicks on the Ajax
link again which sends the request to the server again which messes up
the following:
Rendering of our website in the browser because we are giving extra
load to the browser.
What if the second request processed correctly and you showed user
the page and then comes along the error message from your first
request(saying request timed out) which loads above on the correct
content and mess up with the user reading the correct content.
I want to stop the 1st Ajax response if the Ajax function is called twice. How do I do this?
so i want to stop the 1st Ajax response if the Ajax function is called
twice
What you actually want is to prevent a second request when a first request is in progress.
For example, You may have to change the Save button to Saving..., disable it (and add a little progress wheel) to give live feedback to the user. (Facebook does this)
The key is love feedback to the user. If the user is clueless on what is going on, they are going to think nothing is happening.
You might want to check why the operation is taking long
If this is a complex/time consuming operation, like, say a report generation or a file upload, a progress bar should do
If this is because of the client's internet connection, say it up front, like Gmail: Your have a slow Internet connection and this site may be slow. Better still, provide a fallback option, with less/no Ajax.
You say cause we are giving extra load to the browser: this is kind of fishy. You will not be giving extra load to the browser unless you are giving it tons of HTML to render. Use Ajax only for small updates on the browser. You may want to reload the page if you expect a large change.
How bout seeing as your using some form of JavaScript to begin with you have that link either hidden or disabled in a manor of speaking til the pages request has been followed through with. You could for example have the requested ajax wait for a second variable that would enable that link so a user could click it. But until that variable is received from the original AJAX request its disabled to the click, then if it is clicked it disables again and waits for the same variable to come back again.
Think of how some developers disable a submit button on a form so a user can't double submit there form.. same concept of notion here.
So I am very new to this concept.
So why not go headfirst :) Some things I don't understand;
What happens if js is disabled?
If using mysql databases (ie; checking forms and such) why not just use php?
To confirm what others have said, disabling Javascript will also disable the AJAX call. After all, AJAX stands for "Asynchronous Javascript and XML".
To address why you can't just use PHP, there are some things that just can't be done without it. PHP is great to load the page with the initial information, but after the page is loaded, it actually requires the page to be reloaded to load something else. AJAX allows you to get around this hassle.
For your example of form validation, AJAX can be used to validate the information while the person is filling it out. Otherwise, you are required to reload the page each time someone fills out another field in the form.
Another example is from a project that I have worked on. The form required a zip code and would load the appropriate city and county based on the inputted zip. Using strict PHP, I would need the client to download the entire zip table embedded in the HTML/JS (which would add another 100k at least to the download).
Using AJAX, I can get around this. The user can input the zip code, which triggers an AJAX call that downloads the few rows that I need (this will be less than a few hundred bytes, for comparison).
[Edit:] Also, a tip because you said that you were new to AJAX. If your dealing with some form of authentication (logging in, etc.), remember to validate the user on the AJAX pages themselves. Otherwise, tricky users will be able to access sensitive information for your database.
Ajax just adds to the user experience and allows a web application to feel more like a desktop application to users. So they can delete a record and stay on the same page without reloading, you just let the record disappear.
And remember to validate on the server-side, even if you validate on client-side. Your weakest at your client-side as someone can easily just submit the values straight to your script so ALWAYS check on the server-side and do client-side if you would like to add some nice effects etc.
But you will always need to keep in mind that there are people out there who have javascript disable be it a security policy or just because their paranoid. So when you don't have JS enabled you javascript and AJAX requests won't work. So while developing you will need to make sure that if javascript is not their to do the operation that the form is submitted just like a normal HTTP form, this will allow all those paranoid people to also use your application :D.
OR you could always just deny access to those who don't have Javascript enabled but that's not very nice ... So if you want to check if they have javascript enabled checkout - http://www.w3schools.com/TAGS/tag_noscript.asp - for a example.
AJAX is a Javascript client based technology. If js is disable it simply doesn't work.
Php is a server based technology.
In Php you write pages that are dinamically built by the server. Once built they are sent as html to the client.
Using javascript (and Ajax) you can call the server just to request some datas (hint: look at JSON) or just a little html snippet which is plugged in the current page directly by the browser without requesting a full refresh from the server.
With js and AJAX you can achieve a very rich client experience without reloading a full page every time.
I believe nothing will happen if js is disabled. You need js to grab the data.
If you want to use mysql databases, you can use js to access a php script, which can then return any data gathered from a database, rather than doing it in the page.
AJAX is a way for Javascript (client side) to access PHP/ASP/Whatever serverside language you are using. This means, that if you have an PHP script for getting some data from your MySQL database, and want to run that script when the user clicks some random button, AJAX can do that (async)m and you wont have to reload you page to execute the PHP script.
If Javascript is diabled, AJAX won't work.
I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:
To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier.
Since application is built in such way that going Back is a quite common operation, this is really annoying to end users.
Basically, I would like to do it the way this page does:
http://www.pikanya.net/testcache/
Enter something, submit, and click Back button. No warning, it just goes back.
Googling I found out that this might be a bug in Firefox 3, but I'd like to somehow get this behavior even after they "fix" it.
I guess it could be doable with some HTTP headers, but which exactly?
See my golden rule of web programming here:
Stop data inserting into a database twice
It says: “Never ever respond with a body to a POST-request. Always do the work, and then respond with a Location: header to redirect to the updated page so that browser requests it with GET”
If browser ever asks user about re-POST, your web app is broken. User should not ever see this question.
One way round it is to redirect the POST to a page which redirects to a GET - see Post/Redirect/Get on wikipedia.
Say your POST is 4K of form data. Presumably your server does something with that data rather than just displaying it once and throwing it away, such as saving it in a database. Keep doing that, or if it's a huge search form create a temporary copy of it in a database that gets purged after a few days or on a LRU basis when a space limit is used. Now create a representation of the data which can be accessed using GET. If it's temporary, generate an ID for it and use that as the URL; if it's a permanent set of data it probably has an ID or something that can be used for the URL. At the worst case, an algorithm like tiny url uses can collapse a big URL to a much smaller one. Redirect the POST to GET the representation of the data.
As a historical note, this technique was established practice in 1995.
One way to avoid that warning/behavior is to do the POST via AJAX, then send the user to another page (or not) separately.
I have been using the Session variable to help in this situation. Here's the method I use that has been working great for me for years:
//If there's something in the POST, move it to the session and then redirect right back to where we are
if ($_POST) {
$_SESSION['POST']=$_POST;
redirect($_SERVER["REQUEST_URI"]);
}
//If there's something in the SESSION POST, move it back to the POST and clear the SESSION POST
if ($_SESSION['POST']) {
$_POST=$_SESSION['POST'];
unset($_SESSION['POST']);
}
Technically you don't even need to put it back into a variable called $_POST. But it helps me in keeping track of what data has come from where.
I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:
Your reasoning is wrong. If the request is without side effects, it should be GET. If it has side effects, it should be POST. The choice should not be based on the number of parameters you need to pass.
As another solution you may stop to use redirecting at all.
You may process and render the processing result at once with no POST confirmation alert. You should just manipulate the browser history object:
history.replaceState("", "", "/the/result/page")
See full or short answers