views:

29

answers:

1

The design I've come up with for filtering is awkward at best, and buggy at worst. The idea is to have a base class to support a pick list, and let subclasses add on additional filtering logic as needed.

What is particularly confusing to me is how to trigger the view to filter as various filtering criteria change (see _ApplyFiler(), below). Is setting the filter that way appropriate? Where should I unsubscribe / set it to null after it filters?

Cheers, Berryl

ugly code:

public class SubjectPickerBase<T> : ViewModelBase, ISubjectPicker<T> 
    where T : class, IAvailableItem, INotifyPropertyChanged, IActivitySubject
{
    public CollectionViewSource Subjects { get; private set; }

    protected SubjectPickerBase() { }

    protected void _Initialize(IEnumerable<T> subjects, string subjectName) {
        ...

        Subjects = new CollectionViewSource { Source = subjects };
        _ApplyFilter();
    }

    protected void _ApplyFilter() {
        Subjects.View.Filter += Filter;
    }

    private bool Filter(object obj)
    {
        var subject = obj as T;
        if (ReferenceEquals(subject, null)) return false;

        NotifyPropertyChanged(() => Status);

        var isIncludedBySubclass = OnFilter(subject);
        var isIncludedByBase = subject.IsAvailable;
        return isIncludedByBase & isIncludedBySubclass;
    }

    /// <summary>Hook to allow implementing subclass to provide it's own filter logic</summary>
    protected virtual bool OnFilter(T subject) { return true; }


 }

public class ProjectSelectionViewModel : SubjectPickerBase<ProjectViewModel>
{

    public ProjectSelectionViewModel(IEnumerable<ProjectViewModel> projects) 
    {
        ...
        _Initialize(projects, Strings.ActivitySubject__Project);
    }

    public string DescriptionMatchText {
        get { return _descriptionMatchText; }
        set {
            ApplyPropertyChange<ProjectSelectionViewModel, string>(ref _descriptionMatchText, x => x.DescriptionMatchText, value);
            _ApplyFilter();
        }
    }
    private string _descriptionMatchText;

    protected override bool OnFilter(ProjectViewModel subject)
    {
        ...
        var isDescriptionMatch = subject.IsMatch_Description(DescriptionMatchText);
        return isPrefixMatch && isMidfixMatch && isSequenceNumberMatch && isDescriptionMatch;
    }

}
A: 

There are several pieces to a non-trivial manipulation of the view that I was missing, all having to do with refreshing the CollectionView that is a property of the CollectionViewSource:

The first part of my question was when to set the filter. For my use case, what worked best so far turned out to be registering for the CollectionViewSource.Filter event and then using the View.Refresh method each time a filter is changed. The initial registration of the filter event also triggers the event handler, and many of the msdn samples you see show this as a way of filtering a view, and nothing else. But if your scenario is not trivial & the user can change some filter criteria, you need to use one or more of the above refresh related methods & properties.

The second part of my question had to do with whether you needed to unsubscribe to the filter event, and if so, when. Well, it turns out that you don't need to unsubscribe, but if you do so it effectively clears any filtering of the view. And many of the msdn trivial samples do exactly that to clear the filter, which is certainly the way to go if you want to completely clear any filtering, but for my use case was not what I really wanted. What I wanted was to clear some criteria but not others, and so again using Refresh (at the right time) gave me the desired behavior.

HTH,
Berryl

Berryl