You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Igor Vaynberg <ig...@gmail.com> on 2009/08/06 00:51:44 UTC
Re: Handle file uploads in Behavior and respond using
AjaxRequestTarget
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<ba...@iswd.nl> 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@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handle file uploads in Behavior and respond using
AjaxRequestTarget
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Aug 5, 2009 at 4:10 PM, Bas Gooren<ba...@iswd.nl> wrote:
> Igor,
>
> First off: thanks for the amazingly fast response!
>
> Yes, it feels like I'm overcomplicating things. But then again: there does
> not seem to be an easy way.
> An upload + AJAX refresh always needs 2 requests, which means (for me) that
> I need to preserve the upload somewhere between those requests.
>
> Since this stuff is very easy on other platforms it's just too bad it's like
> this with Wicket.
this is the price you pay for abstraction. It is easy on other
platforms because this is something that is accomplished by working
with low-level http artifacts - http requests. something like php or
jsp or servlets have no abstraction, there it is much easier to do
this then to write a complex UI. in wicket, because of the
abstraction, this is reversed - easy to write UI, more difficult to
wire http requests together like this. its a good thing that 99% of
the time is spent writing UIs :)
> I mean, I really love Wicket, and most of my new projects
> are built on Wicket.
> But things like this one (http://www.uploadify.com/) I'm trying to wrap in a
> component/behavior right now is difficult to say the least.
didnt really look into it that much, when i went to the demo tab it
crashed my firefox :|
> One of the working components I built using IFRAMEs is actually not that
> complex (400 LOC),
> and the problem is not so much in the rendering.
> It could also be the complexity is in the wrong place... Right now this is
> the flow:
> - handle upload, store temp file, pass uuid to client
> - client runs ajax request with the uuid
> - ajax handler in wicket processes the temp file, and re-renders components
>
> I could choose to process the files @ upload time, and the ajax request only
> re-renders elements. Though that does mean components which embed the upload
> component need to implement two methods (processUpload, processAjax) instead
> of one (processAjax(upload,ajax)).
>
> How would you go about building a component or behavior for Uploadify?
> Let's forget about the IFRAME solution for a second: flash-based uploading
> replaces the IFRAME.
>
> Regards,
>
> Bas
>
> ----- Original Message ----- From: "Igor Vaynberg" <ig...@gmail.com>
> To: <us...@wicket.apache.org>
> Sent: Thursday, August 06, 2009 12:51 AM
> Subject: Re: Handle file uploads in Behavior and respond using
> AjaxRequestTarget
>
>
> 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<ba...@iswd.nl> 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@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
Posted by Bas Gooren <ba...@iswd.nl>.
Great! Will take a look at it soon.
This is what I love about Wicket most: very active development (constant
flow of improvement).
Thanks Igor.
Bas
----- Original Message -----
From: "Igor Vaynberg" <ig...@gmail.com>
To: <us...@wicket.apache.org>
Sent: Friday, August 07, 2009 7:28 PM
Subject: Re: Handle file uploads in Behavior and respond using
AjaxRequestTarget
> tada, all done in trunk
>
> -igor
>
> On Wed, Aug 5, 2009 at 8:23 PM, Igor Vaynberg<ig...@gmail.com>
> wrote:
>> yes, the form action is rewritten to the behavior url. the behavior
>> url processes the form the same way it does when an ajax request is
>> used, but because we do not use an ajax request the form contains its
>> multipart data.
>>
>> i tested it on a small example and it works like a charm save
>> javascript problems.
>>
>> -igor
>>
>> On Wed, Aug 5, 2009 at 8:16 PM, Bas Gooren<ba...@iswd.nl> wrote:
>>> Interesting, it looks like you simply POST the form to the AJAX url
>>> using an
>>> IFRAME.
>>>
>>> How does it work server-side? I would expect that it does not work,
>>> since
>>> the form action no longer contains it's usual value, and the new form
>>> action
>>> points directly to an interface (IBehaviorListener).
>>> But I guess that since you're using Wicket.Ajax.Call.submitForm,
>>> server-side
>>> knows a form is being submitted.
>>>
>>> I got uploadify working in a componentized form. Works like a charm for
>>> now.
>>>
>>> Bas
>>>
>>> ----- Original Message ----- From: "Igor Vaynberg"
>>> <ig...@gmail.com>
>>> To: <us...@wicket.apache.org>
>>> Sent: Thursday, August 06, 2009 4:32 AM
>>> Subject: Re: Handle file uploads in Behavior and respond using
>>> AjaxRequestTarget
>>>
>>>
>>>> On Wed, Aug 5, 2009 at 4:10 PM, Bas Gooren<ba...@iswd.nl> wrote:
>>>>
>>>>> One of the working components I built using IFRAMEs is actually not
>>>>> that
>>>>> complex (400 LOC),
>>>>
>>>> i just wrote something that is about 30 lines of javascript that does
>>>> this. only works in firefox so far. see WICKET-2420.
>>>>
>>>> -igor
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handle file uploads in Behavior and respond using
AjaxRequestTarget
Posted by Igor Vaynberg <ig...@gmail.com>.
tada, all done in trunk
-igor
On Wed, Aug 5, 2009 at 8:23 PM, Igor Vaynberg<ig...@gmail.com> wrote:
> yes, the form action is rewritten to the behavior url. the behavior
> url processes the form the same way it does when an ajax request is
> used, but because we do not use an ajax request the form contains its
> multipart data.
>
> i tested it on a small example and it works like a charm save
> javascript problems.
>
> -igor
>
> On Wed, Aug 5, 2009 at 8:16 PM, Bas Gooren<ba...@iswd.nl> wrote:
>> Interesting, it looks like you simply POST the form to the AJAX url using an
>> IFRAME.
>>
>> How does it work server-side? I would expect that it does not work, since
>> the form action no longer contains it's usual value, and the new form action
>> points directly to an interface (IBehaviorListener).
>> But I guess that since you're using Wicket.Ajax.Call.submitForm, server-side
>> knows a form is being submitted.
>>
>> I got uploadify working in a componentized form. Works like a charm for now.
>>
>> Bas
>>
>> ----- Original Message ----- From: "Igor Vaynberg" <ig...@gmail.com>
>> To: <us...@wicket.apache.org>
>> Sent: Thursday, August 06, 2009 4:32 AM
>> Subject: Re: Handle file uploads in Behavior and respond using
>> AjaxRequestTarget
>>
>>
>>> On Wed, Aug 5, 2009 at 4:10 PM, Bas Gooren<ba...@iswd.nl> wrote:
>>>
>>>> One of the working components I built using IFRAMEs is actually not that
>>>> complex (400 LOC),
>>>
>>> i just wrote something that is about 30 lines of javascript that does
>>> this. only works in firefox so far. see WICKET-2420.
>>>
>>> -igor
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handle file uploads in Behavior and respond using
AjaxRequestTarget
Posted by Igor Vaynberg <ig...@gmail.com>.
yes, the form action is rewritten to the behavior url. the behavior
url processes the form the same way it does when an ajax request is
used, but because we do not use an ajax request the form contains its
multipart data.
i tested it on a small example and it works like a charm save
javascript problems.
-igor
On Wed, Aug 5, 2009 at 8:16 PM, Bas Gooren<ba...@iswd.nl> wrote:
> Interesting, it looks like you simply POST the form to the AJAX url using an
> IFRAME.
>
> How does it work server-side? I would expect that it does not work, since
> the form action no longer contains it's usual value, and the new form action
> points directly to an interface (IBehaviorListener).
> But I guess that since you're using Wicket.Ajax.Call.submitForm, server-side
> knows a form is being submitted.
>
> I got uploadify working in a componentized form. Works like a charm for now.
>
> Bas
>
> ----- Original Message ----- From: "Igor Vaynberg" <ig...@gmail.com>
> To: <us...@wicket.apache.org>
> Sent: Thursday, August 06, 2009 4:32 AM
> Subject: Re: Handle file uploads in Behavior and respond using
> AjaxRequestTarget
>
>
>> On Wed, Aug 5, 2009 at 4:10 PM, Bas Gooren<ba...@iswd.nl> wrote:
>>
>>> One of the working components I built using IFRAMEs is actually not that
>>> complex (400 LOC),
>>
>> i just wrote something that is about 30 lines of javascript that does
>> this. only works in firefox so far. see WICKET-2420.
>>
>> -igor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
Posted by Bas Gooren <ba...@iswd.nl>.
Interesting, it looks like you simply POST the form to the AJAX url using an
IFRAME.
How does it work server-side? I would expect that it does not work, since
the form action no longer contains it's usual value, and the new form action
points directly to an interface (IBehaviorListener).
But I guess that since you're using Wicket.Ajax.Call.submitForm, server-side
knows a form is being submitted.
I got uploadify working in a componentized form. Works like a charm for now.
Bas
----- Original Message -----
From: "Igor Vaynberg" <ig...@gmail.com>
To: <us...@wicket.apache.org>
Sent: Thursday, August 06, 2009 4:32 AM
Subject: Re: Handle file uploads in Behavior and respond using
AjaxRequestTarget
> On Wed, Aug 5, 2009 at 4:10 PM, Bas Gooren<ba...@iswd.nl> wrote:
>
>> One of the working components I built using IFRAMEs is actually not that
>> complex (400 LOC),
>
> i just wrote something that is about 30 lines of javascript that does
> this. only works in firefox so far. see WICKET-2420.
>
> -igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handle file uploads in Behavior and respond using
AjaxRequestTarget
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Aug 5, 2009 at 4:10 PM, Bas Gooren<ba...@iswd.nl> wrote:
> One of the working components I built using IFRAMEs is actually not that
> complex (400 LOC),
i just wrote something that is about 30 lines of javascript that does
this. only works in firefox so far. see WICKET-2420.
-igor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
Posted by Bas Gooren <ba...@iswd.nl>.
Igor,
First off: thanks for the amazingly fast response!
Yes, it feels like I'm overcomplicating things. But then again: there does
not seem to be an easy way.
An upload + AJAX refresh always needs 2 requests, which means (for me) that
I need to preserve the upload somewhere between those requests.
Since this stuff is very easy on other platforms it's just too bad it's like
this with Wicket. I mean, I really love Wicket, and most of my new projects
are built on Wicket.
But things like this one (http://www.uploadify.com/) I'm trying to wrap in a
component/behavior right now is difficult to say the least.
One of the working components I built using IFRAMEs is actually not that
complex (400 LOC), and the problem is not so much in the rendering.
It could also be the complexity is in the wrong place... Right now this is
the flow:
- handle upload, store temp file, pass uuid to client
- client runs ajax request with the uuid
- ajax handler in wicket processes the temp file, and re-renders components
I could choose to process the files @ upload time, and the ajax request only
re-renders elements. Though that does mean components which embed the upload
component need to implement two methods (processUpload, processAjax) instead
of one (processAjax(upload,ajax)).
How would you go about building a component or behavior for Uploadify?
Let's forget about the IFRAME solution for a second: flash-based uploading
replaces the IFRAME.
Regards,
Bas
----- Original Message -----
From: "Igor Vaynberg" <ig...@gmail.com>
To: <us...@wicket.apache.org>
Sent: Thursday, August 06, 2009 12:51 AM
Subject: Re: Handle file uploads in Behavior and respond using
AjaxRequestTarget
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<ba...@iswd.nl> 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@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Handle file uploads in Behavior and respond using
AjaxRequestTarget
Posted by Russell Simpkins <ru...@hotmail.com>.
i've done this with php and ajax. the form posts, using target, to a hidden iframe. the response rendered back to the iframe is javascript. The only thing the iframe renders is javascript.
In your page you have javascript functions for the onSuccess() or onFailure() that are specific to that page. Or since you are rendering javascript you can render any javascript you like. This is very ajax "like" in that you are simply rendering callbacks. I suppose you could take it one step further and post the names of your callback functions.
I'm not sure if this is any cleaner or any help at all, but I do hope it helps.
Russ
----------------------------------------
> From: igor.vaynberg@gmail.com
> Date: Wed, 5 Aug 2009 15:51:44 -0700
> Subject: Re: Handle file uploads in Behavior and respond using AjaxRequestTarget
> To: users@wicket.apache.org
>
> 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 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@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
_________________________________________________________________
Get free photo software from Windows Live
http://www.windowslive.com/online/photos?ocid=PID23393::T:WLMTAGL:ON:WL:en-US:SI_PH_software:082009
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handle file uploads in Behavior and respond using
AjaxRequestTarget
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Aug 5, 2009 at 3:58 PM, Jeremy
Thomerson<je...@wickettraining.com> 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<ig...@gmail.com> 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<ba...@iswd.nl> 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@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: Handle file uploads in Behavior and respond using
AjaxRequestTarget
Posted by Jeremy Thomerson <je...@wickettraining.com>.
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<ig...@gmail.com> 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<ba...@iswd.nl> 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@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>