I hit a glitch on the final polishing of the beta. Hopefully, the install issues will be worked out, or you'll have to issue a few SQL commands to set the table up properly.
But, a bigger issue is in working on the "multiple upload" feature, I hit a problem with saving state, which will take a little while to smooth out.
For ease of use, I figure that you should be able to upload 1, or many (up to a webmaster set hard/soft limit) files to a link in total, and at one time.
But, in order to do the upload properly, and efficiently, it makes sense to upload all the files at one time, then add the information for each successful upload.
For instance, a website allows you to attach 10 files to each link, and you want to upload 6 at this point. You are presented with a form with 10 spaces on it, but you only fill in 6. You click submit, and the browser uploads 6 files from your local machine. The script takes this input, parses it, and creates 6 files on disk in the preview area. It now wants to present each of these files to you, one at a time, so you can add in the information like titles, descriptions....
Ok, I think I just figured out a way.
How about: After a successful upload, the user is presented with the second "edit" screen, which shows the link, and the attachments that he can edit:
1) [unvalidated] file_name1, GIF, 320, 180, 82k, etc [please edit]
2) [unvalidated] file_name2, GIF, 400, 200, 90k, etc [please edit]
3) [unvalidated] file_name3, PDF, 8, 50k, etc [please edit]
..6)..
(can't do good graphics here in the forum, but you get the idea).
It's then up to the user to finish entering the information such as title, etc, for each upload, by clicking the [edit] link. If there is a thumbnail, it will be shown next to the link, and on the edit page, or a default image for each other file type. Would this work?
If a user only wants to upload one image, they are presented with the edit page, where all the information can be entered at one time.
The back-end processes are pretty much the same, just a few flags to figure out what data was sent, but the user interface is the real problem! On a BBS, where you could control the connection you can present each file back to the user one at a time. On the web, that would require advanced cookie and session information, that is far beyond the real needs of this program :) It's much safer, simpler, and more secure to do one "transaction" at a time, finish it, then do the next, without making any assumptions as to who is still on the other end of the connection.
So, does the solution above make sense??? I can still probably get the program out tomorrow (today?)
Is multiple file uploading at one time something people would want??? Or is one-file-at-a-time sufficient? I know I can make a case for either, but if I pick one, everyone will want the other, so I'm trying to cover both sorts of uploads.
Let me know.
NOTE: By using a "preview" area, an aborted session can be resumed (the program simply checks the preview area for files for that user) and the user can be presented with a "Please Finish" screen. Because the preview area can be outside the HTML/DOC tree, the users can't use this area to upload illegal files, for private distribution. Also, part of the "validation" process is moving the files from the preview area to the /image/root/ for the system. I've tried to cover all eventualities, and while the betas are going to have bugs and unfinished parts, the final program should have all these features working.
NOTE 2: The betas are only going to use the preview area for uploads. The files will be moved to the /image/root/nnn/nnn/etc area once uploaded, pending validation, they just will not be shown on the "link" or "detail" page until validated. The more complicated use of the preview area is a back-end process, that doesn't really affect the look/feel/function of the program, and can be added when ready, without affecting anything already running. The reason this will be changed as in the "NOTE", is for security. A beta -- by definition -- should not be publically deployed in a mission critical or "risky" situation <--- note the disclaimer!!! :)
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
But, a bigger issue is in working on the "multiple upload" feature, I hit a problem with saving state, which will take a little while to smooth out.
For ease of use, I figure that you should be able to upload 1, or many (up to a webmaster set hard/soft limit) files to a link in total, and at one time.
But, in order to do the upload properly, and efficiently, it makes sense to upload all the files at one time, then add the information for each successful upload.
For instance, a website allows you to attach 10 files to each link, and you want to upload 6 at this point. You are presented with a form with 10 spaces on it, but you only fill in 6. You click submit, and the browser uploads 6 files from your local machine. The script takes this input, parses it, and creates 6 files on disk in the preview area. It now wants to present each of these files to you, one at a time, so you can add in the information like titles, descriptions....
Ok, I think I just figured out a way.
How about: After a successful upload, the user is presented with the second "edit" screen, which shows the link, and the attachments that he can edit:
1) [unvalidated] file_name1, GIF, 320, 180, 82k, etc [please edit]
2) [unvalidated] file_name2, GIF, 400, 200, 90k, etc [please edit]
3) [unvalidated] file_name3, PDF, 8, 50k, etc [please edit]
..6)..
(can't do good graphics here in the forum, but you get the idea).
It's then up to the user to finish entering the information such as title, etc, for each upload, by clicking the [edit] link. If there is a thumbnail, it will be shown next to the link, and on the edit page, or a default image for each other file type. Would this work?
If a user only wants to upload one image, they are presented with the edit page, where all the information can be entered at one time.
The back-end processes are pretty much the same, just a few flags to figure out what data was sent, but the user interface is the real problem! On a BBS, where you could control the connection you can present each file back to the user one at a time. On the web, that would require advanced cookie and session information, that is far beyond the real needs of this program :) It's much safer, simpler, and more secure to do one "transaction" at a time, finish it, then do the next, without making any assumptions as to who is still on the other end of the connection.
So, does the solution above make sense??? I can still probably get the program out tomorrow (today?)
Is multiple file uploading at one time something people would want??? Or is one-file-at-a-time sufficient? I know I can make a case for either, but if I pick one, everyone will want the other, so I'm trying to cover both sorts of uploads.
Let me know.
NOTE: By using a "preview" area, an aborted session can be resumed (the program simply checks the preview area for files for that user) and the user can be presented with a "Please Finish" screen. Because the preview area can be outside the HTML/DOC tree, the users can't use this area to upload illegal files, for private distribution. Also, part of the "validation" process is moving the files from the preview area to the /image/root/ for the system. I've tried to cover all eventualities, and while the betas are going to have bugs and unfinished parts, the final program should have all these features working.
NOTE 2: The betas are only going to use the preview area for uploads. The files will be moved to the /image/root/nnn/nnn/etc area once uploaded, pending validation, they just will not be shown on the "link" or "detail" page until validated. The more complicated use of the preview area is a back-end process, that doesn't really affect the look/feel/function of the program, and can be added when ready, without affecting anything already running. The reason this will be changed as in the "NOTE", is for security. A beta -- by definition -- should not be publically deployed in a mission critical or "risky" situation <--- note the disclaimer!!! :)
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
Multiple Upload/attach Show of hands (important!)