Add form-level validation summary

[gregmac]

If a server-side error is added using

ModelState.AddModelError(String.Empty, "Generic error submitting this form");

There is currently no "built in" way to display it. MVC's ValidationSummary helper works, but it's strange to mix with ChameleonForms (and I believe with two forms on one page, it breaks).

There are several reasons to have overall form validation:

• Generic exception/error handling
• Server-side security failure (eg: User doesn't have permission to save with the specific values entered)

There is a trello task for this but with no detail: https://trello.com/c/1XFS1dHq/157-html-validationsummary-that-doesn-t-suck. In particular:

• Define "Doesn't suck"
• Is there any insight into how this should be done?

eg:

@using (var form = Html.BeginChameleonForm())
{
    using (var section = form.BeginSection("Errors"))
    {
        @section.ValidationSummary();
    }
}

• How is the section rendered if there are no validation errors to show?
• Is there a way to suppress the section if there are no errors (eg, using something like if (form.ValidationErrors.Count > 0) or form.BeingSection("Errors", hideIfEmpty:true); )? I'm not sure what the "ChameleonForms" way to do this..
• Should summary validation display only the non-field-specific errors, or should it also be able to display field-specific ones (like the MVC ValidationSummary helper can)?

[robdmoore]

Nice! Thanks for this issue - it's a great conversation starter :)

I like where you are heading and your reasoning. Definitely have a few ideas of my own to add to the mix.

There are two things in particular that I think "suck" about the built-in method - firstly, there is no way to easily hide it if there are no errors and secondly, there is no way to control the HTML output. Now, a nice thing is it does support population from the unobtrusive JavaScript errors on the page, so changing the HTML markup may well break that (something to investigate).

I'd like to see a way to output it in a way that (optionally?) still works with the unobtrusive JavaScript, but hides the message you configure if the form is valid. It might be nice to be able to output a message if the form is valid (not sure how that would work in with the JavaScript). We might need to extend the unobtrusive validation JavaScript to get it all working, but that's pretty easy (we already have an example of that anyway with the date format validation).

I'd also like to see the HTML output configured from the Form Template; this makes sense in the context of something like Bootstrap where you might want to use, say, a danger alert etc.

In terms of how the Razor should look, I don't think it makes sense to put it in a section (maybe in the leading HTML for it though? That would only make sense if you had a single form section). I think it should just be a call that returns an IHtmlString so it can be placed anywhere. For that reason it probably makes sense on the form object.

@using (var form = Html.BeginChameleonForm())
{
    @form.ValidationSummary()
    @* ... *@
}

I guess that raises a question - should there be an ability to create a summary for a subset of the fields? It's more complex, but might be useful? Might get a bit unwieldy to do though unless there is a way to detect calls to @s.FieldFor(...) and have that process before the @leadingHtml is output - from memory it's possible that's what Razor would do... hmm...

[gregmac]

Great, glad there is interest in this!

To stay focused, I think it's probably worthwhile to simply support the high-level validation (messages not attached to any specific field), and then once that's working, in other tickets:

• look at optionally having a summary of all field-level validation errors (which IMHO really only makes sense on very long, complex forms)
• look at section-level validation summaries that include just the fields in those sections (or something similar to get the "subset of fields summary" you described).

To me, the inability to display the validation problems that aren't field-specific is a missing capability. The other two are display enhancements that can potentially improve UX, but don't change any real functionality.

[robdmoore]

Agree. Sounds good.