[
https://issues.apache.org/jira/browse/WICKET-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Pratt updated WICKET-5747:
-------------------------------
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( {"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 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.
was:
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.
> 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 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
