AdvancedCollectionView's Source as DependencyProperty

[ghost]

Is it possible to change AdvancedCollectionView's Source property into a DependencyProperty? To be able to use it in XAML markup. I want to instantiate ACV in XAML to enforce MVVM. I have all my ViewModels in a separate library.

[nmetulev]

have you tried to see if CollectionViewSource would work?

@tomzorz might have more ideas there too.

[ghost]

@nmetulev what do you mean? I am using AdvancedCollectionView and not CollectionViewSource because of the filtering, sorting capabilities. But if what you are saying is using a CollectionViewSource as the Source of the AdvancedCollectionView, I haven't tried that. I will try that later and update what happens.

One thing I also notice just now, putting an AdvancedCollectionView in the Page.Resources section with no properties set except its key results to a squiggly line. It says, it is not an IList. I think, it is not just the Source property that stops me from using it in XAML.

[tomzorz]

@Rivolvan it wasn't meant to be used in Xaml (despite the naming), because declaring filters/sorts made more sense in code (at least for me, but again I didn't see anyone object).

I read a bunch of SO questions and articles, and most of the Xaml solutions ended up with just stuffing hacky codebehind code in a behavior and using that on the CollectionView. I didn't see how that was better than having it in the ViewModel.

[tomzorz]

The docs give an example of the preferred usage http://docs.uwpcommunitytoolkit.com/en/master/helpers/AdvancedCollectionView/

[ghost]

As I see it, AdvancedCollectionView is made to be UWP specific. And when making cross platform apps, ViewModels are treated as platform agnostic. So it makes sense for those developers and me to put it in the XAML of the UWP app and put the filter logic (usually by a command) in the ViewModel. That way, the filter logic can be shared with other platforms no matter what kind of "CollectionView" is used by those platforms. As for XAML declaration, it seems easier to put it this way:

<AdvancedCollectionView Source={x:Bind ViewModel.Items, Mode=OneWay}> <interactivity:Interaction.Behaviors> <core:EventTriggerBehavior EventName="Filter"> <core:InvokeCommandAction Command="{x:Bind ViewModel.Filter}" InputConverter="{StaticResource FilterConverter}" </core:EventTriggerBehavior> </interactivity:Interaction.Behaviors>

[tomzorz]

@Rivolvan I see your point, and I do have to mention that during implementation I did not consider cross-platform usage. I've seen a hole in UWP that I wanted to fix :)

As for the actual crossplat usage: I'd still prefer if this this wouldn't be in a "uwp toolkit" but maybe in a crossplat toolkit, allowing you not to put this in XAML. But as this thing is in a "uwp toolkit" probably the only solution aside from grabbing the source is making it work in XAML.

To that end I see the following immediate tasks:

• make AdvancedCollectionView a descendant of DependencyObject
• make the Source property a DependencyProperty
• make SortDescription a descendant of DependencyObject
• fix the constructors so they work in XAML

This would probably enable the usage you want. In the future maybe we could change other properties into DPs, so they can be used as an updating binding source / target.

[tomzorz]

Two more things:

• I'd like to see a little input from the repo owners / code reviewers to see what they think of this change before jumping into implementation.
• While I'd be happy to work on this, as far as I see I don't have time to do that for the next 4-5 weeks.

[ghost]

@tomzorz don't get me wrong, I am very thankful that you have taken the time to fill up a hole in UWP that every business app developer needs. And know that I am not saying that you have done this wrong. I just want to know the design behind the implementation. And I wanted to know if there is a workaround to use it in XAML.

I am also in the middle of a project right now, so as a hack, I just put the AdvancedCollectionView in the code behind and talk with the ViewModel via MVVMLight's Messenger. As I said, my ViewModels are in another library so I guess this is the best way I can do for now.

[ghost]

If the creators of this toolkit however sees that we can make the changes you said, I'll be happy to help or maybe make a PR when I can make time.

Thanks again!

[ghost]

As an aside, I think we can never make AdvancedCollectionView platform agnostic however. It relies on UWP APIs that is needed for it to work in UWP's List controls. As I said earlier, the best way we can do for now is make it compatible with XAML usage.

[nmetulev]

Do you see this creating any breaking changes for AdvancedCollectionView?

[tomzorz]

@nmetulev I don't see any at the moment - maybe just the fact that when it becomes a DependencyObject you'll really avoid placing it in the VM.

Maybe we should create a proxy class that lives in XAML? Best of both worlds?

[ghost]

In its current state, the developers who use AdvancedCollectionView in their ViewModels now will still use it there even when we change it to a DependencyObject because, more than likely, their ViewModels are in the same project as their Views or in a UWP Library. (This toolkit can only be referenced from a UWP library anyway)

I don't see any breaking changes when we make this, it will only make it XAML friendly, so win-win.

[skendrot]

Making it a DP does not remove the ability to also create it in code.

[tomzorz]

@skendrot I never denied that ;) It just feels a wee bit weird (at least for me)

[nmetulev]

As long as there are no breaking changes and it can still be used the way it is used right now, I'm ok with you extending it so it can be used in more scenarios. Feel free to submit a PR. :)

[nmetulev]

Up?

[windowstoolkitbot]

This issue seems inactive. It will automatically be closed in 14 days if there is no activity.

[windowstoolkitbot]

This issue seems inactive. It will automatically be closed in 7 days if there is no activity.

[windowstoolkitbot]

Issue is inactive. It was automatically closed.