Community
Participate
Working Groups
This came to my mind while reviewing the filters code. I thought that some people would like to filter out some resources relying on their markers, properties or content types. What do you think?
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.
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.
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
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.
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?
(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.
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.
Created attachment 161620 [details] Change, with throws CoreException
The patch is in HEAD and both UI and core.resources are tagged for the next IBuild.
Created attachment 161663 [details] Change to add API for IW#validateFiltered(IResource)
Created attachment 161664 [details] Change to add API for IW#validateFiltered(IResource)
Created attachment 161667 [details] Change to tests, and javadoc
Now fixed on head.
