cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Upload widget for Woody: how to handle form redisplay?
Date Mon, 10 Nov 2003 11:11:07 GMT

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.


>> 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?

<script language="JavaScript"><!--
function binary(d) {
     var o = '';
     for (var i=0; i<d.length; i=i+2)  
     return o;

gif =  
<img src="javascript:gif"/>

works in Netscape (from 4.x to latest firebird), but doesn't work  
anywhere else.

[taken from]

I still have to find an equivalent way to do the above in IE, anybody?


View raw message