Ensure min/max property editor settings are valid before rendering for content editing

[AndyButland]

Prerequisites

• I have added steps to test this contribution in the description below

Fixes #17509, tracked under AB 47508 (internal HQ tracker).

Description

The issue raises the point that it's possible to save invalid combinations of min and max values when configuring data types with various property editors.

This PR isn't a full fix for the issue. With the changes in place, the invalid values will still be saved. But with this PR merged we'll convert invalid pairs of values to valid ones before rendering them for content editing, and throw an error visible in the browser console indicating the problem.

This is the same pattern followed on a couple of other property editors, such as the slider.

A better fix would be to have some validation available on saving data type configuration, where we could provide custom code for each to validate across the configuration values. But it doesn't look like we have a good solution for that yet - unless I've missed it, but couldn't see use cases - and so this would likely be something to tackle as a feature.

To Test:

• For the numeric, multi URL and text area property editors, create data types with invalid combinations of min/max values (i.e. min > max).
• When using the data types in content editing, verify that a working property editor is rendered and a console error is thrown.

[iOvergaard]

Great work, @AndyButland. I am wondering if this shouldn't be a task for the input component to verify rather than the property editor? My thinking is that you could be using the input element directly elsewhere and you wouldn't get any validation of the inputs.

If we look at the <umb-input-multi-url /> as an example, it sets the min and max up through a range validator:

		this.addValidator(
			'rangeUnderflow',
			() => this.minMessage,
			() => !!this.min && this.urls.length < this.min,
		);
		this.addValidator(
			'rangeOverflow',
			() => this.maxMessage,
			() => !!this.max && this.urls.length > this.max,
		);

In my mind, it would be perfectly reasonable to "activate" the validator if the conditions are invalid, i.e. if min > max then there is a rangeOverflow thus displaying the validation error and refuse to submit.

An alternative could be to implement an _errorMsg as a state and display that with a red text color - this could also be done in the input element rather than the property editor.

What are your thoughts towards this?

[AndyButland]

Does sound like it would be better. I copied this pattern from an existing property editor that did similar - property-editor-ui-slider.element.ts - but perhaps there too we could fix in a similar way rather than how it's currently done. I'll have a look to see if I can make it work along the lines you suggest.

[nielslyngsoe]

Great to see some activity on this matter, @AndyButland

Adjacent to what @iOvergaard writes about, then notice for a Property Editor UI to consider an inner element, like an Input. it needs to be bind.

It can be done in this way, as code of the Property Editor:

	override firstUpdated() {
		this.addFormControlElement(this.shadowRoot!.querySelector('umb-input-number-range')!);
	}

So you have to actively bind Elements to the validation system. In this case the Property Editor UI is bound already, but the implementation needs to define wether the inner element should be taking into account.

Doing so will also make the inner validation message bobble up to the Property Editor and thereby display the message in a red text. So Ideally it should never be necessary to display validation texts on your own.
Well, it depends, cause an editor like the Block Grid Editor does have inner Validation System implemented, but for the simpler Editors it should not be needed.

— I can also hear this would be good to document, but also please respect that such would take some time, so I will postpone that further, there is a document on the very technical side of things here, but that is also very much only related to if you want to implement the system n your own, so not relevant for Property Editors.
src/packages/core/validation/README.md

Thanks for your attention

[nielslyngsoe]

disapproving again (was testing something regarding github)