> Most of the time when people upload a file, it is meant to be retained. > Otherwise why bother with an upload instead of a text field in a form, if you > know it is going to be plain text?
Nothing esotheric, just offering advanced customers the option to upload a csv file with order-data to be parsed and added to the shopping cart. > > Feel free to make a feature request on the issue tracker, but don't wait for > it to be implemented. Sure. > In the meantime you will have to suffer the unbearable torture of writing 3 > extra lines of code: > copy upload($ref; $path) > document to blob($path; $blob) > blob to text($blob; UTF8 Text without length; 0; get upload size($ref)) > delete document($path) It is not, that I can't add 3 extra lines of code but it seems to be not very efficient, that I have to duplicate a file on disc to access it's content. It is a "read file - save file - read file -delete file" process instead of one "read file". And it is not as simple as you write, as I have to deal with potential duplicate filenames for the copy command. > Of course you will have to hope the user hasn't done anything stupid or > malicious by uploading binary content disguised as text or by uploading a huge > file which will eat all of the server's memory and cause it to freeze/crash > when you load 2 copies of it into memory (1 for the blob, 1 for the converted > text). Right, but that has nothing to do with how I access your uploaded temp file. To make it clear: I do not ask for a way to store the uploaded file directly into a blob. Your mechanism of saving the upload to a temp file with autonaming and autodeletion is perfect. What I ask is a way to copy the content of this temp file into a blob instead of copying it into a file on disk. Peter _______________________________________________ Active4D-dev mailing list [email protected] http://list.aparajitaworld.com/listinfo/active4d-dev Archives: http://active4d-nabble.aparajitaworld.com/
