Looks API - The ideas behind
$Revision: 1.3 $
History: available in
CVS
Based on
Freestyle Browser document
by
Petr Hrebejk
- Abstract:
-
This documents describes the concept of Looks
which should improve the usability of NetBeans Explorer and ObjectBrowser.
The text describes the reasons for introducing the looks,
the look architecture and the known issues with the looks.
- Contents:
- 1. What are Looks?
- 2. Why we propose it?
- 3. Examples & Screenshots
- 3.1 Using Looks in Java
- 3.2 Using Looks in other Modules and in the IDE
Looks are possible extension of the
Nodes API.
Nodes are presentation objects used in the IDE. Presentation in this case should
not be confused with visual presentation. Nodes are an layer between objects,
which should be presented visually (e.g. JavaBeans, DataObjects, Services, Options, etc.)
and the real visual presentation.
The main attributes of a Node are it's children nodes, actions which can be performed
on the Node, new types of nodes which can be created and added into the children
nodes, display name of the node, icon of the node, short description
(usually visually represented as tooltip) of the node, properties organized into sets, etc.
The form of visual presentation of a Node and it's children may vary.
It can be the tree which is usually visualized using the Explorer, it can
be the List used in ObjectBrowser, it can also be an IconView (not used in the IDE currently)
or any other form of nodes visualization. The presentation of the properties
of a Node may also vary. Actions are usually presented in a popup menu,
properties are displayed in the form of a property sheet, ...
But these are not the only ways how to represent things. It is quite possible
to create new types of views where the things can be represented other way.
E.g. a table view can represent the Node hierarchy and the properties of each
node in form of a JTable.
The abstraction of Nodes is quite powerful and useful. But a
common framework for conversion of in-memory representation of data structures
(java.sql.Result, java.util.List, org.openide.filesystem.FileObject, any
JavaBean and etc.) into Nodes is missing.
The looks should be seen as an utility framework which should
fill this gab, thus make the module developer's work easier, and bring additional
improvements for the user.
The basic idea behind the looks is that there exists a net of objects which
have actions/services/methods which can be invoked. The objects also
have attributes/properties which can be displayed and changed.
This is quite obvious in the object oriented world. It also maps
very well to the Nodes abstraction used in the IDE (i.e. Nodes, Properties, Actions etc.)
What we want to change is the fact that there is usually only one way how
to look at the underlying data (object net). We want to use the
tree-formed hierarchy of nodes for displaying more than one relation
in the net of objects.
Good example could be the hierarchy of Java objects. Currently in the IDE
if you look at a Java class using the explorer or the ObjectBrowser is
the hierarchy given by containment (i.e. Java class can contain innerclasses,
fields, constructors and methods). But it is true that the object describing
a Java source rather form a net than a tree. This can also be formulated so
that the containment is not the only relationship which can be displayed for
the Java sources. Please see the next paragraphs for examples of
more possible views of Java classes.
- We want to allow to show more than one relationship between the objects
in the Explorer/ObjectBrowser or any other components visualizing nodes.
- We want to allow other modules to influence the way how elements maintained
by other module are represented. (This is not possible without using APIs
exposed by modules with the exception of Java sources where this can be
achieved using
Filter Factories,
which are not very popular :-)
- We want to give the developers an API which will allow to split the
development of Nodes for their elements into parts. Each part will
focus on some aspect of the Nodes (e.g. Children, Actions, Properties,
Clipboard operations, event firing, etc.) The API should allow to
create composite views from the specified parts, delegating
from one look to another etc.
- We want to give the user the ability to choose how the objects should
be viewed for different parts of a project. E.g. give him the
possibility to select a view displaying only the API for one package,
displaying some Java classes as EJBs, displaying some package as
a set of JavaBeans, etc.
- It would be nice to allow the experienced user to build his own
looks by creating CompositeLooks from predefined parts of a look.
Here are some examples of how you can look at a Java class.
|
Here could be something
like group node for members
inherited from superclasses
|
Classic look of Java class in NetBeans 3.X
|
Old look of Java class in NetBeans Developer 2.X, without the grouping nodes.
|
|
|
A Look which shows superclass and all implemented interfaces for the class
Notice that you can switch to content view on any class or interface to look at members.
|
Look which shows a Java class in form of a JavaBean. Children of properties are setter/getter methods and the field belonging to the property. (Analogous by EventSets.)
|
Of course we can imagine another views of a Java class too e.g:
- Seeing special nodes under the class or source node which list values for various metrics of the code.
- Seeing special nodes which would allow to maintain imports (e.g. unresolved identifiers, identifiers fully qualified in source, import clauses for classes and whole packages with subnodes showing which classes are used.
- Subnodes which list Javadoc texts and tags for given, show the correctness of the Javadoc and let you correct the errors.
- Many others.
We could also crate various groupings (e.g. by modifier) and filterings (e.g show API only; means only public and protected members).
Etc. etc.
Other modules can use Looks too. Good example is the XML module. Showing the XML in the standard DOM form is usually not enough. The Node representation of a XML file rather depends on it's DTD or better said on it's semantics. Looks should allow to crate special tree structures for various kinds of deployment descriptors for example.
Setting an EJB look on some package may show all the contained Java classes in form of EJBs with appropriate grouping of home/remote interfaces, beans etc.
Look in VCS modules which would show all new files in a package which were not added to the repository could avoid some bad checkins :-)
The concept of looks can be even used on the root node in the Explorer to avoid having too many tabs in the Explorer. So different looks of the NetBeans root can be e.g:
- Project
- Settings
- Runtime
- Java class path
- Javadoc search path
- C/C++ include search path
- All mounted filesystems
- ...
You can definitely imagine lot of others alternative structures which can be shown instead of the current ones in the IDE.
