Re: FileUPloadField alternatives?
On Mon, Nov 25, 2013 at 7:17 PM, Martin Dietze d...@fh-wedel.de wrote: On Mon, November 25, 2013, Martin Grigorov wrote: I guess that the problem is in https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js?source=cc#L856 If I understand this correctly I might get away by producing a deployable in which that line is simply commented out (as it is intended for Chrome compatibility only)? Also, in a second No. This line is important to process the Ajax XML response. approach, moving that line above the 'form.submit()' seems worthwhile as changing the DOM while a request is still in progress does not look totally harmless to me either? Try it. I'll have a go and have my customer try it (unfortunately I don't have physical access to a box that exhibits this problem). Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= If you cannot convince them, confuse them. -- Harry S Truman - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: FileUPloadField alternatives?
On Tue, November 26, 2013, Martin Grigorov wrote: If I understand this correctly I might get away by producing a deployable in which that line is simply commented out (as it is intended for Chrome compatibility only)? Also, in a second No. This line is important to process the Ajax XML response. Yep, at a second glance I realised this :) worthwhile as changing the DOM while a request is still in progress does not look totally harmless to me either? Try it. Tried it, but the crash still occurs. If you have some more ideas, I'd greatly appreciate this. Actually that above hint seemed very likely a solution to me since the problem seems to occur on old hardware rather than on new one. I am currently trying to set up an old laptop with XP/IE8 hoping to be finally able to reproduce that problem. Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Who the fsck is General Failure, and why is he reading my disk? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: FileUPloadField alternatives?
On Tue, Nov 26, 2013 at 11:29 AM, Martin Dietze d...@fh-wedel.de wrote: On Tue, November 26, 2013, Martin Grigorov wrote: If I understand this correctly I might get away by producing a deployable in which that line is simply commented out (as it is intended for Chrome compatibility only)? Also, in a second No. This line is important to process the Ajax XML response. Yep, at a second glance I realised this :) worthwhile as changing the DOM while a request is still in progress does not look totally harmless to me either? Try it. Tried it, but the crash still occurs. If you have some more ideas, I'd greatly appreciate this. Try with MultiFileUploadField - http://www.wicket-library.com/wicket-examples-6.0.x/upload/multi?0 Actually that above hint seemed very likely a solution to me since the problem seems to occur on old hardware rather than on new one. I am currently trying to set up an old laptop with XP/IE8 hoping to be finally able to reproduce that problem. Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Who the fsck is General Failure, and why is he reading my disk? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: FileUPloadField alternatives?
On Tue, November 26, 2013, Martin Grigorov wrote: If you have some more ideas, I'd greatly appreciate this. Try with MultiFileUploadField - http://www.wicket-library.com/wicket-examples-6.0.x/upload/multi?0 No change, still freezes... M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Wie verhindert man, dass einem die Geige gestohlen wird? Man legt sie in einen Bratschenkasten... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: FileUPloadField alternatives?
Hi, On Mon, Nov 25, 2013 at 4:24 PM, Martin Dietze d...@fh-wedel.de wrote: In my project I am experiencing IE8 crashes at (Ajax-based) file upload. This happens with some particular machines my client uses, and, no, replacing them is (unfortunately) not an option. Can you explain what is the issue ? Maybe Wicket can workaround it ... I am therefore exploring alternatives, hoping that e.g. a flash- or javascript-based upload might not lead to this problem anymore (also, the possibility of uploading more than one file at a time yields some added value). To avoid having to rewrite lots of code, I would ideally like to find something that I can just replace my current FileUploadField/AjaxButton construction with. I took a look at Martin's repo and the file-upload example in it. Is there any way I can have my application notified by an Ajax call after the upload has been finished? It depends what kind of notification you need. You can pass the current page id as an extra request parameter when making the file upload Ajax call. This way you can use Session.get().getPageManager().getPage(pageId). You can cast the page or broadcast an event to notify it. I am not sure whether you will be able to use AjaxRequestTarget though. Because the Ajax call is made by the JS library, not with Wicket.Ajax.** APIs. So it will require some JS coding from you to process ajax-response in the library's onSuccess callback. Also, are there any other components that I could try? I took a look at wicket-uploadify, but that library is based on wicket 1.5, and apart from that I haven't found anything. Is it hard to migrate it to 6.x ? Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Yoda of Borg I am. Assimilated you will be. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: FileUPloadField alternatives?
On Mon, November 25, 2013, Martin Grigorov wrote:
In my project I am experiencing IE8 crashes at (Ajax-based) file
upload. This happens with some particular machines my client
uses, and, no, replacing them is (unfortunately) not an option.
Can you explain what is the issue ?
Maybe Wicket can workaround it ...
I'll try to. Since I cannot reproduce the problem myself (on my
IE8 the application works just fine), I can hardly describe much
more than the symptoms.
When uploading a file using an AjaxButton, the browser freezes
after the upload has been processed on the server, i.e. the
button stays 'pushed', and the browser needs to be closed using
the task manager. The action behind my upload button is fully
executed, i.e. the upload is being processed successfully, and
the components that need Ajax update are added to the onSubmit
method's ART. That's the last I see from that browser in the
logs.
In order to narrow down the problem I've created an upload test
page. It contains a simple form with an
FileUploadField/AjaxButton in it. Also there is the upload
component panel we use in our application (it maintains a list
of uploads that are updated via Ajax and shown under the upload
button).
Last Friday I made the trip to our customer's and took a closer
look at one of the machines. All of them are WinXP/IE8 boxes,
supposedly with identical configurations, but only some of them
exhibit those crashes (but those do this each time we try).
When running on Wicket 6.9.12 the browser crashes even with the
simplest configuration (FileUploadField/AjaxButton). After
downgrading to 6.8.0 (since there once was an issue in the
wicket bugtracker), the browser survives that first check, but
it crashes when trying out our application's upload component.
This leads me to think that there is some Javascript/Ajax stuff
involved in this crash. That's about all I know. I may give you
access to that test page via email if you like to check yourself.
I am not sure whether you will be able to use AjaxRequestTarget though.
Because the Ajax call is made by the JS library, not with Wicket.Ajax.**
APIs. So it will require some JS coding from you to process ajax-response
in the library's onSuccess callback.
That's what I feared :)
This simply means that I will have to dig deeper into that
particular upload library. Since I don't even know whether it
will solve my problem I will have to consider...
Also, are there any other components that I could try? I took a
look at wicket-uploadify, but that library is based on wicket
1.5, and apart from that I haven't found anything.
Is it hard to migrate it to 6.x ?
It contains some Javascript that will most likely no longer
work. Also it is totally undocumented, I don't know how to use
it and if it even works. Actually I went into the same question,
how can I notify my application so that I can use it the same
way I used to use the stock FileUploadField.
Cheers,
M'bert
--
--- / http://herbert.the-little-red-haired-girl.org / -
=+=
#define S Goodbye!\n
main(){exit(printf(S) != strlen(S) ? 0 : 1);}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: FileUPloadField alternatives?
On Mon, Nov 25, 2013 at 5:15 PM, Martin Dietze d...@fh-wedel.de wrote:
On Mon, November 25, 2013, Martin Grigorov wrote:
In my project I am experiencing IE8 crashes at (Ajax-based) file
upload. This happens with some particular machines my client
uses, and, no, replacing them is (unfortunately) not an option.
Can you explain what is the issue ?
Maybe Wicket can workaround it ...
I'll try to. Since I cannot reproduce the problem myself (on my
IE8 the application works just fine), I can hardly describe much
more than the symptoms.
When uploading a file using an AjaxButton, the browser freezes
after the upload has been processed on the server, i.e. the
button stays 'pushed', and the browser needs to be closed using
the task manager. The action behind my upload button is fully
executed, i.e. the upload is being processed successfully, and
the components that need Ajax update are added to the onSubmit
method's ART. That's the last I see from that browser in the
logs.
In order to narrow down the problem I've created an upload test
page. It contains a simple form with an
FileUploadField/AjaxButton in it. Also there is the upload
component panel we use in our application (it maintains a list
of uploads that are updated via Ajax and shown under the upload
button).
I guess that the problem is in
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js?source=cc#L856
Most probably the 'load' event of the used iframe is not triggered.
IE 8's Dev Tools are not the best but you can try to debug it.
Last Friday I made the trip to our customer's and took a closer
look at one of the machines. All of them are WinXP/IE8 boxes,
supposedly with identical configurations, but only some of them
exhibit those crashes (but those do this each time we try).
When running on Wicket 6.9.12 the browser crashes even with the
simplest configuration (FileUploadField/AjaxButton). After
downgrading to 6.8.0 (since there once was an issue in the
wicket bugtracker), the browser survives that first check, but
it crashes when trying out our application's upload component.
This leads me to think that there is some Javascript/Ajax stuff
involved in this crash. That's about all I know. I may give you
access to that test page via email if you like to check yourself.
I am not sure whether you will be able to use AjaxRequestTarget though.
Because the Ajax call is made by the JS library, not with Wicket.Ajax.**
APIs. So it will require some JS coding from you to process
ajax-response
in the library's onSuccess callback.
That's what I feared :)
This simply means that I will have to dig deeper into that
particular upload library. Since I don't even know whether it
will solve my problem I will have to consider...
Also, are there any other components that I could try? I took a
look at wicket-uploadify, but that library is based on wicket
1.5, and apart from that I haven't found anything.
Is it hard to migrate it to 6.x ?
It contains some Javascript that will most likely no longer
work. Also it is totally undocumented, I don't know how to use
it and if it even works. Actually I went into the same question,
how can I notify my application so that I can use it the same
way I used to use the stock FileUploadField.
What is the url to this project ?
Cheers,
M'bert
--
--- / http://herbert.the-little-red-haired-girl.org /
-
=+=
#define S Goodbye!\n
main(){exit(printf(S) != strlen(S) ? 0 : 1);}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: FileUPloadField alternatives?
On Mon, November 25, 2013, Martin Grigorov wrote: I guess that the problem is in https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js?source=cc#L856 If I understand this correctly I might get away by producing a deployable in which that line is simply commented out (as it is intended for Chrome compatibility only)? Also, in a second approach, moving that line above the 'form.submit()' seems worthwhile as changing the DOM while a request is still in progress does not look totally harmless to me either? I'll have a go and have my customer try it (unfortunately I don't have physical access to a box that exhibits this problem). Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= If you cannot convince them, confuse them. -- Harry S Truman - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
