Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
6.17.0
Description
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(
) 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 Wicket JS errors since the Wicket click handler binding 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.
Attachments
Issue Links
- is related to
-
-
- Resolved
-