Re: [platform-core-dev] E4 Resources and RCP

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

I like the notion of having a consistent
model of containers and elements with builders etc.  It might also
allow an easier bridge to a common communication architecture, allowing
the elements to be local or remote (unfortunately I was away for that call).

This might be different from what you
intended, but:

What I'm not sure of yet is whether
this is a model thing or a view thing.  For example, this could be
*the* model for the Common Navigator.  The way you'd extend content
in the CN is to add to the model, not jump through the CN extension points.
 The IWS* elements then make the mapping the the real resources.

Our current Eclipse UI is made up of
many explorer trees, all of which are some kind of projection on the real
underlying data.  For example, Java packages are a compression of
a directory path (amongst other things).  Would we want to describe
Java navigational elements in terms of this model?

I'm imagining an Eclipse where every
explorer is made of of IWS* elements (or things that adapt to them), each
of which forms a logical, domain specific view onto a physical set of resources.
 Maybe Mike Valenta can comment more on the logical to physical problem,
which he spent quite a bit of time on in the past.  A current issue
(as McQ reminded me of yesterday) is that we are very bad at explaining
to the user the relationship between these logical views, either to the
physical layer, or to each other.  My overly simplistic thought at
the moment is that by having a common description of the logical view elements,
we may then be able to talk about the relationships between them, how you
go from one to another.  I know that's vague though.

Regards,
Kevin

"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
Sent by: platform-core-dev-bounces@xxxxxxxxxxx

09/24/2008 12:53 PM

Please respond to
"Eclipse Platform Core component developers list."        <platform-core-dev@xxxxxxxxxxx>

To	"Eclipse Platform Core component developers list." <platform-core-dev@xxxxxxxxxxx>
cc
Subject	[platform-core-dev] E4 Resources and RCP

Hi all,
 
I've had a talk with Michael Scharf today,
where we got the suspicion that
some RCP's might "mis-use" IResource
for things (like E-Mails etc) that 
are not necessarily file system based --
just in order to easily use existing
infrastructure such as the Project Explorer
that's optimized for IResource
contents.
 
Could that be true? Given that the IResource
class Javadocs explicitly state
"The
workspace
analog
of
file
system
files and
directories.", we
were 
wondering if it would make sense to perform
an "extract supertype" kind of
refactoring on the IResource interfaces in
order to separate the core 
concepts such as IContainer, Operation,
Notification and Builder from
the file system based stuff.
 
This separation of concerns could also be
a step towards allowing RCP 
to user Builders (i.e. Transformers) on the
Workspace tree without having
to have an artificial "Project"
-- If I'm not mistaken, this was one of the 
thoughts mentioned during the E4 Summint.
 
Since the supertypes would still be related
to an IWorkspace tree or,
more concrete, a base type of it: the new
base types could be named 
IWSTree, IWSNode, IWSContainer for
relating to arbitrary stateful elements 
of a workspace (such as virtual folders,
URLs, E-Mails, database members,
computed elements, ...). The existing IResource
/ IContainer could then 
remain the file system based extension of
that basic concept.
 
How does that sound? 
Any thoughts?
--
Martin Oberhuber, Senior
Member of Technical Staff, Wind
River
Target Management Project Lead,
DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 _______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev