Nick Pratt created WICKET-5747:
----------------------------------
Summary: Wicket Ajax Click handling gets requeued on OnDomReady so
fire out of order
Key: WICKET-5747
URL: https://issues.apache.org/jira/browse/WICKET-5747
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 6.17.0
Reporter: Nick Pratt
While debugging some jquery script ordering, we noticed the following and I'm
looking for views on why this is done and/or if it's a bug:
1. Wicket assembles all ajax click handlers and writes them out into a single
Wicket.Event.add(window,"domready" function(event) { .... script invocation
written in to the <head> element of the page.
2. For things like click handlers, Wicket writes out Wicket.Ajax.ajax( {"c":
"selection4e2", "u":".....", "m":"POST"}) calls that execute within the
onDomReady function defined in (1)
3. This invocation of (2) in turn invokes jquery( fn ); This requeues the
function invocation at the back of the jquery event queue for onDomReady
processing
4. Any custom scripts that we added using OnDomReadyHeaderItem, regardless of
where we put them on the page after the standard Wicket click handler JS, are
now invoked, according to page order.
5. The re-queued functions from (3) now execute after my custom scripts.
These custom scripts modify the DOM (table paging/filtering etc) and this
mechanism now results in JS errors since the functions fail to find the
required elements in the DOM
Is this re-queueing intentional, and is there a reason that we couldnt just
execute the click handler additions in step (1) rather than re-queuing the JS
call?
A workaround for this is to wrap all of our application JS functions in a
separate jQuery( ... ) invocation, so that we can requeue all of our functions
after all the requeued Wicket ones. It works, but we dont understand the need
for Wicket to perform this requeueing instead of just executing the function as
and where defined on the page.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
