You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2003/11/09 00:06:23 UTC
Upload widget for Woody: how to handle form redisplay?
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...
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
Re: Upload widget for Woody: how to handle form redisplay?
Posted by Sylvain Wallez <sy...@apache.org>.
Marc Portier wrote:
>
>
> Sylvain Wallez wrote:
>
>> Ugo Cei wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>> 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?
>>>
>>>
>>> How about catching the expiration of the continuation and removing
>>> the temp file from there?
>>
>>
>> Good idea.
>>
>> For this, we'll need some kind of "ContinuationExpirationListener". But
>
>
> Maybe you can use the ContinuationsDisposer for this?
>
> I added this during the making of 'Apples' to dispose resources
> (looked up components) your Apple might be holding
Yep, I remember that ;-)
>> they'll have to be registered in the continuation that _will_ be
>> created at the next sendPageAndWait, as the latest continuation
>> represents a past state, and may not exist if we just started the
>> flowscript.
>
>
> Hm, of course for apples it was slightly different, since there the
> use-case controller is one object-instance (and not multiple ones)
>
> but maybe we can find a way to register this kind of clean-up stuff on
> the level of the complete use-case... or in flowscript lingo on the
> level of the continuations-tree (so it only gets executed if the last
> node in the tree is expired, and not upon clearing each node)
I don't think this is enough: as explained above, the objects to be
disposed should be attached to the continuation that _will_ be created
(they belong to this future state) and not to the latest one (which may
not exist if we just started the flow function). And they must be
disposed immediately in case of a sendPage() (no continuation created).
In its current first incarnation (will be committed after 2.1.3 is out),
the upload widget relies on finalize() to cleanup temp files.
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
Re: Upload widget for Woody: how to handle form redisplay?
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Ugo Cei wrote:
>
>> Sylvain Wallez wrote:
>>
>>> 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?
>>
>>
>>
>> How about catching the expiration of the continuation and removing the
>> temp file from there?
>
>
>
> Good idea.
>
> For this, we'll need some kind of "ContinuationExpirationListener". But
Maybe you can use the ContinuationsDisposer for this?
I added this during the making of 'Apples' to dispose resources (looked
up components) your Apple might be holding
> they'll have to be registered in the continuation that _will_ be created
> at the next sendPageAndWait, as the latest continuation represents a
> past state, and may not exist if we just started the flowscript.
>
Hm, of course for apples it was slightly different, since there the
use-case controller is one object-instance (and not multiple ones)
but maybe we can find a way to register this kind of clean-up stuff on
the level of the complete use-case... or in flowscript lingo on the
level of the continuations-tree (so it only gets executed if the last
node in the tree is expired, and not upon clearing each node)
> I think we must also use the cleanup on finalize() for cases where forms
> are used outside of flowscript (i.e. with actions).
>
> Sylvain
>
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: Upload widget for Woody: how to handle form redisplay?
Posted by Sylvain Wallez <sy...@apache.org>.
Ugo Cei wrote:
> Sylvain Wallez wrote:
>
>> 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?
>
>
> How about catching the expiration of the continuation and removing the
> temp file from there?
Good idea.
For this, we'll need some kind of "ContinuationExpirationListener". But
they'll have to be registered in the continuation that _will_ be created
at the next sendPageAndWait, as the latest continuation represents a
past state, and may not exist if we just started the flowscript.
I think we must also use the cleanup on finalize() for cases where forms
are used outside of flowscript (i.e. with actions).
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
Re: Upload widget for Woody: how to handle form redisplay?
Posted by Ugo Cei <u....@cbim.it>.
Sylvain Wallez wrote:
> 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?
How about catching the expiration of the continuation and removing the
temp file from there?
Ugo
Re: Upload widget for Woody: how to handle form redisplay?
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
<snip/>
>> 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>
Wooooow! Awesome weird trick ;-)
> 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?
Tried in IE6 but doesn't work...
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
Re: Upload widget for Woody: how to handle form redisplay?
Posted by Stefano Mazzocchi <st...@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.
Re: Upload widget for Woody: how to handle form redisplay?
Posted by Sylvain Wallez <sy...@apache.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
Re: Upload widget for Woody: how to handle form redisplay?
Posted by Stefano Mazzocchi <st...@apache.org>.
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]
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.
HTH
--
Stefano.