I've posted this question on the PharoJS Seaside forum and on stackoverflow, asking about onSuccess: not working correctly after a callback. In a text input field, if the user presses the [Enter] key we run this code... html jQuery ajax callback: [:value | self doSearchWith: value] value: html jQuery this value; onSuccess: ((html jQuery id: 'fieldId') load html: [:h | ...div to be rendered after search... ]) The intermittent symptom is that the user enters a value, presses [Enter]. The entered value reverts back to the previous value and the search result does not change. At first I thought the problem was that the onSuccess: script was being sent before the callback, but, after reading the gem logs more carefully, the problem turns out to be that the onSuccess: script is not run at all. The only place I run multiple web servers is in our GS + HAProxy setup. There is never a problem with one gem or in VW. If I add 'async: false' then the onSuccess: script always runs. But while the callback is running, the user sees no feedback. For most user actions I show a busy gif and a 10% opaque overlay. Neither of those work with 'async: false' because all display rendering held up. Any suggestions for how I can ensure a onSuccess: script runs after a callback? I understand that onSuccess: depends on the HTTP response code, but the callback action is always successful. Thanks for any help, Bob Nemec _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Bob,
two questions out of the blue:
Maybe both are completely pointless, just brainstorming Joachim Am 10.05.21 um 20:21 schrieb Bob Nemec
via Glass:
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel [hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Submit form conflicts were a problem in the past. I've replaced all the buttons on that view with anchors that look like buttons in order to avoid the enter key default action. But that is a good point: I'll double check that I not missed one. Here is a little bit more information... self onKeyPress: ( (JSStream on: '(window.event ? window.event.keyCode : event.which) == 13') then: (canvas jQuery ajax callback: aBlock value: canvas jQuery this value; onBeforeSend: (JSStream on: 'console.log("onBeforeSend")'); onSuccess: aScript; onComplete: (JSStream on: 'console.log("complete")'))) ...using this code I always see the 'onBeforeSend' in the log, and the callback is always triggered, but 'complete' is never displayed (I was not using onComplete: ... just a curiosity). I also have console.log() code in the onSuccess: script and it is consistent with the refresh rendering. i.e. it is not a case of the (html jQuery id: 'divToBeRefreshed') load html: [:r | ...] ) being sent but not happening. The success script is just not happening. Is there a place I can insert a trace for the callback result code? Although I would think that a bad callback result would show the same symptom on a single gem configuration as well, which it does not. Bob
On Monday, May 10, 2021, 03:16:15 p.m. EDT, jtuchel--- via Glass <[hidden email]> wrote:
Bob,
two questions out of the blue:
Maybe both are completely pointless, just brainstorming Joachim Am 10.05.21 um 20:21 schrieb Bob Nemec
via Glass:
I've posted this question
on the PharoJS Seaside forum and on stackoverflow, asking
about onSuccess: not working correctly after a callback.
In a text input field, if the user presses the [Enter] key
we run this code...
html jQuery ajax
callback: [:value | self doSearchWith:
value] value: html jQuery this value;
onSuccess:
((html jQuery id: 'fieldId') load html: [:h | ...div
to be rendered after search... ])
The intermittent symptom
is that the user enters a value, presses [Enter]. The
entered value reverts back to the previous value and the
search result does not change. At first I thought the
problem was that the onSuccess: script was being sent
before the callback, but, after reading the gem logs more
carefully, the problem turns out to be that the onSuccess:
script is not run at all. The only place I run multiple
web servers is in our GS + HAProxy setup. There is never a
problem with one gem or in VW.
If I add 'async: false'
then the onSuccess: script always runs. But while the
callback is running, the user sees no feedback. For most
user actions I show a busy gif and a 10% opaque overlay.
Neither of those work with 'async: false' because all
display rendering held up.
Any suggestions for how I
can ensure a onSuccess: script runs after a callback?
I understand that
onSuccess: depends on the HTTP response code, but
the callback action is always successful.
Thanks for any help, Bob Nemec
_______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel [hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Bob,
Yeah, these things should also be a
problem in a single image/gem, I agree. That would point in the
load balancer / HAProxy direction, wouldn't it?
Am 10.05.21 um 21:47 schrieb Bob Nemec:
Also make sure you don't have any submit/serialize calls in click handlers for those anchors that might get out of order. Maybe you can check event orders using the dev tools in your browser? I know you see the order in Firefox, I dunno about Chrome.
Joachim
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel [hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
The onSuccess not being called should be a javascript error, not seaside as
its jQuery in the browser that triggers it. Right? What happens if you replace your onSuccess: script with onSuccess: 'console.log("startSuccess");', aScript, 'console.log("endSuccess");'; ? What happens if you change it to onSuccess: ((html jQuery id: 'fieldId') load html: [:h | 1 halt ]) ? Can you always render the search result div or could it contain an error that messes up the onSuccess: javascript function? What version of jQuery are you running and have they fixed any bugs in it in any more up to date versions? GLASS mailing list wrote > Submit form conflicts were a problem in the past. I've replaced all the > buttons on that view with anchors that look like buttons in order to avoid > the enter key default action. But that is a good point: I'll double check > that I not missed one. > Here is a little bit more information... self onKeyPress: ( (JSStream > on: '(window.event ? window.event.keyCode : event.which) == 13') then: > (canvas jQuery ajax callback: aBlock value: canvas jQuery this value; > onBeforeSend: (JSStream on: 'console.log("onBeforeSend")'); onSuccess: > aScript; onComplete: (JSStream on: 'console.log("complete")'))) > ...using this code I always see the 'onBeforeSend' in the log, and the > callback is always triggered, but 'complete' is never displayed (I was not > using onComplete: ... just a curiosity). I also have console.log() code in > the onSuccess: script and it is consistent with the refresh rendering. > i.e. it is not a case of the (html jQuery id: 'divToBeRefreshed') load > html: [:r | ...] ) being sent but not happening. The success script is > just not happening. > Is there a place I can insert a trace for the callback result code? > Although I would think that a bad callback result would show the same > symptom on a single gem configuration as well, which it does not. > Bob > On Monday, May 10, 2021, 03:16:15 p.m. EDT, jtuchel--- via Glass < > glass@.gemtalksystems > > wrote: > > Bob, > two questions out of the blue: > > - did you make sure the ajax request is a success in all cases (HTTP > 200)? > - sounds a bit like the submit event of a surrounding form might > sometimes get in your way. Is that possible? Are you sure it is not the > case? > > > > > Maybe both are completely pointless, just brainstorming > > > Joachim > > > > Am 10.05.21 um 20:21 schrieb Bob Nemec via Glass: > > > I've posted this question on the PharoJS Seaside forum and on > stackoverflow, asking about onSuccess: not working correctly after a > callback. In a text input field, if the user presses the [Enter] key we > run this code... > > html jQuery ajax callback: [:value | self doSearchWith: value] > value: html jQuery this value; > onSuccess: ((html jQuery id: 'fieldId') load html: [:h | ...div > to be rendered after search... ]) > > > The intermittent symptom is that the user enters a value, presses > [Enter]. The entered value reverts back to the previous value and the > search result does not change. At first I thought the problem was that the > onSuccess: script was being sent before the callback, but, after reading > the gem logs more carefully, the problem turns out to be that the > onSuccess: script is not run at all. The only place I run multiple web > servers is in our GS + HAProxy setup. There is never a problem with one > gem or in VW. > > If I add 'async: false' then the onSuccess: script always runs. But > while the callback is running, the user sees no feedback. For most user > actions I show a busy gif and a 10% opaque overlay. Neither of those work > with 'async: false' because all display rendering held up. > Any suggestions for how I can ensure a onSuccess: script runs after a > callback? > I understand that onSuccess: depends on the HTTP response code, but the > callback action is always successful. > Thanks for any help, Bob Nemec > _______________________________________________ > Glass mailing list > Glass@.gemtalksystems > https://lists.gemtalksystems.com/mailman/listinfo/glass > > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto: > jtuchel@ > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > > _______________________________________________ > Glass mailing list > Glass@.gemtalksystems > https://lists.gemtalksystems.com/mailman/listinfo/glass > > _______________________________________________ > Glass mailing list > Glass@.gemtalksystems > https://lists.gemtalksystems.com/mailman/listinfo/glass -- Sent from: http://forum.world.st/GLASS-f1460844.html _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Fixed the missing onSuccess: send by adding event.preventDefault(); to the [Enter] key press script. I should have done that when I first wrote the script. Bob
On Monday, May 10, 2021, 05:28:06 p.m. EDT, Paul DeBruicker via Glass <[hidden email]> wrote:
The onSuccess not being called should be a javascript error, not seaside as its jQuery in the browser that triggers it. Right? What happens if you replace your onSuccess: script with onSuccess: 'console.log("startSuccess");', aScript, 'console.log("endSuccess");'; ? What happens if you change it to onSuccess: ((html jQuery id: 'fieldId') load html: [:h | 1 halt ]) ? Can you always render the search result div or could it contain an error that messes up the onSuccess: javascript function? What version of jQuery are you running and have they fixed any bugs in it in any more up to date versions? GLASS mailing list wrote > Submit form conflicts were a problem in the past. I've replaced all the > buttons on that view with anchors that look like buttons in order to avoid > the enter key default action. But that is a good point: I'll double check > that I not missed one. > Here is a little bit more information... self onKeyPress: ( (JSStream > on: '(window.event ? window.event.keyCode : event.which) == 13') then: > (canvas jQuery ajax callback: aBlock value: canvas jQuery this value; > onBeforeSend: (JSStream on: 'console.log("onBeforeSend")'); onSuccess: > aScript; onComplete: (JSStream on: 'console.log("complete")'))) > ...using this code I always see the 'onBeforeSend' in the log, and the > callback is always triggered, but 'complete' is never displayed (I was not > using onComplete: ... just a curiosity). I also have console.log() code in > the onSuccess: script and it is consistent with the refresh rendering. > i.e. it is not a case of the (html jQuery id: 'divToBeRefreshed') load > html: [:r | ...] ) being sent but not happening. The success script is > just not happening. > Is there a place I can insert a trace for the callback result code? > Although I would think that a bad callback result would show the same > symptom on a single gem configuration as well, which it does not. > Bob > On Monday, May 10, 2021, 03:16:15 p.m. EDT, jtuchel--- via Glass < > [hidden email] > > wrote: > > Bob, > two questions out of the blue: > > - did you make sure the ajax request is a success in all cases (HTTP > 200)? > - sounds a bit like the submit event of a surrounding form might > sometimes get in your way. Is that possible? Are you sure it is not the > case? > > > > > Maybe both are completely pointless, just brainstorming > > > Joachim > > > > Am 10.05.21 um 20:21 schrieb Bob Nemec via Glass: > > > I've posted this question on the PharoJS Seaside forum and on > stackoverflow, asking about onSuccess: not working correctly after a > callback. In a text input field, if the user presses the [Enter] key we > run this code... > > html jQuery ajax callback: [:value | self doSearchWith: value] > value: html jQuery this value; > onSuccess: ((html jQuery id: 'fieldId') load html: [:h | ...div > to be rendered after search... ]) > > > The intermittent symptom is that the user enters a value, presses > [Enter]. The entered value reverts back to the previous value and the > search result does not change. At first I thought the problem was that the > onSuccess: script was being sent before the callback, but, after reading > the gem logs more carefully, the problem turns out to be that the > onSuccess: script is not run at all. The only place I run multiple web > servers is in our GS + HAProxy setup. There is never a problem with one > gem or in VW. > > If I add 'async: false' then the onSuccess: script always runs. But > while the callback is running, the user sees no feedback. For most user > actions I show a busy gif and a 10% opaque overlay. Neither of those work > with 'async: false' because all display rendering held up. > Any suggestions for how I can ensure a onSuccess: script runs after a > callback? > I understand that onSuccess: depends on the HTTP response code, but the > callback action is always successful. > Thanks for any help, Bob Nemec > _______________________________________________ > Glass mailing list > [hidden email] > https://lists.gemtalksystems.com/mailman/listinfo/glass > > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto: > jtuchel@ > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > > _______________________________________________ > Glass mailing list > [hidden email] > https://lists.gemtalksystems.com/mailman/listinfo/glass > > _______________________________________________ > Glass mailing list > [hidden email] > https://lists.gemtalksystems.com/mailman/listinfo/glass -- Sent from: http://forum.world.st/GLASS-f1460844.html _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |