questions about serverCustom validators

[claudiobosticco]

SmartClient Version: SNAPSHOT_v13.1d_2024-09-06/Enterprise Development Only (built 2024-09-06)

Hello, please modify the FSdmiValidation sample like this:

isc.DynamicForm.create({
    ID:"testForm", top: 50,
    dataSource:"validationDMI_orderForm",
    fields: [
        { type:"header", defaultValue:"Add an item to your Order" },
        { name:"itemId", title:"Item", editorType:"ComboBoxItem", optionDataSource:"StockItem",
          valueField:"id", displayField:"description" },
        { name:"quantity", validateOnExit:true },
        { name:"instructions", editorType:"TextAreaItem" }
    ]
});

isc.IButton.create({
    title: "validate",
    autoFit: true,
    click: function () {
        testForm.validate()
    }
})

then, without choosing an item, type 999999 as a quantity, and press "validate". You'll see a validation request (due to the serverCustom validator for "quantity"), and a "Field is required" hover:


then, try the same sample in a different locale, in my case locale=it, and you'll see both the client (localized) message, and the server (not localized) message for the same validation error:



I just want to check with you if it's expected or is a bug or something that you plan to enhance in the framework. I suspect that this wouldn't happen if also server-side messages were localized.

Also I want to ask if stopIfFalse is meant to work also for serverCustom validators, ie if I had 2 serverCustom validators and the first has stopIfFalse, then the 2nd doesn't execute if the first fails. Currently it doesn't seem so.

[Isomorphic]

Hi Claudio, so what's happening here is that when you click your "Validate" button, that triggers validateOnExit (because focus has moved away from the field) so two validations are run.

The second validation, triggered by the explicit validate() call, is a whole-record validation, so the required validator gets run.

Then, the system has two errors from that validator, and we currently do not have a way to tell that they are from the same validator, except by matching the error message. So since the required validator does not have a localized error message, you see redundant messages.

In general, you do need to localize error messages for any custom validators you create. Typically, you do not need to bother to localize built-in validators that can run on the client, since the attempted save will be stopped at the client, so the server validator will never fail.

This flow, while pretty synthetic, is an example of where you might want to localize the server validator.

Another case would be if you are providing REST access to third parties and you want error messages to be in a non-English locale.

Note that we could enhance things so that built-in server validators are automatically localized, using the same language packs the client uses - that would be a valid Feature Sponsorship, which might save you time if your flows are hitting cases where built-in validators on the server are producing end-user-visible error messages.