Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
From: Sylvain Wallez <sylvain@apache.org>
Subject: Re: Upload widget for Woody: how to handle form redisplay?
Date: Sun, 09 Nov 2003 15:33:03 +0100
Lines: 74
Message-ID: <bolj70$cbr$1@sea.gmane.org>
References: <3FAD76EF.5010207@apache.org>
 <2309C901-12B7-11D8-B5F6-000393D2CB02@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031007
In-Reply-To: <2309C901-12B7-11D8-B5F6-000393D2CB02@apache.org>
Sender: news <news@sea.gmane.org>

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.

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?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com