I'm experimenting with doing this kind of filtering at the EFS level now, and it works nicely. I think it is a very useful addition to EFS. However, it doesn't solve the use case where you want to display an alternate logical project structure in one Explorer, while showing the actual file system structure in a different view. There are currently at least two different concerns being merged in the IResource interface:
1) underlying filesystem structure 2) logical project structure In terms of the 3 layers (filesystem, resource, application) that Michael identified in the kickoff discussion, 1 corresponds to the filesystem layer, and 2 to the application layer. Is there a clean way to tease these two concerns apart? If we want to present different mappings for the same underlying IFileStore objects, maybe we should simplify the IResource interface to deal mainly with the management of metadata and delta notifications and introduce a new IVisibleResource interface that deals with presenting the logical relationships between resources (it could delegate its relationships to the underlying IFileStore for the common case). --Terry On Tue, Oct 21, 2008 at 11:49 PM, Michael Scharf < [EMAIL PROTECTED]> wrote: > I would put the resource filters into the EFS layer. Essentially > telling EFS what to exclude/include. The file/directory > hierarchy stays intact but some files/directories become > invisible. > > VS style groups and linked resources change the structure and > should be done at the resource level or the application level. > > Michael > > > Hi all, >> >> We're working on a "Resource Folder Filter" feature that, a little bit >> like Visual Studio does, allows to control which files and folders are >> picked up when a refresh is performed in the workspace on a folder. >> >> The Resource Folder Filter works very simply by the ability to set a list >> of filters (which can be extended with a core resource extension point) on a >> IFolder, whether it is a standard folder or linked resource, and the option >> to make it "inherited", in which cases it applies to all its children >> folders. >> A filter can be defined to either "include only" or "exclude all" files >> and folders matching a given criteria >> >> A default filter is available that allows the user to specify an "include >> only" filter that match a string pattern, such as "*.c;*.h". >> >> This feature will allow significant performance and scalability >> improvement for users having a large file system tree, as as opposed to >> hidden resources, filtered files and folders are not created in the resource >> tree, so don't consume needlessly resources. >> >> Let me know what you guys think, thanks! >> >> Serge Beauchamp. >> Software Engineer >> Freescale Semiconductor >> _______________________________________________ >> eclipse-incubator-e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >> > > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
