Hi all,
This might perhaps be a simple problem but I was wondering if people had any solutions for this.<p>I have a form which allows people to upload images. When a user uploads an image, I save to a database,
1) a modified name for the image,
2) a caption for the image,
3) the id of the user who uploaded the image,
4) Some other information that are used for image retrieval purposes<p>The form allows users to upload up to 30 images. I do not want to write to the database each time
the user wants to upload an image. Rather, I want to store each upload request (plus all the associated information I need like captions etc) and make a large write when a user has confirmed that he/she is satisfied with all of their choices.<p>How can I do this easily?
1) I have considered storing the attributes and information associated with each image in cookies and retrieving and processing cookie information after the user has confirmed his/her choices. However, I am not comfortable with this option as I cannot control what happens to the cookies when they are stored in the client machine.<p>2) Another option is to obtain many hidden fields (more than 30) in the HTML form and fill these up with the associated information I need. I could then process the information in these hidden fields before writing to the database. However, this seems pretty clumsy.<p>3) A third option I was considering was using Amazon's Simple Queue Service to queue image upload requests and then unqueue and process the messages after a user finished making his/her choices and hit a confirm button.<p>Which solution among these 3 is the cleanest and most flexible implementation? Are there other solutions for this problem?<p>Thanks all.
This is what sessions are for, maintaining volatile state that may or may not be written to a more permanent storage.<p>If your application stack does not have a session implementation that 'Just Works!'(tm) for you, you will have to implement one yourself.<p>Generally it will look something like a cross between your solutions 1 and 3, you create an opaque session key which is stored as a cookie and is used to retrieve the data from the session store. What you use to store session data is going to vary depending on how valuable the data and on how tragic failure is.<p>Avoid hidden fields in the html, they are a pain to maintain and will cause you problems because the temptation is to trust that their contents are what you put into them... it also means that you are repeatedly processing the same data. In sum; hidden form values make baby jesus cry.
this is what i did:<p>I have a form that:
user can upload as many as s/he wants
user clicks submit
the browser then sends a stream of data one time<p>on the server:
regex find .<i>multipart/form-data;.</i>boundary=.* from CONTENT_TYPE to make sure it's the right stream
save the stream into temp-file, read the temp-file<p>split file-stream based on .<i>filename=\"(.</i>)\".* into chunks
afterward, "calibrate" the chunk (determine start & end write positions)
then loop and write the chunks into specific filenames provided in the stream<p>so there are 1 upload stream and 1 load n+1 write operations<p>I wonder if it helps since I don't use php (hint: newlisp)