Re: Strange issue with AJAX update + file download
...sorry, forgot that sending attachments to mailing-lists does not generally work... http://picpaste.com/firebug.png http://picpaste.com/chrome_after_download.png Hi, We're using Wicket 1.5.11 with the approach described in https://cwiki.apache.org/confluence/display/WICKET/AJAX+update+and+file+download+in+one+blow to trigger a file download from within a modal dialog. This all works fine, our problem is with the rendering of the page after the download is complete. The page contains some dynamic images/icons that are included via Image/DynamicImageResource (all have a 'antiCache' parameter in their URL as well as a last-modified date that equals now() ). Both chrome and firefox re-request these images after the download has completed and looking at the network traffic/PCAP file I captured , I can see that Wicket is in fact delivering the PNGs to the browser. But: Chrome still renders these icons using the 'image is broken' placeholder icon and Firefox/firebug shows the image downloads as 'never completed' / 0 bytes downloaded (see attached screenshots). Firebug also shows a pending GET request for a JavaScript file along with the image download requests so the issue may be related to either caching or the Wicket request processing in general. Any ideas ? Thanks in advance, Tobias - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange issue with AJAX update + file download
Hi,
I have no idea but something you can try is replacing
target.appendJavaScript(setTimeout(\window.location.href=' + url + '\,
100););
with a bigger timeout... or maybe $(function() { window}); so that
download is triggered once DOM is ready.
On Thu, Apr 10, 2014 at 11:02 AM, Tobias Gierke
tobias.gie...@voipfuture.com wrote:
...sorry, forgot that sending attachments to mailing-lists does not
generally work...
http://picpaste.com/firebug.png
http://picpaste.com/chrome_after_download.png
Hi,
We're using Wicket 1.5.11 with the approach described in
https://cwiki.apache.org/confluence/display/WICKET/
AJAX+update+and+file+download+in+one+blow to trigger a file download
from within a modal dialog. This all works fine, our problem is with the
rendering of the page after the download is complete.
The page contains some dynamic images/icons that are included via
Image/DynamicImageResource (all have a 'antiCache' parameter in their URL
as well as a last-modified date that equals now() ). Both chrome and
firefox re-request these images after the download has completed and
looking at the network traffic/PCAP file I captured , I can see that Wicket
is in fact delivering the PNGs to the browser.
But: Chrome still renders these icons using the 'image is broken'
placeholder icon and Firefox/firebug shows the image downloads as 'never
completed' / 0 bytes downloaded (see attached screenshots). Firebug also
shows a pending GET request for a JavaScript file along with the image
download requests so the issue may be related to either caching or the
Wicket request processing in general.
Any ideas ?
Thanks in advance,
Tobias
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Regards - Ernesto Reinaldo Barreiro
Re: Strange issue with AJAX update + file download
Hi,
Tried both your suggestions, unfortunately none of them worked :(
Thanks anyway,
Tobias
Hi,
I have no idea but something you can try is replacing
target.appendJavaScript(setTimeout(\window.location.href=' + url + '\,
100););
with a bigger timeout... or maybe $(function() { window}); so that
download is triggered once DOM is ready.
On Thu, Apr 10, 2014 at 11:02 AM, Tobias Gierke
tobias.gie...@voipfuture.com wrote:
...sorry, forgot that sending attachments to mailing-lists does not
generally work...
http://picpaste.com/firebug.png
http://picpaste.com/chrome_after_download.png
Hi,
We're using Wicket 1.5.11 with the approach described in
https://cwiki.apache.org/confluence/display/WICKET/
AJAX+update+and+file+download+in+one+blow to trigger a file download
from within a modal dialog. This all works fine, our problem is with the
rendering of the page after the download is complete.
The page contains some dynamic images/icons that are included via
Image/DynamicImageResource (all have a 'antiCache' parameter in their URL
as well as a last-modified date that equals now() ). Both chrome and
firefox re-request these images after the download has completed and
looking at the network traffic/PCAP file I captured , I can see that Wicket
is in fact delivering the PNGs to the browser.
But: Chrome still renders these icons using the 'image is broken'
placeholder icon and Firefox/firebug shows the image downloads as 'never
completed' / 0 bytes downloaded (see attached screenshots). Firebug also
shows a pending GET request for a JavaScript file along with the image
download requests so the issue may be related to either caching or the
Wicket request processing in general.
Any ideas ?
Thanks in advance,
Tobias
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange issue with AJAX update + file download
Hi, On Thu, Apr 10, 2014 at 10:50 AM, Tobias Gierke tobias.gie...@voipfuture.com wrote: Hi, We're using Wicket 1.5.11 with the approach described in https://cwiki.apache.org/confluence/display/WICKET/ AJAX+update+and+file+download+in+one+blow to trigger a file download from within a modal dialog. This all works fine, our problem is with the rendering of the page after the download is complete. What do you exactly mean by the rendering of the page after download completed? You repaint a part of the screen via AJAX? And this is the one giving problem with images? The page contains some dynamic images/icons that are included via Image/DynamicImageResource (all have a 'antiCache' parameter in their URL as well as a last-modified date that equals now() ). Both chrome and firefox re-request these images after the download has completed and looking at the network traffic/PCAP file I captured , I can see that Wicket is in fact delivering the PNGs to the browser. But: Chrome still renders these icons using the 'image is broken' placeholder icon and Firefox/firebug shows the image downloads as 'never completed' / 0 bytes downloaded (see attached screenshots). Firebug also shows a pending GET request for a JavaScript file along with the image download requests so the issue may be related to either caching or the Wicket request processing in general. Any ideas ? Thanks in advance, Tobias - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Regards - Ernesto Reinaldo Barreiro
Re: Strange issue with AJAX update + file download
Hi, What do you exactly mean by the rendering of the page after download completed? You repaint a part of the screen via AJAX? And this is the one giving problem with images? Good point. I just investigated the AJAX response returned by the server when clicking the 'Start download' button on the modal dialog and I noticed that along with the JavaScript snippet that does the setTimeout(...) there are also a lot of AJAX component updates that are obviously generated by components with overridden onEvent() methods. I didn't write the code so I wasn't aware of this :/ I suspect that the issue I'm seeing is caused by the Wicket AJAX library being interrupted by the setTimeout() call while processing the component updates... proving this will unfortunately take some time since the page has a lot of different components that all override onEvent() ... Thanks, Tobias The page contains some dynamic images/icons that are included via Image/DynamicImageResource (all have a 'antiCache' parameter in their URL as well as a last-modified date that equals now() ). Both chrome and firefox re-request these images after the download has completed and looking at the network traffic/PCAP file I captured , I can see that Wicket is in fact delivering the PNGs to the browser. But: Chrome still renders these icons using the 'image is broken' placeholder icon and Firefox/firebug shows the image downloads as 'never completed' / 0 bytes downloaded (see attached screenshots). Firebug also shows a pending GET request for a JavaScript file along with the image download requests so the issue may be related to either caching or the Wicket request processing in general. Any ideas ? Thanks in advance, Tobias - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Tobias Gierke Development VOIPFUTURE GmbH Wendenstraße 4 20097 Hamburg, Germany Phone +49 40 688 900 111 Fax +49 40 688 900 199 Email tobias.gie...@voipfuture.com Web http://www.voipfuture.com CEO Jan Bastian Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange issue with AJAX update + file download
Hi, On Thu, Apr 10, 2014 at 12:13 PM, Tobias Gierke tobias.gie...@voipfuture.com wrote: Hi, What do you exactly mean by the rendering of the page after download completed? You repaint a part of the screen via AJAX? And this is the one giving problem with images? Good point. I just investigated the AJAX response returned by the server when clicking the 'Start download' button on the modal dialog and I noticed that along with the JavaScript snippet that does the setTimeout(...) there are also a lot of AJAX component updates that are obviously generated by components with overridden onEvent() methods. I didn't write the code so I wasn't aware of this :/ This does not sounds very clean: you will be updating all of thos for anything AJAX you do on the page. I suspect that the issue I'm seeing is caused by the Wicket AJAX library being interrupted by the setTimeout() call while processing the component updates... proving this will unfortunately take some time since the page has a lot of different components that all override onEvent() ... In fact the setTimeout is the way of spanning a new thread on JavaScript: that part was added by Martin Grigorov, if I recall it correctly, precisely just to give wicket AJAX the possibility of complete processing. Thanks, Tobias The page contains some dynamic images/icons that are included via Image/DynamicImageResource (all have a 'antiCache' parameter in their URL as well as a last-modified date that equals now() ). Both chrome and firefox re-request these images after the download has completed and looking at the network traffic/PCAP file I captured , I can see that Wicket is in fact delivering the PNGs to the browser. But: Chrome still renders these icons using the 'image is broken' placeholder icon and Firefox/firebug shows the image downloads as 'never completed' / 0 bytes downloaded (see attached screenshots). Firebug also shows a pending GET request for a JavaScript file along with the image download requests so the issue may be related to either caching or the Wicket request processing in general. Any ideas ? Thanks in advance, Tobias - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Tobias Gierke Development VOIPFUTURE GmbH Wendenstraße 4 20097 Hamburg, Germany Phone +49 40 688 900 111 Fax +49 40 688 900 199 Email tobias.gie...@voipfuture.com Web http://www.voipfuture.com CEO Jan Bastian Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Regards - Ernesto Reinaldo Barreiro
Solved [ Re: Strange issue with AJAX update + file download ]
Sorry for the noise, I just tried to validate my assumption by (again) setting the timeout to some really large value (20 seconds) and noticed that I screwed up while testing your initial suggestion , the changed timeout value was never in effect ... Raising the timeout value does in fact solve the issue (although I don't like the solution since the required timeout value depends on the speed of the connection/request processing so this is bound to break sooner than later). Thank you very much, Tobias Hi, What do you exactly mean by the rendering of the page after download completed? You repaint a part of the screen via AJAX? And this is the one giving problem with images? Good point. I just investigated the AJAX response returned by the server when clicking the 'Start download' button on the modal dialog and I noticed that along with the JavaScript snippet that does the setTimeout(...) there are also a lot of AJAX component updates that are obviously generated by components with overridden onEvent() methods. I didn't write the code so I wasn't aware of this :/ I suspect that the issue I'm seeing is caused by the Wicket AJAX library being interrupted by the setTimeout() call while processing the component updates... proving this will unfortunately take some time since the page has a lot of different components that all override onEvent() ... Thanks, Tobias The page contains some dynamic images/icons that are included via Image/DynamicImageResource (all have a 'antiCache' parameter in their URL as well as a last-modified date that equals now() ). Both chrome and firefox re-request these images after the download has completed and looking at the network traffic/PCAP file I captured , I can see that Wicket is in fact delivering the PNGs to the browser. But: Chrome still renders these icons using the 'image is broken' placeholder icon and Firefox/firebug shows the image downloads as 'never completed' / 0 bytes downloaded (see attached screenshots). Firebug also shows a pending GET request for a JavaScript file along with the image download requests so the issue may be related to either caching or the Wicket request processing in general. Any ideas ? Thanks in advance, Tobias - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange issue with AJAX update + file download
Hi, On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke tobias.gie...@voipfuture.com wrote: Hi, What do you exactly mean by the rendering of the page after download completed? You repaint a part of the screen via AJAX? And this is the one giving problem with images? Good point. I just investigated the AJAX response returned by the server when clicking the 'Start download' button on the modal dialog and I noticed that along with the JavaScript snippet that does the setTimeout(...) there are also a lot of AJAX component updates that are obviously generated by components with overridden onEvent() methods. I didn't write the code so I wasn't aware of this :/ I suspect that the issue I'm seeing is caused by the Wicket AJAX library being interrupted by the setTimeout() call while processing the component updates... proving this will unfortunately take some time since the page has a lot of different components that all override onEvent() ... JavaScript is single-threaded. There is no way to interrupt it. By using setTimeout/setInterval functions you just add tasks to the queue that this single thread processes. Thanks, Tobias The page contains some dynamic images/icons that are included via Image/DynamicImageResource (all have a 'antiCache' parameter in their URL as well as a last-modified date that equals now() ). Both chrome and firefox re-request these images after the download has completed and looking at the network traffic/PCAP file I captured , I can see that Wicket is in fact delivering the PNGs to the browser. But: Chrome still renders these icons using the 'image is broken' placeholder icon and Firefox/firebug shows the image downloads as 'never completed' / 0 bytes downloaded (see attached screenshots). Firebug also shows a pending GET request for a JavaScript file along with the image download requests so the issue may be related to either caching or the Wicket request processing in general. Any ideas ? Thanks in advance, Tobias - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Tobias Gierke Development VOIPFUTURE GmbH Wendenstraße 4 20097 Hamburg, Germany Phone +49 40 688 900 111 Fax +49 40 688 900 199 Email tobias.gie...@voipfuture.com Web http://www.voipfuture.com CEO Jan Bastian Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange issue with AJAX update + file download
Hi, Hi, On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke tobias.gie...@voipfuture.com wrote: Hi, What do you exactly mean by the rendering of the page after download completed? You repaint a part of the screen via AJAX? And this is the one giving problem with images? Good point. I just investigated the AJAX response returned by the server when clicking the 'Start download' button on the modal dialog and I noticed that along with the JavaScript snippet that does the setTimeout(...) there are also a lot of AJAX component updates that are obviously generated by components with overridden onEvent() methods. I didn't write the code so I wasn't aware of this :/ I suspect that the issue I'm seeing is caused by the Wicket AJAX library being interrupted by the setTimeout() call while processing the component updates... proving this will unfortunately take some time since the page has a lot of different components that all override onEvent() ... JavaScript is single-threaded. There is no way to interrupt it. By using setTimeout/setInterval functions you just add tasks to the queue that this single thread processes. I stand corrected ;) But how come - given that setTimeout() just adds a task to some queue - the actual magnitude of the timeout has an effect ? My queues are usually processed first-to-last ;) Cheers, Tobias Thanks, Tobias The page contains some dynamic images/icons that are included via Image/DynamicImageResource (all have a 'antiCache' parameter in their URL as well as a last-modified date that equals now() ). Both chrome and firefox re-request these images after the download has completed and looking at the network traffic/PCAP file I captured , I can see that Wicket is in fact delivering the PNGs to the browser. But: Chrome still renders these icons using the 'image is broken' placeholder icon and Firefox/firebug shows the image downloads as 'never completed' / 0 bytes downloaded (see attached screenshots). Firebug also shows a pending GET request for a JavaScript file along with the image download requests so the issue may be related to either caching or the Wicket request processing in general. Any ideas ? Thanks in advance, Tobias - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Tobias Gierke Development VOIPFUTURE GmbH Wendenstraße 4 20097 Hamburg, Germany Phone +49 40 688 900 111 Fax +49 40 688 900 199 Email tobias.gie...@voipfuture.com Web http://www.voipfuture.com CEO Jan Bastian Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Tobias Gierke Development VOIPFUTURE GmbH Wendenstraße 4 20097 Hamburg, Germany Phone +49 40 688 900 111 Fax +49 40 688 900 199 Email tobias.gie...@voipfuture.com Web http://www.voipfuture.com CEO Jan Bastian Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange issue with AJAX update + file download
On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke tobias.gie...@voipfuture.com wrote: Hi, What do you exactly mean by the rendering of the page after download completed? You repaint a part of the screen via AJAX? And this is the one giving problem with images? Good point. I just investigated the AJAX response returned by the server when clicking the 'Start download' button on the modal dialog and I noticed that along with the JavaScript snippet that does the setTimeout(...) there are also a lot of AJAX component updates that are obviously generated by components with overridden onEvent() methods. I didn't write the code so I wasn't aware of this :/ I suspect that the issue I'm seeing is caused by the Wicket AJAX library being interrupted by the setTimeout() call while processing the component updates... proving this will unfortunately take some time since the page has a lot of different components that all override onEvent() ... JavaScript is single-threaded. There is no way to interrupt it. By using setTimeout/setInterval functions you just add tasks to the queue that this single thread processes. I stand corrected ;) But how come - given that setTimeout() just adds a task to some queue - the actual magnitude of the timeout has an effect ? My queues are usually processed first-to-last ;) Forgive my ignorance, I just read http://ejohn.org/blog/how-javascript-timers-work and was enlightened ;) Cheers, Tobias - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange issue with AJAX update + file download
Hi, On Thu, Apr 10, 2014 at 12:36 PM, Tobias Gierke tobias.gie...@voipfuture.com wrote: Hi, Hi, On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke tobias.gie...@voipfuture.com wrote: Hi, What do you exactly mean by the rendering of the page after download completed? You repaint a part of the screen via AJAX? And this is the one giving problem with images? Good point. I just investigated the AJAX response returned by the server when clicking the 'Start download' button on the modal dialog and I noticed that along with the JavaScript snippet that does the setTimeout(...) there are also a lot of AJAX component updates that are obviously generated by components with overridden onEvent() methods. I didn't write the code so I wasn't aware of this :/ I suspect that the issue I'm seeing is caused by the Wicket AJAX library being interrupted by the setTimeout() call while processing the component updates... proving this will unfortunately take some time since the page has a lot of different components that all override onEvent() ... JavaScript is single-threaded. There is no way to interrupt it. By using setTimeout/setInterval functions you just add tasks to the queue that this single thread processes. I stand corrected ;) But how come - given that setTimeout() just adds a task to some queue - the actual magnitude of the timeout has an effect ? My queues are usually processed first-to-last ;) Probably the time out just influence the download of images: e.g. maybe by making window.location.href=' + url + '\, 100); You are telling the browser stop loading images, we are processing anew document Cheers, Tobias Thanks, Tobias The page contains some dynamic images/icons that are included via Image/DynamicImageResource (all have a 'antiCache' parameter in their URL as well as a last-modified date that equals now() ). Both chrome and firefox re-request these images after the download has completed and looking at the network traffic/PCAP file I captured , I can see that Wicket is in fact delivering the PNGs to the browser. But: Chrome still renders these icons using the 'image is broken' placeholder icon and Firefox/firebug shows the image downloads as 'never completed' / 0 bytes downloaded (see attached screenshots). Firebug also shows a pending GET request for a JavaScript file along with the image download requests so the issue may be related to either caching or the Wicket request processing in general. Any ideas ? Thanks in advance, Tobias - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Tobias Gierke Development VOIPFUTURE GmbH Wendenstraße 4 20097 Hamburg, Germany Phone +49 40 688 900 111 Fax +49 40 688 900 199 Email tobias.gie...@voipfuture.com Web http://www.voipfuture.com CEO Jan Bastian Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Tobias Gierke Development VOIPFUTURE GmbH Wendenstraße 4 20097 Hamburg, Germany Phone +49 40 688 900 111 Fax +49 40 688 900 199 Email tobias.gie...@voipfuture.com Web http://www.voipfuture.com CEO Jan Bastian Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Regards - Ernesto Reinaldo Barreiro
Re: Strange issue with AJAX update + file download
On Thu, Apr 10, 2014 at 1:44 PM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Hi, On Thu, Apr 10, 2014 at 12:36 PM, Tobias Gierke tobias.gie...@voipfuture.com wrote: Hi, Hi, On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke tobias.gie...@voipfuture.com wrote: Hi, What do you exactly mean by the rendering of the page after download completed? You repaint a part of the screen via AJAX? And this is the one giving problem with images? Good point. I just investigated the AJAX response returned by the server when clicking the 'Start download' button on the modal dialog and I noticed that along with the JavaScript snippet that does the setTimeout(...) there are also a lot of AJAX component updates that are obviously generated by components with overridden onEvent() methods. I didn't write the code so I wasn't aware of this :/ I suspect that the issue I'm seeing is caused by the Wicket AJAX library being interrupted by the setTimeout() call while processing the component updates... proving this will unfortunately take some time since the page has a lot of different components that all override onEvent() ... JavaScript is single-threaded. There is no way to interrupt it. By using setTimeout/setInterval functions you just add tasks to the queue that this single thread processes. I stand corrected ;) But how come - given that setTimeout() just adds a task to some queue - the actual magnitude of the timeout has an effect ? My queues are usually processed first-to-last ;) Probably the time out just influence the download of images: e.g. maybe by making window.location.href=' + url + '\, 100); You are telling the browser stop loading images, we are processing anew document There is still something unclear here - window.location.href is contributed via target.appendJavaScript(). This means it is put into evaluate XML element in the Ajax response and should be processed (sequentially!) later than the resource downloads by Wicket.FunctionExecuter. I.e. the resources should fire their loaded events before FunctionExecuter to move to the next task Cheers, Tobias Thanks, Tobias The page contains some dynamic images/icons that are included via Image/DynamicImageResource (all have a 'antiCache' parameter in their URL as well as a last-modified date that equals now() ). Both chrome and firefox re-request these images after the download has completed and looking at the network traffic/PCAP file I captured , I can see that Wicket is in fact delivering the PNGs to the browser. But: Chrome still renders these icons using the 'image is broken' placeholder icon and Firefox/firebug shows the image downloads as 'never completed' / 0 bytes downloaded (see attached screenshots). Firebug also shows a pending GET request for a JavaScript file along with the image download requests so the issue may be related to either caching or the Wicket request processing in general. Any ideas ? Thanks in advance, Tobias - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Tobias Gierke Development VOIPFUTURE GmbH Wendenstraße 4 20097 Hamburg, Germany Phone +49 40 688 900 111 Fax +49 40 688 900 199 Email tobias.gie...@voipfuture.com Web http://www.voipfuture.com CEO Jan Bastian Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Tobias Gierke Development VOIPFUTURE GmbH Wendenstraße 4 20097 Hamburg, Germany Phone +49 40 688 900 111 Fax +49 40 688 900 199 Email tobias.gie...@voipfuture.com Web http://www.voipfuture.com CEO Jan Bastian Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Regards - Ernesto Reinaldo Barreiro
Re: Strange issue with AJAX update + file download
On 10/04/2014 12:53, Martin Grigorov wrote:
On Thu, Apr 10, 2014 at 1:44 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Hi,
On Thu, Apr 10, 2014 at 12:36 PM, Tobias Gierke
tobias.gie...@voipfuture.com wrote:
Hi,
Hi,
On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke
tobias.gie...@voipfuture.com
wrote:
Hi,
What do you exactly mean by the rendering of the page after download
completed? You repaint a part of the screen via AJAX? And this is the
one
giving problem with images?
Good point. I just investigated the AJAX response returned by the
server
when clicking the 'Start download' button on the modal dialog and I
noticed
that along with the JavaScript snippet that does the setTimeout(...)
there are also a lot of AJAX component updates that are obviously
generated
by components with overridden onEvent() methods. I didn't write the
code
so
I wasn't aware of this :/
I suspect that the issue I'm seeing is caused by the Wicket AJAX
library
being interrupted by the setTimeout() call while processing the
component
updates... proving this will unfortunately take some time since the
page
has a lot of different components that all override onEvent() ...
JavaScript is single-threaded. There is no way to interrupt it.
By using setTimeout/setInterval functions you just add tasks to the
queue
that this single thread processes.
I stand corrected ;) But how come - given that setTimeout() just adds a
task to some queue - the actual magnitude of the timeout has an effect
?
My queues are usually processed first-to-last ;)
Probably the time out just influence the download of images: e.g. maybe by
making
window.location.href=' + url + '\, 100);
You are telling the browser stop loading images, we are processing anew
document
There is still something unclear here - window.location.href is contributed
via target.appendJavaScript().
This means it is put into evaluate XML element in the Ajax response and
should be processed (sequentially!) later than the resource downloads by
Wicket.FunctionExecuter. I.e. the resources should fire their loaded
events before FunctionExecuter to move to the next task
Page locking maybe? Does the download lock the page for the duration of
the download?
ajax get
ajax response
dom modified
browser starts downloading images in background, one (or a few) at a time
download of file starts (page is locked on server)
while file download is still busy, browser attempts to download other
images. This may require page lock on server, which will make this
request hang until file download is complete.
Maybe, instead of using AJAXDownload, make like:
new AjaxLink(link){
@Override
public void onClick(AjaxRequestTarget target){
// do whatever
target.add(...);
Application.get().getResourceReferenceRegistry().registerResourceReference(MyDownloadResourceReference.INSTANCE);
target.appendJavaScript(setTimeout(\window.location.href=' +
urlFor(MyDownloadResourceReference.INSTANCE, null) + '\, 100););
}
};
public class MyDownloadResourceReference
extends ResourceReference
{
public static final MyDownloadResourceReference INSTACE = new
MyDownloadResourceReference();
public MyDownloadResourceReference()
{
super(MyApp.class, download-woteva);
}
@Override
public IResource getResource()
{
// return resource
}
}
You will need to have some sort of way of passing information from the
page to the IResource about exactly what should be downloaded. You can
do this with by storing temp info in the session (not so great), or by
passing PageParameters in the urlFor() instead of null, and parsing them
in the IResource.
HTH,
Jesse
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange issue with AJAX update + file download
one solution might be to pull document from a mounted resource: which are
not locked.
On Thu, Apr 10, 2014 at 6:16 PM, Jesse Long j...@unknown.za.net wrote:
On 10/04/2014 12:53, Martin Grigorov wrote:
On Thu, Apr 10, 2014 at 1:44 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Hi,
On Thu, Apr 10, 2014 at 12:36 PM, Tobias Gierke
tobias.gie...@voipfuture.com wrote:
Hi,
Hi,
On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke
tobias.gie...@voipfuture.com
wrote:
Hi,
What do you exactly mean by the rendering of the page after
download
completed? You repaint a part of the screen via AJAX? And this is the
one
giving problem with images?
Good point. I just investigated the AJAX response returned by the
server
when clicking the 'Start download' button on the modal dialog and I
noticed
that along with the JavaScript snippet that does the setTimeout(...)
there are also a lot of AJAX component updates that are obviously
generated
by components with overridden onEvent() methods. I didn't write the
code
so
I wasn't aware of this :/
I suspect that the issue I'm seeing is caused by the Wicket AJAX
library
being interrupted by the setTimeout() call while processing the
component
updates... proving this will unfortunately take some time since the
page
has a lot of different components that all override onEvent() ...
JavaScript is single-threaded. There is no way to interrupt it.
By using setTimeout/setInterval functions you just add tasks to the
queue
that this single thread processes.
I stand corrected ;) But how come - given that setTimeout() just
adds a
task to some queue - the actual magnitude of the timeout has an effect
?
My queues are usually processed first-to-last ;)
Probably the time out just influence the download of images: e.g.
maybe by
making
window.location.href=' + url + '\, 100);
You are telling the browser stop loading images, we are processing anew
document
There is still something unclear here - window.location.href is
contributed
via target.appendJavaScript().
This means it is put into evaluate XML element in the Ajax response and
should be processed (sequentially!) later than the resource downloads by
Wicket.FunctionExecuter. I.e. the resources should fire their loaded
events before FunctionExecuter to move to the next task
Page locking maybe? Does the download lock the page for the duration of
the download?
ajax get
ajax response
dom modified
browser starts downloading images in background, one (or a few) at a time
download of file starts (page is locked on server)
while file download is still busy, browser attempts to download other
images. This may require page lock on server, which will make this request
hang until file download is complete.
Maybe, instead of using AJAXDownload, make like:
new AjaxLink(link){
@Override
public void onClick(AjaxRequestTarget target){
// do whatever
target.add(...);
Application.get().getResourceReferenceRegistry()
.registerResourceReference(MyDownloadResourceReference.INSTANCE);
target.appendJavaScript(setTimeout(\window.location.href=' + urlFor(
MyDownloadResourceReference.INSTANCE, null) + '\, 100););
}
};
public class MyDownloadResourceReference
extends ResourceReference
{
public static final MyDownloadResourceReference INSTACE = new
MyDownloadResourceReference();
public MyDownloadResourceReference()
{
super(MyApp.class, download-woteva);
}
@Override
public IResource getResource()
{
// return resource
}
}
You will need to have some sort of way of passing information from the
page to the IResource about exactly what should be downloaded. You can do
this with by storing temp info in the session (not so great), or by passing
PageParameters in the urlFor() instead of null, and parsing them in the
IResource.
HTH,
Jesse
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Regards - Ernesto Reinaldo Barreiro
