WIP: sends table widget data on each ajax form submit

[der-On]

Instead of sending data of a table widget only on a certain ajax handler (default onSave) the table widget now sends data on every ajax form submit.

What problem does this PR solve?

When having a translatable datatable widget data get's lost when switching locales.

In this example I show the current behaviour:

1. We have the table in the "de" locale:

2. We switch to the "en" locale, an ajax request with the handler formProperties::onSwitchItemLocale is send, however the table will only handle the onSave handler by default:

3. We switch back to the "de" locale and all data is lost:

How does this PR solve the problem?

By handling any ajax request handler the form data is preserved for each locale.

However this means datatables that are within forms that also allow other ajax handlers and must not handle those a specifique postbackHandlerName must now be added to the field config of the datatable to only listen to those ajax requests.

[der-On]

This PR yet does not contain the newly compiled JS files.

[github-actions]

This pull request will be closed and archived in 3 days, as there has been no activity in this pull request for the last 6 months.
If you intend to continue working on this pull request, please respond within 3 days.
If this pull request is critical for your business, please reach out to us at [email protected].

[der-On]

@LukeTowers Is this PR still "required" or desired to be merged?

[bennothommo]

It is, but right now my priorities are on the marketplace. I will circle back to this when I have time.

[LukeTowers]

@der-On @bennothommo what's the status of this PR?

[bennothommo]

The PR works as described, however, it might be considered a BC break for the table widget behavior since now the table data is included with every AJAX request, not just the specified AJAX event.

I also think it will cause some issues for the Builder plugin, mainly on pages where there are other AJAX actions on the page besides the saving of data.

I'd be inclined to block this PR for the moment until we can ensure that the Builder plugin won't be affected.

[LukeTowers]

@der-On are you interested in testing this change with the builder plugin so that we can move forward with merging it?

[der-On]

@LukeTowers I will try. Please assign it to me, so I do not loose it.

[der-On]

@bennothommo I've tried to test the builder, but that one seems broken currently.

Uncaught TypeError: can't access property "hide", $(...).data(...) is undefined
    makePluginActiveDone http://localhost/plugins/winter/builder/assets/js/build-min.js?v2.0.6:76
    jQuery 8
    Request http://localhost/modules/system/assets/js/framework.js?v=1.2.6:438
    request http://localhost/modules/system/assets/js/framework.js?v=1.2.6:505
    makePluginActive http://localhost/plugins/winter/builder/assets/js/build-min.js?v2.0.6:73
    applyPluginSettingsDone http://localhost/plugins/winter/builder/assets/js/build-min.js?v2.0.6:70
    cmdApplyPluginSettings http://localhost/plugins/winter/builder/assets/js/build-min.js?v2.0.6:65
    jQuery 8
    Request http://localhost/modules/system/assets/js/framework.js?v=1.2.6:438
    request http://localhost/modules/system/assets/js/framework.js?v=1.2.6:505
    cmdApplyPluginSettings http://localhost/plugins/winter/builder/assets/js/build-min.js?v2.0.6:64
    invokeCommand http://localhost/plugins/winter/builder/assets/js/build-min.js?v2.0.6:36
    triggerCommand http://localhost/plugins/winter/builder/assets/js/build-min.js?v2.0.6:493
    onCommand http://localhost/plugins/winter/builder/assets/js/build-min.js?v2.0.6:539
    jQuery 10
    <anonymous> http://localhost/modules/system/assets/js/framework.js?v=1.2.6:688
    <anonymous> http://localhost/modules/system/assets/js/framework.js?v=1.2.6:716
build-min.js:76:30

[bennothommo]

@der-On what's the context? Which table?

[der-On]

@bennothommo I've opened the main page of the builder plugin, created a Test plugin using it and after that I get this error. I get the same error when clicking on the button to show me the existing plugins. At this point this PR was not merged.

[der-On]

I will retest it again with current dev versions as this is pretty urgent for us.

[der-On]

@bennothommo I get the same result with current dev-main version of the builder. The builder plugin seems to be partly broken in it's current state. I however was able to add tables and columns using the builder plugin with this PR applied.

[bennothommo]

@der-On have you tested this with a fresh install of Winter and the Builder plugin, with just your PR's changes applied?

[der-On]

@bennothommo Will try with fresh winter without translate plugin.

[LukeTowers]

@der-On any updates on this?

[der-On]

@LukeTowers @bennothommo I've now found the time to test it against a fresh install of winter with dev-develop and builder plugin on dev-main. Builder seems to work but when creating model list definition I get the following error with my change:

this.cachedModelFieldsPromises[modelClass].done is not a function and endless recursion if hitting "add database columns".

Will investigate on this to find a workaround.

[der-On]

@bennothommo @LukeTowers I found a solution with a small fix to the PR and the builder. I've also edited the PR description to better describe the problem.

If no postbackHandlerName is set on a datatable it will update on each ajax request. However if a postbackHandlerName is defined on the table widget it will only update on that.

In the builder plugin I needed to add the following to plugins/winter/builder/classes/modellistmodel/fields.yaml:

tabs:
    stretch: true
    cssClass: master-area
    fields:
        columns:
            stretch: true
            cssClass: frameless
            tab: winter.builder::lang.list.tab_columns
            type: datatable
            postbackHandlerName: onModelListSave # <- this will ensure the table is only submitted on this handler