mittra;11042725 wrote:
If I understand this code correctly, in upload.php the variable $result is being used to relay back to index.php that upload.php ran successfully and in index.php in the stopUpload function the variable success is a boolean that directly relates to $result in upload.php. Is that correct?
Possibly correct, if you use terms in a very lose sense. The important thing is that you understand how it works. If you wish to communicate with others, also using terms in a stricter sense will help a lot to avoid confusion. In short
- upload.php does not tell index.php anything at all. upload.php never calls index.php
- The success parameter of stopUpload directly relates to the value of $result in upload.php
- success is not a boolean in this case - it is an integer
- You cannot rely on success being of any particular type as far as the function body of stopUpload goes, unless stopUpload cast it as such. The type of success is determined at call time, by the calling code which in this case is output from upload.php.
# int
echo window.top.stopUpload(1);
# bool
echo window.top.stopUpload(true);
# string
echo window.top.stopUpload('1');
The form's target attribute is set to "upload_target" which is an iframe. That iframe works pretty much like any ordinary html page, except that it is also part of another enclosing html page. Thus, the posted form is processed by upload.php. The browser will then take any output from upload.php and use it as content for the iframe. In this case, the output is this script element
<script>window.top.window.stopUpload(<?php echo $result; ?>);</script>
You should remove the type attribute. If it is present it must be a valid content type. "text/javascript" is obsolete, but the type attribute will take this value if not specified. Setting the type to text/javascript is incorrect, while leaving it out will default to this value. Leaving it out is at least no less interoperable.
You should also remove the language attribute since its possible values have never been standardized. Use type (unless you need a text/javascript type).
What happens is that the script will run inside the iframe. iframes have their own window object. The top property of a window will refer to the window object of a browser window or browser tab (the top-most browsing context). Therefor, in the topmost browsing context it is always true that
window === window.top;
And while it is also true and not incorrect to use redundant .window
window.window === window.top.window;
window === window.top.window;
it is nonetheless redundant.
In your topmost browsing context, you have defined the function stopUpload and the iframe may then call it by
window.top.stopUpload();
just like the topmost browsing context would call it by
window.stopUpload();
// or better yet, simply
stopUpload();
If you have a button of the non-submit variety in your topmost document, and pushing it calls the javascript function stopUpload, you'd probably (hopefully) not state that clicking the button would tell index.php anything. You'd probably state that clicking the button would call stopUpload. The same thing happens as a result of the output from upload.php: stopUpload is called. Nothing is sent to index.php.
mittra;11042725 wrote:
if they aren't using Chrome the interface appears to hang-up while the file is uploading to the temporary location
iframe uploads and frame uploads are a thing of the past. You are generally better off handling http requests that do not reload the page with ajax. Ajax requests are asynchronous by default, and you should get consistent behaviour across browsers.
mittra;11042725 wrote:
I wanted to have the interface put up something to let the users know that their file is being uploaded and that the page isn't hung up or locked up.
If you are satisified with giving Everyone but IE9- a progress bar, you can use the progress event for level 2 XHR.
mittra;11042725 wrote:
I did a little search and found some scripts that appeared to do just what I was seeking, but I'm having issues incorporating them into my existing code.
It's kind of hard to help inside a black box.
mittra;11042725 wrote:
This code uploads the file as expected and displays the "Loading..." gif while the temporary file is being uploaded as I wanted. It uses move_uploaded_file instead of ftp_put, but that's not a big deal because i know how to re-write the php to use ftp_put instead.
Except that this could lead to another problem. If the progress bar measures progress for the user's upload to your web server and you switch from moving the large file on the same disk (constant time in regards to file size) to an ftp upload (will take time, potentially lots of time) the progress bar may stay at 100% for a long time, which makes the system appear to be frozen.
One way around this is to continue using move_uploaded_file, then close the http connection before sending the file over ftp. The downside to this is that the user's file will not be immediately available in the new location after the (user's) upload completes.
The other way around it is to "guess" (possibly by using average speed for the last 10 uploads) at what speed you can deliver the file from web server to ftp server and incorporate this time into the file upload total time and modifying the progress calculation to incoroprate this.
mittra;11042725 wrote:
The problem I have with this code is I don't know how to display feedback. For example, if the e-mail field is blank or doesn't contain a valid e-mail, I don't know how to modify this code to stop processing the upload and tell the user to enter a valid e-mail address.
This is a two-part problem - one part is handling this gracefully in the brower. The second part is to have your server simply abort on invalid in-data, or in case you wish to play nice with anyone else talking to your api, abort on invalid in-data and provide a meaningful error message.
The first part is preventing the upload from being allowed unless the user provides the necessary information. Adding the required attribute to all form inputs that are required will make such information required. Adding an onsubmit event to the form (or similar for ajax uploads) and implement javascript validation of whatever data you want to validate and abort unless it is valid takes care of the rest. This way, a regular user will never have to send their very large file to your web server before being told that their email adress is required or invalid.
The second part is doing the same thing on the web server. First off, any user can circumvent your client-side validation by creating their own http request even if you don't mean for anyone to do so. Secondly, it is possible that you actually want to allow user's to use your server side api outside of your web page.
mittra;11042725 wrote:
how would I pass back other values to index.php so I could specify other conditions besides just success or failure uploading the file?
Reformulate the question as: how would I pass back other values to stopUpload so I could specify other conditions besides just success or failure uploading the file?
The answer is then obviously to pass more than only 0 or 1 to stopUpload. One way would be to also send 2, 3 and 4 to stopUpload. But it's probably better to let success take only 0/1 / true/false, and add second parameter which takes an error message, such as "file size too large", "invalid email address" etc. And such a function could still be called both directly from javascript code BEFORE sending the request to the server, as well as after (in case your form was bypassed or some server side error occurred).
mittra;11042725 wrote:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Stop coding for yesterdays web and start following ]the current specification
The html 5 standards wrote:
The DOCTYPE legacy string should not be used unless the document is generated from a system that cannot output the shorter string.
Moreover, XHTML 1.0 Transitional does not even seem to be a permitted obsolete doctype.