[Solved] TextBox seems to be the only control that shows green "edited" border, other controls do not?

[Rob]

I love the feature, helps users know what they edited before saving changes, BUT ... it seems this "was edited" feature doesn't apply to many other controls like DropDownList, MultiSelect, CheckBox.

Am I stuck "as is" or is there something I can apply to make this UI feature work with other Telerik controls?

[Dimo]

Hello Rob,

All our Form components render a k-valid CSS class that you can use to apply a green border with custom CSS:

https://blazorrepl.telerik.com/wgaqHYOq34lsScUC21

There are two important things to keep in mind:

• Positive validation UI is normally used for specific purposes like password strength. It is not necessary to use it always.
• The rendering of k-valid depends on two things:
  • The EditContext must have fired OnValidationStateChanged.
  • There must be no validation messages for the respective model property.
    

The above EditContext API and algorithm can lead to false positives. If validation has occurred for one model property, all the others may appear as valid while still empty and not valid. The above REPL test page demonstrates this - type something in a textbox and all other components will light up as green, which is not correct. We can't call Validate() on the EditContext initially, because this will validate all inputs, which the user has not touched yet and this may not be desired. However, you can do that yourself if you like. Otherwise, if you want to use green borders, you need some more advanced custom logic that takes into account the current Form values.

All the above considerations explain why we don't use green borders by default.

Regards,
Dimo
Progress Telerik

[Rob]

 

--kendo-color-success

This is not defined in my solution?

Understand "normal" use case, but for my users the green box would represent data they have edited.  They are frequently working on multiple activities and might be in the middle of updating some data and get districted and return a few minutes later to finish the update.  Having a green border around the "edited" data refreshes their memory of what they already edited and where to resume.

I have done some custom logic (setting up editContext field changed handler, but it's more work than I would like to do especially since it appears some of the work is already there native to "some" of your controls.

But my original question is why does this "built-in" k-valid NOT work on dropdownlist, checkbox, etc.   The green border will trigger on any TextBox when user edits (regardless of validator or not) so long as the model is defined for the EditContext and bound to the control. 

The dropdownlist is bound (@bind-value) to the model property that is defined for the EditContext, yet when the user selects/edits in the dropdownlist, nothing happens to the controls border (aka doesn't turn green).  I don't understand why we have such inconsistency?  

[Dimo]

>> --kendo-color-success is not defined in my solution?

This means one of the following:

• The app is using a Telerik UI for Blazor version that is older than 6.0.0.
• The CSS theme is outdated and doesn't match the Telerik UI for Blazor NuGet package version.
• The app is using a Telerik CSS theme that is cached by the browser.

>> for my users the green box would represent data they have edited.

This means that the approach that I suggested is not suitable. Instead, subscribe to EditContext.OnFieldChanged through the Form component reference and apply custom CSS classes on the <FormItem> components.

https://blazorrepl.telerik.com/QquBabug46PWwilw37

>> why does this "built-in" k-valid NOT work on dropdownlist, checkbox, etc

I can't be sure without knowing your Telerik UI for Blazor version and without seeing the issue in action, but there are two assumptions that you can verify:

• The k-valid class is not applied to some components, for example, if you are using an older product version that renders different CSS classes.
• The required CSS styles do not target some components. Note that we do not wish for this to work by default anyway. Versions 5.x had this "feature" by accident and we removed it afterwards.

 

[Rob]

We're using Telerik UI Blazor 13.3.0.

CSS theme is matched to the Telerik Blazor NuGet package per _Host.cshtml

@page "/"
@using BlazorApplicationInsights;
@using Microsoft.AspNetCore.Components.Web
@using Microsoft.AspNetCore.Mvc.TagHelpers
@using Telerik.Blazor.Components
@namespace Toms.Pages
@* Telerik Cache Busting  *@
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
@{
    var telerikUiForBlazorVersion = typeof(TelerikRootComponent).Assembly.GetName().Version;
}
<!DOCTYPE html>
<html lang="en">
<head>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <base href="~/" />
    <component type="typeof(ApplicationInsightsInit)" render-mode="ServerPrerendered" />
    <link href="_content/Telerik.UI.for.Blazor/css/kendo-theme-material/all.css?@telerikUiForBlazorVersion" rel="stylesheet" /> 
    <link href="lib/fontawesome/css/all.css" rel="stylesheet" />
    <link asp-href-include="css/styles.css" rel="stylesheet">
    <link asp-href-include="css/site.css" rel="stylesheet" />
    <link rel="icon" type="image/png" href="favicon.png" />
    <script src="_content/Telerik.UI.for.Blazor/js/telerik-blazor.js?@telerikUiForBlazorVersion"></script>
    <component type="typeof(HeadOutlet)" render-mode="ServerPrerendered" />

Not being cached by the Browser.

How do I get them to target some components?

Why did you remove the default feature rather than just make an option flag?

Rob.

 

 

[Dimo]

Rob,

Please review the attached sample app and compare with yours. The code in Home.razor and Counter.razor shows both alternative techniques from my previous replies. As always, the browser's DOM inspector is your best friend.

Note that I changed the custom CSS rule to apply a green border only at the bottom, in accordance with the Material design language. Of course, this is a matter of personal preference.

Judging by all the information that you provided so far, the issue may be related to custom CSS styles in your app, which prevent the green borders from displaying on all Form inputs.

>> Why did you remove the default feature rather than just make an option flag?

This was not a feature, but an implementation oversight. We added styles to the theme by mistake and then reverted the change. On the other hand, the feature that adds a k-valid CSS class to the Form inputs exists and you can benefit from it if you like. Apart from being rarely needed and requested, a positive validation styling is cumbersome to implement due to the limited EditContext API and false positive considerations that I described in my first reply.

[Rob]

>> As always, the browser's DOM inspector is your best friend. <<

I'll disagree, more like my worst nightmare and to be avoid if possible as I have actual real work to do ;)

Will take a look at your zip and get back to you.

As always, thank you for taking the time.

Rob.