Extend `Classes.bind` syntax to support enum and string bindings

[maxkatz6]

Is your feature request related to a problem? Please describe.

Currenly Classes.className syntax only supports boolean bindings, which toggle specified class name on the control:

<Border Classes.className="{Binding BooleanProp}" />

By itself this syntax is very convenient, but also very limiting for enum and string bindings.
For example, if developer wants to toggle classes depending on enum value without any C# code, they should somehow convert it to boolean expression, which can be written this:

<Border Classes.is-verbose="{Binding Verbosity, ConverterParameter={x:Static LogEventLevel.Verbose}, Converter={x:Static ObjectConverters.Equal}}" />

With custom converters this syntax can be slightly improved, but far from ideal.

Describe the solution you'd like

Extend existing syntax by allowing non-boolean bindings. Combined with StringFormat when desired to customize property name.

<Border Classes.bind="{Binding Verbosity, StringFormat='vebosity-{0}'}" />

Where:

1. "Classes.bind" is a reserved property.
2. StringFormat is optional, when return property type is string or enum. Required for any other type.
3. Flags enums are not supported (unless a custom converter).
4. Single binding defines a group of class names, where only single one is set at a time.

It should also work with setters:

<Setter Property="Classes.bind" Value="{Binding Verbosity}" />

Problems:

1. The tricky part is to draw a line between "this is a boolean binding" and a "this is an enum/string binding", especially when binding return type is unknown (reflection binding or converter are used). Unless we introduce a breaking change for any app that already used "Classes.bind" as a classname.
2. With this syntax only single class binding is allowed per control. Since duplicated xml attributes are not allowed.

Describe alternatives you've considered

No response

Additional context

No response

[MrJul]

Alternative syntax: allow binding Classes directly, e.g; Classes="{Binding Verbosity}".
This keeps the Classes.attr syntax for single classes only without needing to special case anything, and feels quite natural.

Also, regardless of the syntax, allow returning a space delimited string to apply several classes at once. Said another way, any string valid in Classes="" should be able to be returned by that binding.

(Optionally, for performance, we might also accept a property or converter returning a IReadOnlyList<string>.)

[kebox7]

Alternative syntax: allow binding Classes directly, e.g; Classes="{Binding Verbosity}".

Well, something similar can be implemented now.

public static class BindableStyle {
    public static readonly AttachedProperty<string> ClassesProperty =
        AvaloniaProperty.RegisterAttached<StyledElement, string>("Classes", typeof(BindableStyle), string.Empty);

    public static void SetClasses(AvaloniaObject element, string value) =>
        element.SetValue(ClassesProperty, value);

    public static string GetClasses(AvaloniaObject element) =>
        element.GetValue(ClassesProperty);

    static BindableStyle() =>
        ClassesProperty.Changed.AddClassHandler<StyledElement>(OnClassesAttachedPropertyChanged);

    private static void OnClassesAttachedPropertyChanged(AvaloniaObject o, AvaloniaPropertyChangedEventArgs e) {
        if (o is StyledElement styled) {
            styled.Classes.Replace((e.GetNewValue<string>() ?? string.Empty).Split(' '));
        }
    }
}

<Rectangle>
    <ui:BindableStyle.Classes>
        <MultiBinding Converter="{StaticResource Converters.StatusItemToClasses}">
            <Binding Path="Value" />
            <Binding Path="Warning" />
        </MultiBinding>
    </ui:BindableStyle.Classes>
</Rectangle>

But I agree, it would have been better without the additional code.

ADD:
This approach has a disadvantage. We can only completely change all classes, and if it is necessary to add one to the existing ones or remove it, this can create problems.

[robloo]

Yea, we should allow a way to set one or more string value to Classes directly. The existing syntax was kind-of hacky as well.

However, I don't have a good idea in mind for this either but I would go a different route as @MrJul said. It makes the most sense to handle all the calculation and conversion of properties to class "string name" in the view model (no need to StringFormat). Then just support binding that view model string name to Classes property on controls.

In fact, the real issue is perhaps we should have made Classes a styles property somehow already. If it took an IEnumerable we could also bind a list of strings to it. I guess the issue is how to differentiate between classes set by binding (which can/should be replaced) vs. classes set elsewhere which need to remain. The classes added in the view model should be appended to what is already there.

Edit: Ok, ugly idea, but what if we had something like ClassesSource like we have ItemsSource. We can bind a separate list to that and it will just append them to existing Classes automatically. Keeping the lists separate solves the issue where bound classes need to be replaced and others should always remain.

[SuperJMN]

Related to this discussion: #18976

[ds1709]

I think it can be usefull to have the NamingConvention option to specify, how the enum value must be converted to class name (PascalCase, camelCase, kebab-case, snake_case, or custom).

[robloo]

I think it can be usefull to have the NamingConvention option to specify, how the enum value must be converted to class name (PascalCase, camelCase, kebab-case, snake_case, or custom).

I agree we aren't doing great on character casing. WPF/C#/XML uses PascalCase for basically everything. However, Avalonia is pulling in a lot of CSS/web ideas and is mixing/matching in inconsistent ways. We should have probably set a standard convention and followed it a long time ago (especially for pseudoclasses).

That said, an enum value has ONLY one proper name convention and that's embedded in the framework itself. Its the same as used by Enum.Parse and related code. It will follow whatever you name the enums in source code yourself but those enum values should be PascalCase.

[ds1709]

WPF/C#/XML uses PascalCase for basically everything

In XML usualy camelCase is used, but not PascalCase. Even in XML basis like xsd ('http://www.w3.org/2001/XMLSchema') all elements and attributes are camelCase.

[robloo]

I am referring the XAML variant of XML. Microsoft follows the same conventions as C#/.NET there for obvious reasons -- so the object model maps 1-to-1 -- same names, same character casing.

It is very much a solved discussion that occurred over 20 years ago.