[HxInputBase] Allow for CustomValidation Context and Propety and Add LabelType into application-wide Defaults

[mmonteagudo]

• Adds the EditContext, ValidationFor and ValidationForFieldName (as implemented in HxValidationMessage) in order to have built-in custom validation in all Input components
• Adds LabelType as an option in the InputBase.Defaults to set application-wide LabelType for Input components that apply.

[mmonteagudo]

I already have the code updated, but I can't push the contribution or even create the PR, let me know how can I help I forked the repo and Created a PR

https://github.com/havit/Havit.Blazor/pull/873

[hakenr]

Hello @mmonteagudo,

I like the new LabelType settings. I'll just polish the resolution cascade to align with the other parameters.

Could you provide an example scenario where you would take advantage of the new ValidationXy parameters?

[mmonteagudo]

I want able to provide it for the examples in the code, but in my case I'm using it for Validating using FluentValidation when validating values that are not parameters, for example in my case:

One if my properties in my project is ApplicationData which is a Dictionary, and I need to validate when one for the items in the dictionary has an specific value as a condition to validate all others, as default validation only works with properties, that's not possible, so in this in case I declared in Fluent Validation a "custom property to validate" and I'm matching that property (in this case equals to the dictionary key)

So, basically I'm sending to Fluent a custom property name to validate.

Hope the explanation helps, here are some code examples where I'm using the implementation

[hakenr]

Hello @mmonteagudo, I revisited your scenario and from my perspective, the main issue you're trying to resolve is:

• You're binding to dictionary items, which is inherently tricky, and you're using a custom ValueChanged callback to capture the value and save it to the dictionary.
• You want to combine this with the built-in HxValidationMessage and convince the input component to display the validation message for an artificial property.

From my point of view, your approach works, but it feels like a bit of a hack to solve a very niche scenario. Maintaining such a specific implementation might bring more complexity than the value it offers.

My suggestion for anyone facing a similar situation would be:

1. Try to avoid binding to the dictionary. Instead, create a ViewModel with properties for each individual item.
2. If you absolutely need to handle a dynamic model structure, use ValidationMessageMode="ValidationMessageMode.None" and manually add your own <HxValidationMessage .../> to the form.
3. In larger projects, you can derive project-specific components and override InputBase.BuildRenderValidationMessage() to add any necessary customization, including overriding parameters passed to HxValidationMessage with your own values (like ValidationForFieldName).

For now, I've decided not to accept the idea of adding the ValidationFor, ValidationForFieldName, and ValidationEditContext parameters to HxInputBase (i.e., to every input component).

However, I do like your idea of having a central place to set the default LabelType for all input components, and I'll try to finish that based on your PR (I'll revert the validation-related changes and fine-tune the LabelType idea).