Hello Dae,
I get it now. However, as I have worked through this application, I
have decided on more functionality that adds to the 'requirements' of
the application. Basically, I need a Javascript 'Progress Bar' to let
the User know things are working. I also need to partially control the
progress bar from the server side. What I plan to do is simply use a
client side progress bar (so it is really a 'guesstimate' of progress)
and control from the server side if it is displayed or not.
Here is the flow I see before I added this requirement:
1. User clicks on link for some_page.php which loads.
2. Refresh in some_page.php asks for file_gen.php which starts creating
a file.
3. While user is waiting, the 'progress bar' on some_page.php begins.
4. file_gen.php completes file and sends to client.
5. User does a 'Save-As' (or Open-With etc).
6. some_page.php is still open and progress bar is still executing.
This is misleading since the progress is complete.
Here is what I propose, which minimizes the refreshes, but still allows
control over the progress bar. Let me know if this makes sense.
Better method:
1. User clicks on link for some_page.php which loads, with no progress
bar.
2. User specifies file creation parameters and clicks submit (manual
refresh).
3. Server sends back some_page.php with Javascript progress bar
started.
4. Refresh in some_page.php asks for file_gen.php which starts
creating file.
5. While User is waiting, the 'progress bar' on some_page.php
continues.
6. file_gen.php completes file and sends same some_page.php to client.
7. some_page.php now has a progress bar at 100%.
8. some_page.php also contains a refresh to a now existing file.
9. Page refreshes and User does a 'Save-As' (or Open-With etc).
10. some_page.php is still open with progress bar at 100%.
11. User can go back to step 2, which causes the progress bar to be
removed.
Note: The 'some_page.php' is actually a small dialog with only 2 small
jpegs. The file to be created can take up to 30 seconds on a FAST
machine. (Long story) If either of these facts were not true, I
wouldn't really like the above solution. But, I think in this case it
is the best solution.
Thoughts? Have I 'got it' now? :)
Thanks,
Eric
Daedalus.OS wrote:
Dae,
Without a request from the client for another 'page' won't I receive
the 'Headers already sent' error?
Eric
No. The thing here is that since you're calling it as a new page with a
<META HTTP-EQUIV="refresh"...>, the browser is actually waiting to receive a
totally new page with new headers. All what the page you call have to do is
making the file, send the proper header and the file. Since you're making it
as a Content-Disposition: attachment, the new page will not replace the
actual page in the browser but prompt to save it to disk instead.
So here is a simple view of what is happenning when a user click the link to
some_page.php:
-The browser receive the header for that page and display the page.
-Then the meta http-equiv="refresh"... attempt to refresh to file_gen.php
-The browser think he is going to another page and wait to receive the
headers
-file_gen.php create the file and then sends the headers + the file
-Browser receives the headers and see the Content-Disposition: attachment,
this mean (for the browser) do not display, prompt for download.
(This is a simplified view ... of course)
Dae