[
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