Bug 292787

Comment 1 John Arthorne 2009-10-20 13:43:01 EDT

I don't really understand - filters are currently used before an IResource even exists, as the point is to prune resources out of the resource tree entirely. If you're filtering on properties like markers, etc, then the IResource must already exist so it's too late to filter it out of the tree.

Comment 2 Szymon Brandys 2009-12-02 04:41:15 EST

Right. I think that I'm talking about another kind of filters. We have the concept of HIDDEN resources and maybe we could allow users to configure which resources should be marked HIDDEN and be ignored while traversing deltas.

Anyway this is not a blocker for bug 291755.

Comment 3 Serge Beauchamp 2010-03-04 06:10:30 EST

As I was discussion with Szymon, there's two part of this issue:

1) Improving the current IFileInfoFilter so that he passes the full location, not only the name, so filters can do more advanced things like discriminating files and folders on their file system attributes or paths.

2) Having a Resource filter - that's different than the current filter mechanism) that actually can filter resources based on resource attributes, markers, etc...  A kind of HIDDEN extension

Comment 4 Serge Beauchamp 2010-03-04 14:33:20 EST

Created attachment 161012 [details]
Patch

Here's some modification to the AbstractFileInfoMatcher.

The AbstractFileInfoMatcher.matches(IFileInfo) now takes an additional parameter, the fileStore of the parent as follows:

	public abstract boolean matches(IFileStore parent, IFileInfo fileInfo);

This has 2 main benefits:

1) It's performance neutral:  The parent fileStore is already there in the UnifiedTree code block, there's no cost to just pass it around.

2) It allows filter providers to do vastly more rich filtering, by being able to calculate the full path of the file/folder being filtered, getting file stat (creation date), etc, etc...

Btw, I realized too that with all the refactoring that went on over the last few months, we're not using the IFileInfoFilter anymore.

I think it's a small, but very beneficial change, and I think it's safe to make it for tomorrow's freeze.

Let me know what you guys think.

Comment 5 Szymon Brandys 2010-03-05 12:33:50 EST

Does any of existing filters allow for filtering using paths?

If I have such a project structure:

project1 - folder1 - file11
             - folder2 - file21
                          - file22
                          
and I want to add a filter to project1 to filter out project1/folder2/file22, how should I do it? Should the filter be marked as inheritable?

Comment 6 Serge Beauchamp 2010-03-05 12:59:27 EST

(In reply to comment #5)
> Does any of existing filters allow for filtering using paths?
> 
No, existing filter implementations only filter on filenames.

> If I have such a project structure:
> 
> project1 - folder1 - file11
>              - folder2 - file21
>                           - file22
> 
> and I want to add a filter to project1 to filter out project1/folder2/file22,
> how should I do it? Should the filter be marked as inheritable?

That's right, the filter has to be inheritable.

Comment 7 Serge Beauchamp 2010-03-05 14:27:29 EST

Created attachment 161172 [details]
Change

Here's an even better patch:

Instead of passing the IFileStore of the parent, pass the IContainer directly.

It doesn't change anything in terms of performance, but again, adds much more filtering ability, such as being able to filter not only on the file system location, but also on the workspace path.

Comment 8 Serge Beauchamp 2010-03-10 11:06:30 EST

Created attachment 161620 [details]
Change, with throws CoreException

Comment 9 Szymon Brandys 2010-03-10 12:10:29 EST

The patch is in HEAD and both UI and core.resources are tagged for the next IBuild.

Comment 10 Serge Beauchamp 2010-03-10 15:43:49 EST

Created attachment 161663 [details]
Change to add API for IW#validateFiltered(IResource)

Comment 11 Serge Beauchamp 2010-03-10 15:47:33 EST

Created attachment 161664 [details]
Change to add API for IW#validateFiltered(IResource)

Comment 12 Serge Beauchamp 2010-03-10 16:05:34 EST

Created attachment 161667 [details]
Change to tests, and javadoc

Comment 13 Serge Beauchamp 2010-03-10 16:21:48 EST

Now fixed on head.