[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] [resources] Resource Folder filters
|
> From my perspective, the concept of resource filters already
> exist at the application layer - Viewer filters -, the resource
> filters belong to the resource layer
+1, and EFS filters are not needed IMHO since the file system
should be accurately reflected.
If we're filtering at the resource layer already, then
filtering at the EFS layer as well would only improve
performance in the case of a rather "flat" structure
with lots of files in a folder that resources would
filter out later. That's not worth the effort, especially
given that many FS providers don't understand filtering
either.
This assumption might be different if databases are the
back-end of EFS.. I don't know much about these.
For me, the concept of filtering at the application layer
(that is, providing a logical "view" onto the resources
especially geared for a particular client) is interesting
in order to reduce resource delta notifications and reduce
the number of resources that a Visitor needs to visit.
If CDT, as a client, expresses interest in resources of content
type "c-file" only which reside in its (already filtered!) source
folders only, then the amount of resource change notifications
sent to CDT could likely be reduced. Performing a refreshLocal
on that "view" only could avoid getting file stat unnecessarily
for object and other files that CDT doesn't care about in this
case.
This is especially interesting when multiple natures are
present in a project (e.g. Java and C and Modeling and WTP),
and it is different than the logical project structure, which
I understand would be shared by all natures in a project.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
>
> 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
> >
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
