Kendo components sometimes initialized with a local transport with JQuery 3

[reckart]

I am encountering a strange issue. I have some Kendo ComboBoxes which should normally load their data via an AJAX callback. When using the JQuery 2 reference in Wicket, this works nice. However, when switching to the JQuery 3 reference, in some cases, the dropdown shows just "no data" and the AJAX callback is never called. I have tried with Wicket Kendo/JQuery 8.3.0 as well as 8.6.1 (in conjunction with various Wicket versions).

Debugging in my applications shows that in the cases where the AJAX call is not triggered (and the "no data message" is displayed), the ComboBox gets its content from some datasource with a "LocalTransport".

I suspect there might be some timing issue / race condition that turns out differently with JQuery 3 than with JQuery 2. I was looking for (un)caught exceptions as well, but this didn't turn up anything.

I'm afraid, I don't have the time to build a standalone example showcasing this issue. But if somebody has an idea what kind of change between JQuery 2 and 3 might cause this issue or how to further debug the issue, please let me know.

[reckart]

Ok, so what happens with JQuery 3 is that the JavaScript header item which creates the datasource is created only after the ComboBox is initialized. Thus, during the initialization of the ComboBox, the data source on the window object is still undefined and a new empty data source with a local transport is created. If the page is reloaded or the element is refreshed using AJAX, then the datasource either initialized before the widget (on reload) or the data source has already been initialized previously (on AJAX refresh).

[reckart]

The datasource is initialized in a "header contribution" section of the AJAX request which puts the ComboBox onto the page. The ComboBox itself is initialized in a "priority evaluate".

[reckart]

Both, the JS which initializes the data source and the one which initializes he ComboBox are wrapped in a jQuery(...) call:

    jQuery('#featureEditorHead1981').kendoComboBox({
        "template": jQuery('#featureEditorHead1981_template').html(),
        "dataTextField": "text",
        "autoBind": true,
        "dataValueField": "value",
        "dataSource": window.featureEditorHead1981_datasource
    });

jQuery(function() {
    window.featureEditorHead1981_datasource = new kendo.data.DataSource({
        "dataType": "json",
        "transport": {
            "read": "./annotation.html?8-.1-rightSidebar-annotationDetailEditorPanel-annotationFeatureForm-featureEditorsContainer-featureValues-2-editor-value"
        },
        "error": function(xhr, error) {
            var dw = Wicket.Ajax.DebugWindow;
            if (typeof dw !== 'undefined') {
                dw.logError(kendo.stringify(xhr));
            }
        },
        "sync": function() {
            this.read();
        }
    });
});

According to the documentation of JQuery, jQuery(function x) executes function x when the DOM is ready. So it looks to me like the order in which multiple queued jQuery(...) calls are executed differs between JQuery 2 and JQuery 3, causing the initialization order to be wrong with JQuery 3.

[reckart]

Aha - so it looks to me as if the Wicket Kendo ComboBox and other widgets using header-based datasources are not compatible with JQuery 3 in general because...:

... in JQuery 3: Breaking change: document-ready handlers are now asynchronous

(Source: https://jquery.com/upgrade-guide/3.0/#breaking-change-document-ready-handlers-are-now-asynchronous)

I think this means we now know why it breaks, but the question is: how to fix it? It doesn't seem to be an issue in either Kendo, JQuery or Wicket itself, but in fact in the way that the Wicket Kendo integration initializes data sources and widgets.

[sebfz1]

Hi Richard, thank you so much for your investigation!!

I was not aware of the async of dom-ready event in jQuery 3!

How to fix it? Well my first thought is to see if we can play with async/await or $.ajax().done()...

[sebfz1]

Erratum, $.ajax().done() might not be very useful in that case....

On Thu, Oct 10, 2019, 14:34 Sebastien sebfz1@gmail.com wrote:

Hi Richard, thank you so much for your investigation!!

I was not aware of the async of dom-ready event in jQuery 3!

How to fix it? Well my first thought is to see if we can play with async/await or $.ajax().done()...

[reckart]

@sebfz1 are we still limited to using Kendo/JQuery wicket with JQuery 2?

[sebfz1]

Hi Richard, I would say "yes, probably". I will have a look asap.

[thaitzer]

Well since jquery 2 is EOL since 2017 and has known vulnerabilities, this means for us, that we have to find a replacement for this library!

[sebfz1]

I will try to conduct some tests this weekend...

[sebfz1]

Very sorry for the incredible delay in handling this issue!

As you know, I was not able to reproduce the issues on any of the components mentioned in this thread... Still, I think I could manage the data-source dependency order properly by rendering it using the OnDomReadyHeaderItem, just before the widget itself. The data-source object is still attached to the window object/scope because the widget can be detached/re-attached and needs to be able to find it.

I just published 9.6.0-SNAPSHOT, please give it a try and let me know. If you encounter an issue (like a side effect for instance) please try to reproduce in a quickstart. I'm also keen to know if it works well if the data-source is shared between several widgets...

[reckart]

@sebfz1 Where did you publish to? Seems like Sonatype OSS SNAPSHOT doesn't have the artifacts (yet?):

https://repository.apache.org/content/repositories/snapshots/com/googlecode/wicket-jquery-ui/wicket-jquery-ui-parent/9.6.0-SNAPSHOT/maven-metadata.xml => 404

[reckart]

Never mind - looks like the Maven CLI build managed to obtain the snapshots now...

[sebfz1]

Snapshots are published on Sonatype OSS Snapshot repository: https://oss.sonatype.org/content/repositories/snapshots/com/googlecode/wicket-jquery-ui/wicket-jquery-ui-parent/9.6.0-SNAPSHOT/maven-metadata.xml

[reckart]

I upgraded to the SNAPSHOT and set Wicket to use JQuery 3. A first little try with a ComboBox looks ok, but re-reading the initial issue, it seems the problem did appear randomly. So I'll keep an eye out and see if it comes up over the next days...

[reckart]

@thaitzer if you have the opportunity, would be great if you could test as well.

[thaitzer]

In the end, what fixed it for me, was not using the javascript defer header item from apache wicket. No problems once I removed that.

[reckart]

@thaitzer so did you try with the snapshot?

[thaitzer]

@thaitzer so did you try with the snapshot? in short - sorry - no.

For me the release version is working with JQuery 3 without any issues once I removed the JavaScriptDeferHeaderResponse from my wicket application.

Do you want me to try with defer header and the snapshot?

[reckart]

@sebfz1 so, so finally... I configured Wicket to roll out JQuery 3 and kept the eyes open for a situation where the combobox dropdown would not populate with Wicket JQuery UI/Kendo 9.5.0. It tested switching between 9.5.0 and 9.6.0-SNAPSHOT in this situation and can say that with 9.6.0-SNAPSHOT, the dropdown populates properly.

Sorry for the delay, but it took me a while to spot a reproducible situation.

[reckart]

@sebfz1 when you find the time for a new release: Wicket 9.7.0 is out as well.

[sebfz1]

Released wicket-jquery-ui-9.6.0.
I'll try to release 9.7.0 asap...

[reckart]

Thanks and welcome in 2022!

[sebfz1]

Released wicket-jquery-ui-9.7.0 (with kendoui.2021.3.1207). Happy New Year too! :)