[
https://issues.apache.org/jira/browse/WICKET-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Pratt updated WICKET-5747:
-------------------------------
Summary: Wicket Ajax Click handling gets requeued in OnDomReady so fire out
of order (was: Wicket Ajax Click handling gets requeued on OnDomReady so fire
out of order)
> Wicket Ajax Click handling gets requeued in 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
> Labels: ajax, javascript
>
> 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)
