[
https://issues.apache.org/jira/browse/WICKET-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214723#comment-14214723
]
Nick Pratt edited comment on WICKET-5747 at 11/17/14 3:16 PM:
--------------------------------------------------------------
Is there a reason why we couldn't execute those standard Wicket JS handlers
directly during invocation of the
Wicket.Event.add(window, "domready", function(event) { ... }
method so that all events contained therein fire in the order as laid out on
the page (assuming we could detect that we were running inside the jquery
domready function?
was (Author: nickpratt):
Is there a reason why we couldn't execute those standard Wicket JS handlers
directly during invocation of the
Wicket.Event.add(window, "domready", function(event) { ... }
method so that all events container therein fire in the order as laid out on
the page (assuming we could detect that we were running inside the jquery
domready function?
> 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)
