[platform-ui-dev] General Purpose Navigator

[Dirk Baeumer <dirk_baeumer@xxxxxxxxxx>]

Hi Knut,

enclosed some feedback especially considering requirements we have in the
JDT/UI world.

I like the idea of having one Navigator in Eclipse although I think it will
not be so easy to achieve ;-).

My comments are:

- tweak of resource content provider or own content provider per nature:

  I feel strongly that we should use the existing Java model content
provider in a Java Navigator. The
  reason is that using the resource content provider and patching, adding
and removing resources is
  exactly what the Java model is doing right now. So we would basically
double this logic from the Java model
  to the Java Navigator content provider. Taken your example this would
mean:
  o for folders mapped to package we have to ignore children which are
folders since Java doesn't have the
      notation of sub package
  o source folders. In our example the content provider has to know that
SourceFolder/SourceSub is the actual
      source folder. When asking for the children of the project we have to
add this. Additionally we have to remove
      SourceSub as a child from SourceFolder. This is exactly what the Java
model is already doing.

- how do we had structure below a file:

  The package explorer show members below a compilation unit as well (the
top level types, their methods, fields,
   .....). A general purpose navigator should support rendering this
structure not only for compilation units but for all
   files types where a "structure content provider" is provided. For
example the Java navigator should be able to show
   the structure of an Ant build.xml file as well.

- open up rename, move, delete, .... actions and refactoring:

  JDT/UI is currently working on an open refactoring infrastructure which
will allow other plug-ins to participate in certain
  refactorings (currently planned are rename, move, delete). These
participants will work for any kind of elements (not
  only Java elements). I already have code running that allows another
plug-in to participate in the rename of a gif file
  (this is for example interesting for a web project which would like to
update html files in this scenario). From how I
  understand your document the refactoring participant architecture is
exactly what you have described with open up
  the actions. The time line for the refactoring participants is as
follows: provide rename and delete participants and
  convert Java refactorings to it for M2 and have a paper ready for the
community.

- I doubt that we will be able to have a good UI story if for special
projects/natures the standard actions can't be
  replaced. We will allow this for refactoring participants. Consider
deleting a file:
  o if the file in a normal resource file then a confirmation dialog is
needed to ask the user if he really wants to
      delete the file.
  o if the file is a compilation unit additional UI is needed asking if the
delete should check for references and
      delete references in import statements without further confirmation.
  Without the ability to somehow "replace" the delete action or its UI the
user will be faced with two dialogs.

- general action contribution: will it be still possible to add action to
an elements context menu via code or is the
  idea that everything will be described in XML. Some of our actions have
enablement logic which we will not be
  able to describe in XML.

- how will the filter dialog look like ? For example if a workspace
contains Simple, Web and Java projects will
  the filter dialog present a combined list of filters. Or will there be
common filters and nature specific filters ?

- how do we ensure that Java specific functionality doesn't get lost when
another plug-in replaces the Java specific
  content provider. Consider the following case: a project has a web and a
Java nature and the web tooling plug-in
  provides a special "navigator" for projects having the web and the Java
nature. Does the new architecture assume
  that JDT/UI make its "navigator code" (content provider, DnD, action
contribution, ...) API so that for example the web
  tooling can reuse it to build a special navigator ? IMO this is currently
a big problem since a derived navigator mostly
  misses functionality from its base navigator.

Dirk