Added support for Classes="{Binding StringValue}"

[Athari]

What does the pull request do?

Adds support for binding Classes property to as string:

<Control Classes="{Binding StringValue}" />

See feature request:

• #18068

Currently I await API review and suggestions on what to do with <Control Classes="{Binding #ctl.Classes}">.

Public API changes

  public class StyledElementExtensions
+   public static IDisposable BindClasses(this StyledElement target, IBinding source, object anchor)
+   public static void SetClasses(this StyledElement target, string classNames)
+   public static void SetClass(this StyledElement target, string className, bool value)

Why SetClass was added: there's a need to differentiate between Classes collection modification and Classes.Foo setters/bindings in XAML, because the latter need to always overwrite Classes setter/binding.

To do

• [x] Support for <Control Classes="{Binding StringValue}" Classes.Foo="True">.

  Specific should override general, like it's happening currently without binding, iiuc.

• [ ] Support for <Control Classes="{Binding #ctl.Classes}">.

  Doing <Control Classes="{Binding #ctl.Classes.ClassesString}"> would be simple, I think, but isn't pretty. However, implicitly appending conversion to string makes behavior of <Control Classes="{Binding #ctl.Classes, Converter=...}"> unclear, so maybe explicit is better.

What is the current behavior?

Binding fails with a compilation error due to lack of a setter for Classes property.

What is the updated/expected behavior with this PR?

Now it works, but with limitations. It's currently WIP and I'll continue work if API is approved.

Some things may have broken in the process, like reordering of Classes and Classes.Foo properties. Haven't tested thoroughly yet.

How was the solution implemented (if it's not obvious)?

Used implementation of Classes.Foo="{Binding BoolValue}" as a base.

Initially I wanted to experiment with binding to events (#3766) but decided to try something simple first.

Checklist

• [ ] Added unit tests (if possible)?
• [ ] Added XML documentation to any related classes?
• [ ] Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

None planned.

Obsoletions / Deprecations

None.

Fixed issues

Fixes #18068

[avaloniaui-bot]

You can test this PR using the following package version. 12.0.999-cibuild0060481-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[avaloniaui-bot]

You can test this PR using the following package version. 12.0.999-cibuild0060489-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[Athari]

@MrJul Could you add needs-api-review label, please?

Questions (with my thoughts attached):

1. Are these API changes okay?

     public class StyledElementExtensions
   +   public static IDisposable BindClasses(this StyledElement target, IBinding source, object anchor)
   +   public static void SetClasses(this StyledElement target, string classNames)
   +   public static void SetClass(this StyledElement target, string className, bool value)
   

   Why SetClass was added: there's a need to differentiate between Classes collection modification and Classes.Foo setters/bindings in XAML, because the latter need to always overwrite Classes setter/binding.

2. What should using Classes property as a binding source look like?

   •  <Control Classes="{Binding #ctl.Classes.ClassesString}">
     

     • Pros:
       1. Easy to implement
       2. Leaves binding to/from list of strings as a future possibility
     • Cons:
       1. Not pretty

   •  <Control Classes="{Binding #ctl.Classes}">
     

     • Pros:
       1. Clean "obvious" syntax
     • Cons:
       1. Unclear what arrives to converter in <Control Classes="{Binding #ctl.Classes, Converter={MyConverter}}">, to binding within MultiBinding etc.
       2. Still has to be implemented via a property of Classes (?)

   However, maybe I'm just missing something obvious, as I'm new to XAML and bindings internals.