NYCPHP Meetup

NYPHP.org

[nycphp-talk] $_FILES and form reloading

David Krings ramons at gmx.net
Sun Nov 12 09:38:31 EST 2006


Hi,

    this requires that one has to do tests both on the client and the 
server (can't just not do the server side checks!). I don't really see 
why this extra effort is that much better. The task is to upload an 
image file with some extra info, so the burden on uploading first and 
then checking doesn't strike me as that huge as that one wants to 
prevent submitting the form before all input is checked. And pop-ups are 
often blocked, a small mistake that a user may even notice upon 
reviewing the input before clicking submit throws an error....I don't 
know. I don't say that this isn't a working approach, but users got 
accustomed to getting a consolidated error report with a chance to 
correct the wrong entries after submitting the form the first time.

    I like the highlight idea, but I don't see any reason to make a user 
re-upload the file when there is nothing wrong with the file. Contrary 
to fixing some text in a box, uploading a file again requires to open 
the browse box, select the file again, and click OK or do some other 
action to submit the file selection. That may not be that bad as long as 
there are only a few files in the source location, but if I'd have to 
find PDRM1066.jpg in a folder that has several hundred image files just 
because I forgot to enter a mandatory name I'd get mad really quickly. 
The server got the file already and this is just make work for the user. 
Not that this is a huge issue, but the traffic generated is much higher 
as there is a bigger form page to load with all the JavaScript in it and 
one has to upload the image again for any unrelated input error.

    I found sessions and session IDs to be very helpful. I can create a 
temp folder using the session ID that is by design unique to each 
client. Upon completion of the submission I move the interim file to its 
final location and ditch the session ID temp folder. You need to add 
some housekeeping that cleans up leftovers from aborted submissions. 
That is fairly easy when the user guidance allows for going back to a 
main menu, which is a good spot to clean up any temp files for the 
current session. Same applies on logout. Leaves only the case where the 
user is nasty and simply closes the browser. I haven't found an optimal 
solution for that, but did OK by saving the session ID in a db table 
upon login and check if a temp folder with that name exists when that 
user logs in the next time. That limits the worst case to those 
situations where a user aborts a submission and does not log in again 
for quite some time or never. Those cases can be handled by pulling in 
all temp folders and looking at their creation dates and dump all those 
with any file(s) inside that are older than the maximum expiration time 
set for a cookie/session (I think the default in PHP is three hours). It 
may then still be that the user is currently logged in, but that 
shouldn't matter as any access to that temp folder should first check if 
that folder exists and if not creates it or does something else that is 
applicable.

    Quite a bit of effort for something really stupid, but computers are 
just that. :/

       So, now that I gave this speech I better get to practicing what I 
preach, LOL.

             David K.

Timothy Boyden wrote:
> Michael,
>
> An approach I use which would eliminate this issue would be to use
> JavaScript and do error checking as the user is still filling out the form.
> The way I see it is, why make the user wait until s/he has filled out the
> entire form and submitted it before telling them they made an error? Make
> use of the event handlers and when they "change focus" or click on another
> form field, fire off a JavaScript that checks the previous field for errors
> and pop-up a dialog box that lets them know they made an error on the
> previous field. A site that gives some good recommendations is here:
>
> http://www.xs4all.nl/~sbpoley/webmatters/formval.html
>
> As others have stated, saving the upload file to a temp file on the server
> is also a possibility, but I've also in the past returned the form all
> filled out with the previously submitted data (read only), with the field in
> error highlighted and a message that the user will need to re-upload the
> file(s). YMMV.
>
> Cheers,
>   



More information about the talk mailing list