Web App name tag capabilities and Upload response handling

Question

Hi Guys,
Let me begin by apologising for how long-winded this is going to be. 
I have set my products up in the ecommerce module utilising catalogues etc - I have removed the buy now and cart options, so the ecommerce module is operating essentially like a showroom.  What I want to do now is link the individual large products to a web app because my product range requires personalization and the customers need to give me information and assetts to get their finished product back - the key for me is getting reports from the system, the web apps are just a portal to those reports.  So the workflow would see them submit their text and assetts to be used in the final product and pay via the web app.  With the web app that takes payment and allows them to submit their personalization stuff I was going to make one per product, so if product a) requires them to submit one block of text and 2 photos, the web app would have corresponding fields.  Then I got thinking about using content holders, the one web app for all products that need one block of text and 2 photos, if I could get the name tag to populate with the product page that sends to it, or the page name the web app form is inserted on, because this will correspond to the large product.  This way when I do the reporting instead of having to report from heaps of web apps, I could just filter the reports by the product name.  It would mean I would only need a handful of web apps vs needing quite a lot, but if it is beyond me I am happy that I have a solution, even if it is a bloated one.
The other part of this involves me needing to capture the uploaded file name in the web app form fields so I can report from them.  I have been looking around and came across the below code.  My web app will require 1-12 uploaded file names to be captured in 1-12 form fields i.e. img_1 - img_12 - I am not a coder but I wondered whether this had potential for what I need.  It comes from here http://www.openjs.com/articles/ajax/ajax_file_upload/response_data.php
Thanks in advance for taking the time to digest all of this.
Mandy
A Sample Application
For example, say you are building a photo gallery. When a user uploads an image(using the above mentioned ajax method), you want to get its name and file size from the server side. First, lets create the Javascript uploading script(for explanation on this part, see the Ajax File Upload article)...
The Code
<script type="text/javascript"> function init() { document.getElementById("file_upload_form").onsubmit=function() { document.getElementById("file_upload_form").target = "upload_target"; } } </script>  <form id="file_upload_form" method="post" enctype="multipart/form-data" action="upload.php"> <input name="file" id="file" size="27" type="file" /><br /> <input type="submit" name="action" value="Upload Image" /><br /> <iframe id="upload_target" name="upload_target" src="" style="width:100px;height:100px;border:1px solid #ccc;"></iframe> </form> <div id="image_details"></div>
And the server side(PHP in this case) script will look something like this...
<?php list($name,$result) = upload('file','image_uploads','jpg,jpeg,gif,png'); if($name) { // Upload Successful $details = stat("image_uploads/$name"); $size = $details['size'] / 1024; print json_encode(array( "success"     =>     $result, "failure"     =>     false, "file_name"     =>     $name,     // Name of the file - JS should get this value "size"          =>     $size     // Size of the file - JS should get this as well. )); } else { // Upload failed for some reason. print json_encode(array( "success"     =>     false, "failure"     =>     $result, )); }
Here we are printing the data that should be given to JS directly into the iframe. Javascript can access this data by accessing the iframe's DOM. Lets add that part to the JS code...
function init() { document.getElementById("file_upload_form").onsubmit=function() { document.getElementById("file_upload_form").target = "upload_target"; document.getElementById("upload_target").onload = uploadDone; //This function should be called when the iframe has compleated loading // That will happen when the file is completely uploaded and the server has returned the data we need. } }  function uploadDone() { //Function will be called when iframe is loaded var ret = frames['upload_target'].document.getElementsByTagName("body")[0].innerHTML; var data = eval("("+ret+")"); //Parse JSON // Read the below explanations before passing judgment on me  if(data.success) { //This part happens when the image gets uploaded. document.getElementById("image_details").innerHTML = "<img src='image_uploads/" + data.file_name + "' /><br />Size: " + data.size + " KB"; } else if(data.failure) { //Upload failed - show user the reason. alert("Upload Failed: " + data.failure); } }
Explanation
Lets see whats happening here - a play by play commentary...
document.getElementById("upload_target").onload = uploadDone;
Set an event handler that will be called when the iframe has compleated loading. That will happen when the file is completely uploaded and the server has returned the data we need. Now lets see the function uploadDone().
var ret = frames['upload_target'].document.getElementsByTagName("body")[0].innerHTML; var data = eval("("+ret+")");
These two lines are an eyesore. No - it goes beyond 'eyesore' - this is an abomination. If these lines causes you to gouge out your eyes and run for the hills, I can understand completely. I had to wash my hands after writing those lines. Twice.
var ret = frames['upload_target'].document.getElementsByTagName("body")[0].innerHTML;
This will get the data the server side script put in the iframe. This line cannot be avoided as far as I know. You can write it in different ways - but in the end, you will have to take the innerHTML or the nodeValue or something of the body element of the iframe. I used the smallest code in the sample. Even if you specify the Content type of the iframe page as text/plain, the browser will 'domify' it.
One other thing - in frames['upload_target'] the 'upload_target' is the name of the iframe - not the ID. Its a gotcha you need to be aware of.
var data = eval("("+ret+")");
Thankfully, this line can be avoided - you can use some other format(in this particular case the best format might be plain HTML) so that you don't have to parse a string that comes out of innerHTML. Or you can use CSV. Or plain text. Or JSON as we are doing right now - just parse it without using eval(). Reason I choose it? Smallest code - and easier to understand.
Now we have a working system. The files are uploaded and data reaches the client side. Everything works perfectly. Oh, how I wish I could say that. But nooo - the nightmare of every javascript developer rears its ugly head again...
Internet Explorer
Internet Explorer, also known as IE, also known as the Beast, again manages to mess things up. They don't support the onload event for iframe. So the code...
document.getElementById("upload_target").onload = uploadDone;
will not work. WILL. NOT. WORK. Thanks IE, thanks very much.
So, what do we do? We use a small hack. We put a script tag inside the iframe with a onload event that calls the uploadDone() of the top frame. So now the server side script looks like this...
<html> <head> <script type="text/javascript"> function init() { if(top.uploadDone) top.uploadDone(); //top means parent frame. } window.onload=init; </script> <body> <?php list($name,$result) = upload('file','image_uploads','jpg,jpeg,gif,png'); if($name) { // Upload Successful // Put the PHP content from the last code sample here here } ?> </body> </html>
Okay - now we have a IE-proof working system. Upload an image using the below demo application to see it in action.
If you have a better way of doing this, please, PLEASE let me know. I feel dirty doing it this way.
See it in Action

Answer 1

You also need to consider when someone removes a product and what happens in terms of the things uploaded.
Not saying your way wont work but I have the structure for this basically very similar on sites already that covers all the basis of real world use and works well.
Mine is future proof anyway. BC will never ( I have it in writing) replace the code because it will break implementations and sites directly. jquery version is on the cards but the way that will be implemented or any change will either be with notice and on new sites not old or like many features an option in the admin to change it.