Re: Handle file uploads in Behavior and respond using AjaxRequestTarget

View: New views
2 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: Handle file uploads in Behavior and respond using AjaxRequestTarget

by jthomerson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Seeing this thread and similar requests come up before, I have
wondered how difficult it would be to natively support this in Wicket
- via some AjaxForm, etc.  Change the ajax submitting behaviors to
submit to an invisible iframe if it finds any file input fields, and
change the processing so that when it returns the JS in the iframe, it
is handled in the real frame.

Has this been discussed before?  Is it in JIRA?  Is it something we
should add to the 1.5 wishlist?

Come on, Igor - shoot me down - I haven't throught this through much -
so I know I'm missing something obvious - and it's probably on the tip
of your tongue - right behind "wtf - why didn't you think of (insert
something that I forgot to consider)"  :)

Happy Wednesday.

--
Jeremy Thomerson
http://www.wickettraining.com




On Wed, Aug 5, 2009 at 5:51 PM, Igor Vaynberg<igor.vaynberg@...> wrote:

> well, its complex because you have to hack this in, browser's built in
> ajax support doesnt handle multipart requests yet.
>
> sounds like you are overcomplicating it by prerendering the iframe in
> the output. i think it would be easier to create the iframe on the fly
> via javascript, and give it style='display:none' so you wouldnt need
> to do any sizing.
>
> if upload fails the response in the iframe can write out some
> javascript to notify the main script that is managing the upload -
> which can then somehow show an error - maybe by doing an ajax request
> to wicket and rerendering the feedbackpanel.
>
> if upload is successful do the same thing, have iframe write out a bit
> of js that notifies the main script that the upload is done - which
> can then issue an ajax callback to wicket.
>
> makes sense? btw, there have to be libs that do all this for you on
> the js side of things.
>
> -igor
>
>
> On Wed, Aug 5, 2009 at 3:42 PM, Bas Gooren<bas@...> wrote:
>> Hi all,
>>
>> Since I've seen many great answers on this list it's time to ask one of my questions ;-)
>>
>> The thing that strikes me as odd is how hard it is right now to handle file uploads and respond as if it were an AJAX request.
>> I've built (based on various sources) a solution which uses a Panel which contains an IFRAME. After the upload, some AJAX javascript is rendered which calls an abstract function on the Panel so the implementor can replace or re-render components. This works great, although it took some extra effort since the frame and panel cannot easily share state (different pages/pagemaps/...?). The examples on the web store the uploaded file, and then pass it's filename through the AJAX request for access. I changed it to store uploads in temporary storage, identified by UUIDs.
>>
>> Now I have to say I really don't like this solution, since the IFRAME has to be sized to fit, or I have to use some not-so-nice javascript to automatically resize the IFRAME when an upload error occurs.
>>
>> Since I have had great fun with swfupload + PHP before, I decided to try and make an easier solution. I wondered if it would be possible to:
>>
>> 1) extend AbstractBehavior (works)
>> 2) render the swf which will upload the file (works)
>> 3) give the swf the URL of the behavior (works)
>> 4) handle the upload(s) in onRequest() (does not work)
>> 5) and then, just like AbstractDefaultAjaxBehavior.onRequest(), build an AjaxRequestTarget and handle the request (like it came in over xmlhttp) (works)
>> 6) use javascript (Wicket.Ajax.Call.loadedCallback) to parse the (fake) AJAX response
>>
>> Sounds possible, right? It just seems overkill to run a POST request _and_ an AJAX request for every upload. It seems more complex than it should be. Actually, with the IFRAME it's three requests: IFRAME GET, IFRAME POST, AJAX GET
>>
>> What is not working right now is:
>> - POST request not directed to the Behavior (I'm assuming there is special-case handling for POST somewhere?)
>>
>> Anyway, I'd like to known if any of the devs think the above is possible. If not, I'll stick to the solution I'm building right now (swfupload to a mounted URIRequestTargetUrlCodingStrategy + UUID in the URL, AJAX request with this UUID after successful upload).
>>
>> Ofcourse it's also possible something like this is possible but needs a completely different angle.
>>
>> Kind regards,
>>
>> Bas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

Re: Handle file uploads in Behavior and respond using AjaxRequestTarget

by igor.vaynberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, Aug 5, 2009 at 3:58 PM, Jeremy
Thomerson<jeremy@...> wrote:

> Seeing this thread and similar requests come up before, I have
> wondered how difficult it would be to natively support this in Wicket
> - via some AjaxForm, etc.  Change the ajax submitting behaviors to
> submit to an invisible iframe if it finds any file input fields, and
> change the processing so that when it returns the JS in the iframe, it
> is handled in the real frame.
>
> Has this been discussed before?  Is it in JIRA?  Is it something we
> should add to the 1.5 wishlist?
>
> Come on, Igor - shoot me down - I haven't throught this through much -
> so I know I'm missing something obvious - and it's probably on the tip
> of your tongue - right behind "wtf - why didn't you think of (insert
> something that I forgot to consider)"  :)

you have managed to overcomplicate it; you dont need an ajax form, nor
any changes to the ajax behaviors.

this is more a problem of logistics, historically these things have
been a huge timesink. modal window, something that should be
relatively simple, has sucked in enough time to write wicket twice
over. so did autocompletetextfield. i think we are all a bit hesitant
about introducing more magical javascript.

fine. maybe the time has come to bite the bullet on this one. see
WICKET-2420. currently it works in firefox, save a minor problem with
the browser spinner which never seems to stop. it fails in all the
other browsers in slightly different ways. even at 30 lines javascript
can cause a headache. let the fun begin, i hope you like tweaking
javascript :)

-igor

>
> Happy Wednesday.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
>
> On Wed, Aug 5, 2009 at 5:51 PM, Igor Vaynberg<igor.vaynberg@...> wrote:
>> well, its complex because you have to hack this in, browser's built in
>> ajax support doesnt handle multipart requests yet.
>>
>> sounds like you are overcomplicating it by prerendering the iframe in
>> the output. i think it would be easier to create the iframe on the fly
>> via javascript, and give it style='display:none' so you wouldnt need
>> to do any sizing.
>>
>> if upload fails the response in the iframe can write out some
>> javascript to notify the main script that is managing the upload -
>> which can then somehow show an error - maybe by doing an ajax request
>> to wicket and rerendering the feedbackpanel.
>>
>> if upload is successful do the same thing, have iframe write out a bit
>> of js that notifies the main script that the upload is done - which
>> can then issue an ajax callback to wicket.
>>
>> makes sense? btw, there have to be libs that do all this for you on
>> the js side of things.
>>
>> -igor
>>
>>
>> On Wed, Aug 5, 2009 at 3:42 PM, Bas Gooren<bas@...> wrote:
>>> Hi all,
>>>
>>> Since I've seen many great answers on this list it's time to ask one of my questions ;-)
>>>
>>> The thing that strikes me as odd is how hard it is right now to handle file uploads and respond as if it were an AJAX request.
>>> I've built (based on various sources) a solution which uses a Panel which contains an IFRAME. After the upload, some AJAX javascript is rendered which calls an abstract function on the Panel so the implementor can replace or re-render components. This works great, although it took some extra effort since the frame and panel cannot easily share state (different pages/pagemaps/...?). The examples on the web store the uploaded file, and then pass it's filename through the AJAX request for access. I changed it to store uploads in temporary storage, identified by UUIDs.
>>>
>>> Now I have to say I really don't like this solution, since the IFRAME has to be sized to fit, or I have to use some not-so-nice javascript to automatically resize the IFRAME when an upload error occurs.
>>>
>>> Since I have had great fun with swfupload + PHP before, I decided to try and make an easier solution. I wondered if it would be possible to:
>>>
>>> 1) extend AbstractBehavior (works)
>>> 2) render the swf which will upload the file (works)
>>> 3) give the swf the URL of the behavior (works)
>>> 4) handle the upload(s) in onRequest() (does not work)
>>> 5) and then, just like AbstractDefaultAjaxBehavior.onRequest(), build an AjaxRequestTarget and handle the request (like it came in over xmlhttp) (works)
>>> 6) use javascript (Wicket.Ajax.Call.loadedCallback) to parse the (fake) AJAX response
>>>
>>> Sounds possible, right? It just seems overkill to run a POST request _and_ an AJAX request for every upload. It seems more complex than it should be. Actually, with the IFRAME it's three requests: IFRAME GET, IFRAME POST, AJAX GET
>>>
>>> What is not working right now is:
>>> - POST request not directed to the Behavior (I'm assuming there is special-case handling for POST somewhere?)
>>>
>>> Anyway, I'd like to known if any of the devs think the above is possible. If not, I'll stick to the solution I'm building right now (swfupload to a mounted URIRequestTargetUrlCodingStrategy + UUID in the URL, AJAX request with this UUID after successful upload).
>>>
>>> Ofcourse it's also possible something like this is possible but needs a completely different angle.
>>>
>>> Kind regards,
>>>
>>> Bas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>