We Keep Coding

Php long script with client side callback

I'm have a very long process in a php script (generate a huge pdf).
I have a button in my HTML page that launches the php script and I'd like to show a kind of progress bar or at least an animated gif and when the php script is over, display the generated pdf.
The generation of the pdf may last 15 minutes so the php engine exits in timeout and the browser too.
I there a way to declare a kind of client-side callback that would be invoked as soon as the server side process is over ?
Thanks for your replies
Edit :
Thanks for your replies :)
If I well understand, I must launch the process on server-side and "detach" my client i.e do not wait untill the process is over. Instead, my client should periodically check the progression of server-side process. Right ?
If so, I may use the following scenario :
The client sends an ajax request to the server. The server launches
the process and returns a guid to the client. This guid identifies
the job.
The client periodically checks the progression of the job
via an Ajax request, from its guid.
Once the job is over, the client can issue a last Ajax query to
download the PDF
That means that the server must save the generated PDF on its disk and wait for the final Ajax request to send the file and delete it, right ?

For something as long as 15 minutes, I wouldn't even use web sockets for this. 15 minutes is a long time and there's really no telling what the user is going to be doing in the meantime. A disconnected notification process is probably going to be more reliable in this case.
Consider something like:
User initiates process, whereby a record is stored in the database "queueing" the process to take place.
User is immediately presented with a page indicating that the process has been queued and that they can continue to use the application.
A separate application which runs periodically (every minute? every few minutes?) checks for "queued" processes in the database, updates their status to "in-progress" (so subsequent runs don't also pick up the same records), and processes them.
As each process completes, it's either removed from the database or updated to a "completed" status.
The user is otherwise notified that the process is complete.
This final notification can be done a number of ways. An email can be sent to the user, for example. Or consider a user experience similar to the Facebook notification bar. Each page in the website can check for "completed" processes when the page loads and present a "notification" in the UI which directs the user to the result of the process. If users spend a lot of time on any given page then this would be a good place to use web sockets or long polling via JavaScript to keep checking for completed processes.
The main thing is to separate the user interface from the long-running process. Web applications by design aren't suited for processes which run for that long. By separating the concerns the web application can focus just on the user interface and the command-line application can focus on the processing. (As an added bonus, this would prevent users from over-loading the server with too many concurrent processes. The command-line application can just run one record at a time, so too many concurrent processes just slows down the response, not the server.)

as #David said, but no one has covered the progress bar, the implantation of this depends on what you know ( you being the application creating the pdf ).
Do you know the size of the pdf when complete.
Do you know how long
it will take to generate.
Do you have code where you can hook into
to update the progress.
The application needs a way to know when to update the completed percentage, and by how much. If you can do that then you can either store the progress in the database with the script that crates the PDF and read it on a user facing page, or store it in a file, etc..
jQuery UI progress bar is easy to use, but you will have to know what percentage is done to be able to tell the end user.
After that it is a pretty simple matter of using ajax (jquery $.post ) and a file, that's how i do it. I just wright a simple text file with a number representing the completion percent. Load it via ajax and feed it to the jquery ui progress widget.

jQuery post big text data transfer (eventual load)

The problem:
I have a jquery ajax (post) based website, where the website doesn't refresh every time user navigates to another page. Which means I have to pull data with ajax and present it to the user. Now for pulling small text data, this system works great. However once the text data is huge (let's say over 200,000 words), the load time is quite high (especially for mobile users). What I mean to say is, ajax tries to load full text information and displays it after it is done loading all text. So the user has to wait quite a bit to get the information.
If you look at a different scenario, let's say wikipedia. There are big pages in wikipedia. However, a user doesn't feel he/she has to wait a lot because the page loads step by step (top to bottom). So even if the page is large, the user is already kept busy with some information. And while the user is processing those, rest of the page keeps loading.
Question:
So is it possible to display, via ajax, information on real time load? Meaning keep showing whatever is loaded and not wait for the full document to be loaded?

Ajax (xmlhttprequest) is a really great feature in html5, for the same thing, ajax is better than socket, by that, I mean non-persistant connection but as soon as the connection is persistant (impossible for xmlhttprequest)socket is fastest.
The simplest way is to use web socket is socket.io but you need a JavaScript server to use this library and there is one host where you can get one for free with admin tools: heroku.
You can use PHP server if you dont want to use JavaScript server with the socketme library but it is a bit more complex.
Also, you can think diferently, you try to send a lot of data.
200 000 words is something like 70ko (I try a lorem ipsum), the upload speed is relative to data and connection speed/ping. You can compress by any way your data before sending and uncompress server-side. There is probably thousand way to do this but I think the simpliest way is to find a JavaScript library to compress/uncompress data and simply use your jquery ajax to send what's compressed.
EDIT — 21/03/14:
I misunderstood the question, you want to display the current upload progress ?
Yes, it is possible by using the onprogress event, in jQuery you must follow this simple exemple: jQuery ajax progress

hide the path of the php file in ajax request

I dont know if this possible
But I have an ajax function in my javascript and as all, we know we need to provide php file path in the ajax request and this will be visible to all the users and unfortunately they can see the path of the ajax files and where they are stored .but i dont want this to happen i dont want user or client to see my ajax filed Is there a way to hide this path from the client, from seeing the path of ajax files? i know its something obfuscation but i only want the path to be done is it possible?
Update
so is there any way to stop user from viewing or opening php files from the url, I mean if user enters the path of ajax files and hits enter he can see all my files over there and he can easily hack my data so is there a way to stop user from entering them , i want only my pages to access php files not from users url,Thanks

It is not possible. The browser has to request the URI. The user can see what resources their browser is requesting.
"Ajax files" are not a special case. You need to secure them in exactly the same way as any other resource you provide over HTTP. i.e. use authentication and authorisation to make sure that only users who are allowed to access them do, input validation to make sure that any data sent to them is acceptable, and escaping to make sure that the data doesn't cause you problems if you try to insert it into SQL/HTML/JS/any other data format.
Response to update:
so is there any way to stop user from viewing or opening php files from the url
Still No!
I mean if user enters the path of ajax files and hits enter he can see all my files over there
You can configure your server to not serve a DirectoryIndex. The specifics depend on the server. Alternatively you can put a blank index.html file there.
and he can easily hack my data
How?
so is there a way to stop user from entering them
No.
i want only my pages to access php files not from users
Only an HTTP client can request a URI. There is no way to distinguish between an HTTP client responding to an instruction from JavaScript that you have written from one that is responding to user input.

a possible way would be to obfuscate it so that its not user readible. expl; by using a main script and including the file by switching on some POST/GET param your sending (could be a random string, hash, number).
more efficient obfuscation can be acchieved, when you would redirect all traffic to one script via mod_rewrite. Somewhere in the url, you hide a number, that tells you which file to use. Then you add random string before and after it (with specific length) and read it from your main script. But then the user will find out by looking at the javascript.
but srsly. why do you care? there is no security by obscurity!
/updated to your updated question;
I think you want to be looking at your apache configuration; use .htaccess files or better, disable indexing of a directory all together. The user wont be able to know about all your php files. Only the ones, you made public via links in your application. There is no such thing as "only letting ajax access file but not the user". because ajax IS the user and vice-verca! you are sending ajax request on behalf of the user! and if the user enters the url in the browserbar, its the same as sending an ajax request.
You could add a special header with your ajax call (or use the one already supplied), but that wouldn't change anything, as soon as the user looks at the traffic close enought.
What I think you want is a User Session to only allow privileged users to fully execute a script.

Unless you are using jsp technology with apache tomcat, you can place your folders in the WEB-INF.

No.
This is not possible. The client performs the request and the client is under the users control.

How to update asynchron pages upon event from other client?

I'm currently fooling around with AJAX. Right now, I created a Markdown previewer that updates on change of a textarea. (I guess you know that from somewhere... ;-) ).
Now, I'm trying to figure out, how to update a page upon an event is fired from another client. So to say an asynchron message board. A user writes something, an event is called, the post is written.
But on the other clients' pages, the new post is of course not yet available until they reload and get the updated list of posts from the database.
Now, how can you get this to work asynchronously? So in that moment when one client does something, the other clients all get to know that he did something?
I don't think this can be done completely in AJAX, but I also have no idea whatsoever how to implement this on server-side, as it would require a page reload to inform the other clients of the event.
I'm thinking of creating a file or database entry that hashes the current state of data. Whenever a client loads the page, he saves this hash. Then, a timer (does this exist in JavaScript?) checks for the hash every few seconds.
As soon as anyone changes the databse, the hash is recalculated. If the script sees that the hash was changed and is different to the one saved, it reloads the contents form the database and saves the new hash.
Is that even going to work?

Polling that is light as possible is really the best solution here. Even if you did use a socket or something... That's still basically a live connection waiting around that will likely have to poll itself (albeit in a more effecient way).
20 queries in 10 minutes that have responses like {"updates":false} shouldn't even be putting a dent in your application. I mean imagine someone browsing your site requesting 20 pages and the related images/scripts/etc (even if some caching is involved), there could easily be hundreds of requests requiring all sorts of wasted database queries to information to be displayed on the page they don't actually care about.

You could use polling. For example each client might be sending continuous AJAX requests to the server say each 30 seconds to see if new posts are available and if yes, show them:
setInterval(function() {
// TODO: Send an AJAX request here to the server and fetch new posts.
// if new posts are available update the DOM
}, 30 * 1000);
On the other hand when someone decides to write a new post you send an AJAX (or not AJAX) request to the server to store this post in the database.
Another less commonly used approach is the concept of Comet and the HTML 5 WebSockets implementation which allow the clients to be notified by the server of changes using push.

Is there a good way to remotely get javascript debug information from an end-user?

I've been trying to solve a Javascript problem on my company's site that a single user has reported, but have exhausted all possible fixes I can think of. To do more, I'll need more information about what's happening in the user's browser. Can anyone suggest a bookmarklet or other tool I can send to this user to print a log of all Ajax calls and exceptions raised, so the user can send it back to me?

I ended up using Firebug Lite. An automated system that could send me the information directly would have been better, of course, but there wasn't time to set that up. Thanks for the suggestions!

Log all the information you want in a cookie and have the customer send the cookie back to you.

There are a few framework for logging to the browser console in JS, log4Javascript is the one I've used and had good luck with. Alternately, you could send back relevant log information in an AJAX call to a server-side script that writes out a client log and the customer wouldn't have to mess around with sending logs or cookies.

A try-catch block around the "suspect" part of your code.
- and some form of submit in the catch-part, sending details of the incident back to the server - eg. via a form-submit in a hidden iframe or Ajax..