Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] [resources] Resource Folder filters 
Hi Terry,
My perspective is that the purpose of that resource filter feature is to improve performance and scalability at the resource layer level, while allowing the user to efficiently build the logical project file structure.
The user already has a way by using viewer filters to hide unwanted resources (such as .projects, etc...), but the limitation of this functionality is that the underlying resources tree (which can be massive) is still created for the hidden resources.
The resource filters allows to scale down the resource tree created by implementing the filtering directly when a folder resource refreshes from the file system, it isn't meant as a solution to generally allow the user to create arbitrarily complex logical project structure (that what are linked resources for).
Having filtering at the EFS level (which is analogous to have it at the Directory.Filter level discussed earlier in this thread) is a nice addition, although it is only as long as a method such as IFileStore. childStores(Filter, |int options, IProgressMonitor <http://developer.capeclear.com/7.5.1/help/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/IProgressMonitor.html> monitor) is faster than the regular |IFileStore. childStores(|int options, IProgressMonitor <http://developer.capeclear.com/7.5.1/help/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/IProgressMonitor.html> monitor).| 
|
From my perspective, the concept of resource filters already exist at the application layer - Viewer filters -, the resource filters belong to the resource layer, and EFS filters would be at the file system layer.
If I understand you correctly, the idea of IVisibleResource is really a linked resource, is that correct? 
|
Serge.

Terry Parker wrote:
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 <Michael.Scharf@xxxxxxxxxxxxx <mailto:Michael.Scharf@xxxxxxxxxxxxx>> 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
        eclipse-incubator-e4-dev@xxxxxxxxxxx
        <mailto:eclipse-incubator-e4-dev@xxxxxxxxxxx>
        https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev


    _______________________________________________
    eclipse-incubator-e4-dev mailing list
    eclipse-incubator-e4-dev@xxxxxxxxxxx
    <mailto:eclipse-incubator-e4-dev@xxxxxxxxxxx>
    https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev


------------------------------------------------------------------------

_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev

Back to the top