[Feature] TextBoxRegex should use the BeforeTextChanging event

[jp-weber]

Currently, the characters are checked for validity after they have been entered and set. Therefore, there are various events that currently have to be used to validate the entries for the various modes and to delete them if necessary.
The problem that arises here, especially with the ValidationMode Dynamic, is that non-valid entries are set and then deleted again.

Describe the problem this feature would solve

With the use of the BeforeTextChanging event, the values of the input are validated before the input is set and, with the ValidationMode dynamic, these are discarded if the input is not valid.

With this change, you could remove checks on the get and setters that catch invalid queries that would currently have been removed only after the first set.

[ghost]

Hello, 'jp-weber! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[michael-hawker]

Thanks @jp-weber. This is an interesting scenario.

The original purpose of this extension was to help with field validation. So for instance checking an e-mail address adhered to some light-fuzzy semblance of an e-mail or a phone number. Sometimes those are invalid until the final character is typed, so if you invalidate all the input before the user has finished typing the text, then they'd never be able to input the data.

I think we need to understand how these scenarios work with the different validation modes vs. special casing looking at particular ValidationType?

Can you elaborate on the user scenario you're using this feature on? That'd be helpful to know.

It may be helpful as a first step to add UI interaction tests for the feature and define behaviors for what we expect in certain cases (like copy-paste in particular that you found).

Then it'd be easier to update with new behavior that expects how we want this to function? We're fine with making behavior changes for 7.0 as it's a major release. I just want to make sure we're explicitly figuring out what we want that behavior to be. 🙂

You up for helping us figure out a more detailed set of scenarios here and potentially adding some tests around this feature to make it more robust for the future?

[jp-weber]

@michael-hawker

I think we need to understand how these scenarios work with the different validation modes vs. special casing looking at particular ValidationType?

Originally there were only the validation modes normal and force. Normal only validates the entered text, the force mode validates the entered text and deletes the entry if it is not valid when the focus is left by the textbox. With the implementation of the dynamic mode, my original idea was to discard inputs directly if they are not valid. Due to the fact that entries that are not valid are deleted, complicated rules such as e-mail entries cannot be implemented with the dynamic mode.

At this point we would have to explain in more detail that the dynamic mode can only accept simple regex rules. Because as the input as a whole can only become valid through further entries.

The use of the dynamic mode is intended to prevent non-valid entries from being set for an entry (non-valid entries are deleted).

Can you elaborate on the user scenario you're using this feature on? That'd be helpful to know.

Using the BeforeTextChanging event does not change anything for the user in the normal and force validation modes.

What changes for both is the time at which the validation happens. Previously, the input was set to the variable and then validated. With the BeforeTextChanging event, the input is first validated and then set.

For the dynamic mode, this has the advantage that invalid entries can be discarded directly and do not have to be deleted after being set. Another advantage of the dynamic mode is that if non-valid entries are made, checks in the getter and setter are no longer required.

Due to the construction of the old version, non-valid character strings, where only trailing characters are not valid, can be deleted by inserting them into the textbox with the validation mode dynamic and thus a valid input can be achieved.

If, for example, only characters are accepted in the field and the input is:
123abcd123 => the whole text is deleted
abcd123 => only 123 is deleted

With the BeforeTextChanging event the input is discarded in this example.

It may be helpful as a first step to add UI interaction tests for the feature and define behaviors for what we expect in certain cases (like copy-paste in particular that you found).

Then it'd be easier to update with new behavior that expects how we want this to function? We're fine with making behavior changes for 7.0 as it's a major release. I just want to make sure we're explicitly figuring out what we want that behavior to be. 🙂

You up for helping us figure out a more detailed set of scenarios here and potentially adding some tests around this feature to make it more robust for the future?

If I can find time for this, I would love to do it.

[michael-hawker]

@jamesmcroft I had pinged you over here, but just wanted to pick your brain on some of the overarching scenarios here so we can define some expected behavior.

We have our interaction and visual unit testing frameworks setup, so @jp-weber if we can basically make a spec and implement tests for how we expect things to work, then it should be a lot easier for us to make updates/improvements to the existing behavior (or add new modes for these new scenarios).

If we don't make breaking changes we can put this in 7.1, otherwise wait for an 8.0 and do an overhaul.

Thoughts?

[jp-weber]

Thanks for highlighting the pull request @michael-hawker. I've had a lot on my plate lately and haven't been able to look into it further. The days when I have time again I can implement the unit tests with the cases and define the expected behavior. @jamesmcroft you can look over the finished cases, whether this then fits so.

[michael-hawker]

@jp-weber moving this to our next milestone. Let us know when you can get back to it. Just want to make sure we validate how this effects the user experience for folks that are using it and upgrade. Thanks!