Cool, thanks for the update!
Sven
On 23.01.20 20:19, Entropy wrote:
Okay, nevermind. I solved that by using a MutationObserver in javascript to
look for the thing Wicket makes visible or not and invoke my javascript as
needed.
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-for
Okay, nevermind. I solved that by using a MutationObserver in javascript to
look for the thing Wicket makes visible or not and invoke my javascript as
needed.
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
--
I just tried that and in terms of timing, it's perfect! However, my
front-end guys put together a multi-piece veil that blocks input, displays
our spinny, but also does some accessibility stuff and focus stuff that they
consider important. I'm going to go talk to them and see if they can live
wit
Hi,
sorry, I thought you know that detail:
If a behavior or any of the components in the hierarchy implements
IAjaxIndicatorAware, it can specify the id of a markup to be shown
during Ajax processing:
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/aj
Sven,
I'm afraid I don't know what you mean. Our real jQuery expert quit abruptly
and hasn't been replaced yet, so I'm sorry if this is a jQuery thing, but
your last two paragraphs don't make sense to me. What is attrs.i? It's not
on the object from what I see in the F12 tools. There's alot of
You're right, the Ajax response isn't available in the done callback.
Regretfully I can't remember how I solved the same issue in one of my
last projects.
But have you thought about utilizing the default Ajax indicator?
You could set attrs.i in AJAX_CALL_BEFORE and let Wicket show that
markup
And I should add that the third parameter, which the docs imply is the jqXHR
object, which is where I would expect the response to be, is null in these
callbacks. i tried subscribing to the /ajax/call/success handler as well
and it was null there.
--
Sent from: http://apache-wicket.1842946.n4.nab
That sounds great. But as I look through the jqEvent and attributes objects
I don't see what element is the response headers.
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
-
To unsubscribe,
On Tue, Jan 21, 2020 at 11:59 PM Entropy wrote:
> That seems promising. If you could look how you did it in your other
> project
> that would be great. I suppose if I could get access to the response XML I
> could look for the redirect in that. I'm not sure where it is though or
> even if it's
Hi,
I know this is not bulletproof but I always add a timeOut to hiding the
veil, usually 300, 400 milliseconds, so that there is some margin for AJAX
request to finish. Also some AJAX requests are so fast that veil + almost
not visible. spinner is
On Tue, Jan 21, 2020 at 11:59 PM Entropy wrote:
That seems promising. If you could look how you did it in your other project
that would be great. I suppose if I could get access to the response XML I
could look for the redirect in that. I'm not sure where it is though or
even if it's provided to this event.
--
Sent from: http://apache-wicket
Hi Entropy,
the trick is do keep the veil up whenever a redirect happens as the
result of an Ajax request.
Similar to what wicket-ajax-jquery.js is doing with it's Ajax indicator:
if (attrs.i && context.isRedirecting !== true) {
Wicket.DOM.h
In our app we display a veil after any button click that goes to the server
to prevent users double-submitting. Which they do. Alot. Double-submits
cause a variety of mischief for us ranging from StaleObjectExceptions in
hibernate to wicket exceptions about buttons not being enabled and others.
13 matches
Mail list logo
