Question Regarding: Only show validation errors if a field got focus #642

[fcjoe-gis]

During testing with the current main branch we notice that we do not see required fields when the FeatureForm loaded. I then notice in the history Only show validation errors if a field got focus#642. After rolling back to before this pull request I see the desired behavior has returned.

I am quite curious to understand the feedback you received that led to this change. I found the previous behavior a much better user experience and in communicating this change to users they seem to agree. Especially with a larger form the user wants to know which fields are required. Prior to this PR this was very clear. Could you please reconsider this change. Or at least give a flag the that could be set so they could have it show when the form loads

Thanks
-Joe

[dotMorten]

Thank you for the feedback! The thinking here is that when editing an existing feature, it can still be considered "invalid" according to the rules but still save-able in the sense that it doesn't break with the table schema. The problem is that if someone chooses to edit a feature with values that doesn't pass the validation requirements, it is confusing to get validation errors for fields you didn't even touch. You might only be interested in changing one value, but suddenly you can't apply that change without also dealing with other failures.

Does this help explain the reasoning? I'd love to hear the workflows you got and better understand it so we can look into adding more control here.

[fcjoe-gis]

Specific to required fields. A driver to using the FeatureForm is that I can define my form on the web and use that configuration on the form. One aspect is making fields required that may allow null values. This is critical.

I feel like this is removing an entire driver for the FeatureFormView. A key aspect was informing users of all the required fields on the form based on the configuration. Having the form not show required fields, now requires the user tap through every field on the form to determine if it is required. The user does not know they filled in the form completely until they Submit and get errors

The user knows they have filled in the form when all the required fields have been addresses (maybe not the best example because almost every field is required in this case)

I am not clear on the use case of someone wanting to have a form configured in the web map, but that then allows a user to save just based on the table definition ignoring the configuration.

[mstefarov]

We added a new setting on FeatureFormView in 200.8: ErrorsVisibility. Setting it to "Visible" shows all validation messages on all fields. Does this meet your needs?

[fcjoe-gis]

I have only done a little testing but this does not seem to be working as it did previously. In MAUI, iOS. The first time a feature is placed a required field does not indicate anything. Additional times that feature is placed the field shows required, but it does not get a red outline until the user click in the field.

First time feature is placed:

Following time feature is placed:

Tap into field:

    <esri:FeatureFormView x:Name="FeatureFormView" Background="Transparent" Padding="12" Grid.ColumnSpan="2"
                          VerticalScrollBarVisibility="Default"
                          FeatureForm="{Binding FeatureForm}" ErrorsVisibility="Visible"/>

I have another deployment which has more required fields I will test against, but that is a little more involved to setup.

The behavior currently observed will not allow us to upgrade

[fcjoe-gis]

So for some odd reason, the first time the form is being hydrated this method returns null

internal static FeatureFormView? GetFeatureFormViewParent(Element child) => GetParent<FeatureFormView>(child);

In this initial time .Parent is null on the FeatureFormElementView that is passed in. On subsequent times loading the form it behaves correctly in that it returns the FeatureFormView

[fcjoe-gis]

I created a PR that does seem to address the issues encountered. I am not sure this is the best implementation approach, but seems to be working

Added logic so that the error message and text box outline updates are displayed based on ErrorsVisibility #687

Thanks
-Joe