[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] General Purpose Navigator
|
See my replies marked with <knut> below. None of what I write is set in
stone at this point. Everything is up for debate.
Knut
|---------+--------------------------------->
| | Dirk Baeumer |
| | <dirk_baeumer@xxxxxx.c|
| | om> |
| | Sent by: |
| | platform-ui-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 06/18/2003 05:57 AM |
| | Please respond to |
| | platform-ui-dev |
| | |
|---------+--------------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: platform-ui-dev@xxxxxxxxxxx |
| cc: |
| Subject: [platform-ui-dev] General Purpose Navigator |
| |
>------------------------------------------------------------------------------------------------------------------------------|
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 ;-).
<knut>
To clarify: The goal of the General Purpose Navigator is not really to
have a single Navigator view that serves all users ("The Great One"). The
idea is to have a single view that adapts to specific purposes. So you
might have a Resource Navigator, Java Navigator and Web Navigator. They are
all different presentations but will be just different "modes" of the same
view from an implementation point of view. We want to have one concept of a
Navigator but allow for individual instances tailored to a specific
task/user group.
We do not plan to allow plugins to modify other Navigator views to the
point of adding in content providers. Each view will have a distinct
presentation.
Of course, that doesn't make it any easier. If it was easy it wouldn't be
any fun, now would it?
</knut>
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.
<knut>
I agree. Knowing the implementation of the Package Explorer it is not a
good use case for demonstrating how a General Purpose Navigator in "Java
mode" (Java Navigator) might work. Since you already have a complete model
that you want to display it doesn't make any sense to reuse a resource
content provider and tweak it to what Java needs.
</knut>
- 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.
<knut>
It will be up to the specific content provider to supply this more fine
grained content.
That's why I don't think we want to allow arbitrary content
customization/extension using extension points. There are just too many
variations.
In this scenario the Ant plugin would not be able to add to the Java
Navigator in order to supply more content at the Java compilation unit
level. Instead an Ant Navigator could specify a content provider that is
based on the Java content provider and adds another level for Ant xml
files.
It is interesting to consider allowing content customization by any plugin
in any view. However, I think it would add a lot of complexity that we
don't need at this point. You would want some amount of control over what
other plugins do to "your" view. Otherwise you may end up with something
that is no longer tailored to a specific user role or task.
</knut>
- 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.
<knut>
Yes, this is exactly what we need. The problem is that the Navigator
needs it at the workbench level, not JDT. I don't really want to duplicate
efforts here. If I only design static web pages then I would not use the
Java Navigator to rename files. More generally even if I do use Java, if I
rename a regular resource (i.e., no Java file) then perhaps I always want
to get the plain resource rename and not the Java rename. The latter is
something to consider in general. I think actions should be consistent
based on file type. If I rename a GIF file I want the same behavior
regardless of which view "mode" I am using.
</knut>
- 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.
<knut>
We do want to allow changing the behavior of standard actions. We do not
want to allow changing how the action itself is presented in the UI. I.e.,
we add the action for you but you can change the behavior (declaration vs.
definition). The problem now in some Eclipse based products is that you
have many views that add a delete, rename, refresh or some other standard
action but don't hook the retargetable action handler. You end up with
enabled menu items in the context menu but disabled menu items in the
workbench menu bar. We'd like to make it harder to screw this up.
</knut>
- 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.
<knut>
I think the answer is to provide more control via an extension point.
E.g., allow specifying a class that implements an IActionFilter when you
specify an object contribution in the popupMenu extension point.
</knut>
- 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 ?
<knut>
Since each Navigator view is designed with a specific task/role in mind
and has complete control over its contents it will also have complete
control over the filter dialog.
</knut>
- 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.
<knut>
If you are working with web projects you would use the Web Navigator. Say,
it generally uses a Java presentation but with some modifications for web
projects. From an implementation point of view the Web Navigator would want
to reuse the Java content provider. So yes, the base content providers
(Resource, Java) should be API. We haven't talked about what the protocol
for this API should look like though. If the Web Navigator only wants to
add to the Java content model you should be able to do this using an
extension point. In most cases you will probably want to replace elements.
Again, the question is how to best allow for content customization. Going
beyond simply adding elements you probably can't rely on extension points
alone anymore.
</knut>
Dirk
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
