Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Mime-Version: 1.0 (Apple Message framework v606)
In-Reply-To: <bolj70$cbr$1@sea.gmane.org>
References: <3FAD76EF.5010207@apache.org>
 <2309C901-12B7-11D8-B5F6-000393D2CB02@apache.org>
 <bolj70$cbr$1@sea.gmane.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9530740E-136E-11D8-B41A-000393D2CB02@apache.org>
Content-Transfer-Encoding: 7bit
From: Stefano Mazzocchi <stefano@apache.org>
Subject: Re: Upload widget for Woody: how to handle form redisplay?
Date: Mon, 10 Nov 2003 12:11:07 +0100
To: dev@cocoon.apache.org


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.