Allow LINQ Expressions for Binding Expressions #1667

jkoritzinsky · 2018-06-10T03:05:12Z

What does the pull request do?
- Add new API to allow users to create ExpressionObservers with LINQ Expressions instead of strings.
- Move string-based binding paths up to Avalonia.Markup.
- Fix attached property resolution to always resolve the correct property.
What is the current behavior?
- ExpressionObservers can only have their binding paths specified as strings.
- The AvaloniaPropertyAccessorPlugin tries to resolve an attached property name without the XAML context, so it just makes a guess of which property is the correct property.
What is the updated/expected behavior with this PR?
- ExpressionObservers can be created from LINQ Expressions, ExpressionNodes, or strings.
- Attached property bindings now use the AvaloniaPropertyAccessorNode class instead with an already-resolved AvaloniaProperty that is resolved via a callback (i.e. XAML type lookup) when built from a string.
How was the solution implemented (if it's not obvious)?
- Stream Bindings in LINQ Expressions are pattern based. A method that is either an instance method or extension method without parameters named StreamBinding generates a stream binding node at that point in the expression.

Checklist:

Added unit tests (if possible)?
Added XML documentation to any related classes?
Consider submitting a PR to https://github.com/AvaloniaUI/Avaloniaui.net with user documentation

If the pull request fixes issue(s) list them like this:

Fixes #1652.

…esn't generate IndexExpressions (they weren't in S.L.Expressions v1 so they aren't auto-genned).

…Expression paths and raw ExpressionNodes (now public) the primarily supported syntax.

grokys

Hey @jkoritzinsky I really love this! It's something I intended to do from the beginning but never got round to.

Just a few things:

Indexers don't seem to be working. We should really be testing expressions in the unit tests to catch stuff like this
Should we also allow Binding to be created with expressions? Binding provides a few extra features like binding to the DataContext or to other controls that could be really useful along with strong typing. This could be a separate PR though.

grokys · 2018-06-13T04:19:11Z

src/Avalonia.Base/Data/Core/ExpressionObserver.cs

+        /// <param name="node">The expression.</param>
        /// <param name="description">
-        /// A description of the expression. If null, <paramref name="expression"/> will be used.
+        /// A description of the expression. If null, <paramref name="node"/> will be used.


This statement doesn't seem to be true.

grokys · 2018-06-13T04:20:05Z

src/Avalonia.Base/Data/Core/ExpressionObserver.cs

            _root = new WeakReference(root);
        }

+        public static ExpressionObserver Create<T, U>(


Need an XML doc here.

grokys · 2018-06-13T04:41:59Z

tests/Avalonia.LeakTests/ExpressionObserverTests.cs

            {
                var source = new { Foo = new MethodBound() };
-                var target = new ExpressionObserver(source, "Foo.A");
+                var target = ExpressionObserver.Create(source, o => (Action)o.Foo.A);


I'm getting an exception thrown here:

System.InvalidOperationException: No coercion operator is defined between types 'Avalonia.LeakTests.ExpressionObserverTests+MethodBound' and 'System.Action'.

Not sure why this isn't showing up on CI?

Leak Tests aren't running on CI currently. That's fixed as part of my Cake PR.

grokys · 2018-06-13T04:45:21Z

tests/Avalonia.Base.UnitTests/Data/Core/ExpressionObserverTests_Property.cs

        {
            var data = new { Foo = "foo" };
-            var target = new ExpressionObserver(data, "Foo");
+            var target = ExpressionObserverBuilder.Build(data, "Foo");


Should all these tests be using ExpressionObserver.Create rather than ExpressionObserverBuilder? We should really be testing the ExpressionObserver itself here, and putting the ExpressionObserverBuilder stuff in the markup tests I think.

grokys · 2018-06-13T04:47:53Z

src/Markup/Avalonia.Markup/Markup/Parsers/ExpressionObserverBuilder.cs

+
+namespace Avalonia.Markup.Parsers
+{
+    public class ExpressionObserverBuilder


It feels like this should probably be internal - is it public just for the ExpressionObserver tests? If we make them use ExpressionObserver.Create then could this be made internal?

Currently it's public so XAML layer classes (MemberSelector and TreeDataTemplate) can use it just like they were using ExpressionObserver beforehand.

grokys · 2018-06-13T04:50:58Z

tests/Avalonia.Base.UnitTests/Data/Core/ExpressionObserverTests_Indexer.cs

        {
            var data = new { Foo = new [] { "foo", "bar" } };
-            var target = new ExpressionObserver(data, "Foo[1]");
+            var target = ExpressionObserverBuilder.Build(data, "Foo[1]");


If I change this to be:

var target = ExpressionObserver.Create(data, x => x.Foo[1]);

I get:

Xunit.Sdk.EqualException: Assert.Equal() Failure Expected: bar Actual: {Error: System.MissingMemberException: Could not find CLR property 'Foo' on 'System.String[]'}

We really need to be testing ExpressionObserver with actual expressions here!

grokys · 2018-06-13T05:15:06Z

Also, does this PR depend on #1668? A lot of the changes seem to be similar.

jkoritzinsky · 2018-06-13T05:16:42Z

#1668 is dependent on some of the changes in this PR. After this gets merged in the changes over there will clean up a lot.

…For tests that require using invalid members or are more tedious to test with expression trees, test them in Avalonia.Markup.UnitTests with ExpressionObserverBuilder.

…-expressionobserver

grokys · 2018-06-26T22:28:53Z

This is going to conflict with #1694, which do you think it makes more sense to get merged first?

jkoritzinsky · 2018-06-26T22:31:29Z

I'm on vacation for a week, so probably #1694. Alternatively, all that's left to do here is the XML doc comments, so if you want to put those in we could merge this on approval.

…-expressionobserver

jkoritzinsky · 2018-07-03T02:31:48Z

@grokys I've made all the requested changes. Can you take another review pass when possible?

grokys

Mainly a few nits here, but I do wonder about my point 2 above: by making ExpressionObserver only handle expressions and pushing string expressions into Binding, we're making ExpressionNode part of the public API when it feels like an implementation detail.

What would be the cons of making ExpressionObserver handle strings as well?

grokys · 2018-07-07T12:16:00Z

src/Avalonia.Base/Data/Core/Parsers/ExpressionTreeParser.cs

+{
+    class ExpressionTreeParser
+    {
+        private readonly bool enableDataValidation;


This applies to quite a few places, but elsewhere we use _field with an underscore for fields to follow the .net core coding guidelines.

grokys · 2018-07-07T12:17:21Z

tests/Avalonia.Base.UnitTests/Data/Core/ExpressionObserverTests_ExpressionTree.cs

+        {
+            NotifyingBase test = new Class1 { Foo = "Test" };
+
+            var target = ExpressionObserver.Create(test, o => ((Class1)o).Foo);


Oh nice! I was just about to check if this works!

grokys · 2018-07-07T12:30:29Z

src/Avalonia.Base/Data/Core/Parsers/ExpressionTreeParser.cs

+
+namespace Avalonia.Data.Core.Parsers
+{
+    class ExpressionTreeParser


Does this need to be a separate class? Could this and ExpressionVisitorNodeBuilder be combined into a single class?

I could combine it, but I like having the visitor implementation in its own class. Keeps the messy logic of the visitor separated from the simpler logic in ExpressionTreeParser.

grokys · 2018-07-07T12:37:01Z

src/Avalonia.Base/Data/Core/ExpressionObserver.cs

+        /// <param name="description">
+        /// A description of the expression. If null, <paramref name="expression"/>'s string representation will be used.
+        /// </param>
+        public static ExpressionObserver Create<T, U>(


Usually, methods come after ctors. I understand why you've done it like this (every ctor has an accompanying static creation method) but I'd rather stick to our standard ordering.

I've moved them to after the constructors.

jkoritzinsky · 2018-07-09T00:07:26Z

I have a few reasons why I like having the string support outside of ExpressionObserver.

By having the string support in the Markup layer, the Reader class moves up as well (enabling Remove Sprache dependency #1668)
If we have string support in the base layer as a constructor (as done currently), then we make string bindings the easiest path of use. I'd like to push advanced users that want to directly use ExpressionObserver to use type-safe binding expressions if possible.
By making ExpressionNode and subclasses part of the API, we allow advanced users who want to customize the binding system (which is already supported on ExpressionObserver in master) to create custom binding nodes if they so wish.
Everything in Avalonia.Data.Core is already an implementation detail namespace. I don't think exposing anything in that namespace publicly is necessarily bad.

…-expressionobserver

grokys · 2018-07-10T09:44:25Z

Ok, yes those sound like good arguments for doing it this way 👍

jkoritzinsky added 7 commits May 17, 2018 17:39

Preliminary support. Indexers require more work since the compiler do…

e8c32bf

…esn't generate IndexExpressions (they weren't in S.L.Expressions v1 so they aren't auto-genned).

Merge branch 'master' into linq-expression-expressionobserver

de1f300

Fix indexer and casting expressions.

bf6375f

Fix bug in ExpressionVisitorNodeBuilder.

d282311

Move string-based binding paths up to Avalonia.Markup. Make the LINQ …

af186e3

…Expression paths and raw ExpressionNodes (now public) the primarily supported syntax.

Add pattern-based support for streaming. Fix bugs in method bindings.

c6c51dd

Remove now-unneeded logic in AvaloniaPropertyAccessorPlugin.

8a6be39

jkoritzinsky requested a review from a team June 10, 2018 03:05

jkoritzinsky mentioned this pull request Jun 10, 2018

Remove Sprache dependency #1668

Merged

3 tasks

Fix missing type resolver in TemplateBindingExtension.

2be443a

grokys requested changes Jun 13, 2018

View reviewed changes

grokys assigned jkoritzinsky Jun 14, 2018

jkoritzinsky added 3 commits June 18, 2018 17:40

Make tests in Avalonia.Base.UnitTests use ExpressionObserver.Create. …

1b2d644

…For tests that require using invalid members or are more tedious to test with expression trees, test them in Avalonia.Markup.UnitTests with ExpressionObserverBuilder.

Merge remote-tracking branch 'AvaloniaUI/master' into linq-expression…

775f9e7

…-expressionobserver

Fix merge

f759d28

jkoritzinsky added 2 commits July 2, 2018 21:23

Merge remote-tracking branch 'AvaloniaUI/master' into linq-expression…

b525070

…-expressionobserver

Add XML docs.

dbc942b

jkoritzinsky assigned grokys and unassigned jkoritzinsky Jul 3, 2018

Add back missing typeResolver arguments removed in the merge.

e76eda1

grokys requested changes Jul 7, 2018

View reviewed changes

Fix nits.

f6fc306

Merge remote-tracking branch 'AvaloniaUI/master' into linq-expression…

19ec878

…-expressionobserver

grokys approved these changes Jul 10, 2018

View reviewed changes

Merge branch 'master' into linq-expression-expressionobserver

3ac4891

jkoritzinsky merged commit 3dd5e3a into AvaloniaUI:master Jul 10, 2018

jkoritzinsky deleted the linq-expression-expressionobserver branch July 10, 2018 15:49

grokys added this to the 0.7.0 milestone Apr 3, 2019

Uh oh!

Allow LINQ Expressions for Binding Expressions #1667

Allow LINQ Expressions for Binding Expressions #1667

Uh oh!

Conversation

jkoritzinsky commented Jun 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

grokys left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

grokys commented Jun 13, 2018

Uh oh!

jkoritzinsky commented Jun 13, 2018

Uh oh!

grokys commented Jun 26, 2018

Uh oh!

jkoritzinsky commented Jun 26, 2018

Uh oh!

jkoritzinsky commented Jul 3, 2018

Uh oh!

grokys left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkoritzinsky commented Jul 9, 2018

Uh oh!

grokys commented Jul 10, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jkoritzinsky commented Jun 10, 2018 •

edited

Loading