On 9 Nov 2003, at 15:33, Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
On 9 Nov 2003, at 00:06, Sylvain Wallez wrote:
Hi all,
I'm attacking the problem of uploads in Woody. Upayavira started to work on this some time ago but hadn't the time to finish, so I asked him to send me the baby for it to continue growing.
But upload is a difficult problem when the nice form framework you use redisplays pages when a validation occurs. Let's consider a simple form with a "name" field (required) and a "file" upload widget.
What happens if the user selects a file but gives no name? The form is redisplayed, because the name is required, but the upload occurs! Should we discard the upload because the validation failed?
A solution is to keep the uploaded content in a temp area until the form is valid. But what if the user leaves and never re-submits the form? Should we rely on the garbage collector to finalize() the upload widget to clean the temp area?
Any idea or advice appreciated...
I see two potential solutions:
1) client side validation: you don't send if there is no name (the javascript for this is really easy and really portable, btw)
2) disabling: if the upload is done, but there is an error in the form, the 'upload widget' is replaced with the file name (or anything that identifies that the upload has been already done)
In any case, you *have* to visually identify the fact that the upload was already performed. The best usability solution would be to have some DHTML that says "the upload was already done. Click here to resend" and turns into the upload widget if clicked (again, pretty easy and portable stuff to do). Then, if no upload takes place, you pick up the temporary upload and use that. [you can store the temp upload in the continuation anyway]
I think I wasn't clear: my fears were about the fact that potentially large temporary data has to be kept on the server waiting for the user to finish interaction with the form (it can even go away and never finish it). But looking at the problem from any angle, I don't see how we can avoid this.
Oh, yeah, there is no way we can avoid this. It is a potential DoS by disk fill-up... but remember that cocoon has a limit on how big the uploads should be.
Now about the presentation stuff, I was also thinking to something along these lines.
Cool.
Note that if you want to do "in-place uploads" (linotype style), but you have errors in the form, the server side needs to change the URI of the uploaded image to point to the temporary uploaded image... this might require some synch between the form handling and the sitemap.
The ideal (REST-ish) solution would be to send back the image "encoded" inside the XHTML page. I think it's possible with <embed>, but I've never tried it.
Do you mean embed the image inside the HTML as e.g. base-64 data?
<html>
<head>
<script language="JavaScript"><!--
function binary(d) {
var o = '';
for (var i=0; i<d.length; i=i+2) o+=String.fromCharCode(eval('0x'+(d.substring(i,i+2)).toString(16)));
return o;
}
gif = binary('47494638376120001000800000000000FFFFFF2C00000000200010000002208C 8FA9CBED0FA344A0D609019E7A47DB799938924A189A07AA9E570BC7F2BC15003B0A');
//--></script>
</head>
<body>
<img src="javascript:gif"/>
</body>
</html>
works in Netscape (from 4.x to latest firebird), but doesn't work anywhere else.
[taken from http://developer.irt.org/script/955.htm]
I still have to find an equivalent way to do the above in IE, anybody?
-- Stefano.
