Project

General

Profile

Actions

Feature #7986

closed
RS RM

Consider optimizing updates by only changing changed form values?

Feature #7986: Consider optimizing updates by only changing changed form values?

Added by Roel Standaert over 5 years ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
01/19/2021
Due date:
% Done:

0%

Estimated time:

Description

On every signal all form data is submitted to the server, even form data that hasn't changed since the last signal. Maybe we could make it so that only updated form data is sent, and not all form data.

Special care will have to be taken for situations where absence of form data has a particular meaning, e.g. no values for WSelectionBox means no selection. In that case we could encode it as an array instead? Since WSelectionBox is supported when JavaScript is disabled, the old behavior should still work.

Apart from making the signals a bit smaller this may help in situations where many signals are being sent very quickly, causing the server side value of some widgets to be temporarily reset to their old value.

Suppose an update from the server changes the selected item in a WComboBox, but before that update was received and processed by the browser many events occur. These events will still have the old item selected. The effect will be that the current selected item of the WComboBox temporarily switches back to the old value after being changed, to then settle to the new value once a signal from the client comes in after the client has updated its value.


Related issues 1 (0 open1 closed)

Related to Bug #14496: WSuggestionPopup selection lost on next request when cache-form-data is enabledClosedRomain Mardulyn04/28/2026

Actions

RS Updated by Roel Standaert over 5 years ago Actions #1

Note: we'd also have to take note of all of the form values after every server update, so we can catch the situation where the server changes something and the user changes it back to the old value.

KD Updated by Korneel Dumon over 5 years ago Actions #2

I think the race condition can still occur. If the formwidget value in the client changes rather than stay the same, then the server will still get the wrong value.

RS Updated by Roel Standaert over 5 years ago Actions #3

Hence I said "may help". I think that's the more uncommon case, and we can't really (or at least easily) avoid a race condition in that case.

RK Updated by ruben kindt almost 5 years ago Actions #4

  • Assignee set to ruben kindt

RS Updated by Roel Standaert almost 4 years ago Actions #5

  • Assignee deleted (ruben kindt)

RM Updated by Romain Mardulyn about 1 year ago Actions #6

  • Status changed from New to InProgress
  • Assignee set to Romain Mardulyn

RM Updated by Romain Mardulyn about 1 year ago Actions #7

  • Status changed from InProgress to Review
  • Assignee deleted (Romain Mardulyn)

RM Updated by Romain Mardulyn 6 months ago Actions #8

  • Target version changed from future to 4.13.0

MV Updated by Matthias Van Ceulebroeck 5 months ago Actions #9

  • Assignee set to Matthias Van Ceulebroeck

RM Updated by Romain Mardulyn 5 months ago Actions #10

  • Status changed from Review to Implemented @Emweb
  • Assignee changed from Matthias Van Ceulebroeck to Romain Mardulyn

RM Updated by Romain Mardulyn 4 months ago Actions #11

  • Status changed from Implemented @Emweb to Closed

RP Updated by Raf Pauwels 4 months ago Actions #12

  • Related to Bug #14496: WSuggestionPopup selection lost on next request when cache-form-data is enabled added
Actions

Also available in: PDF Atom