Looks API - Known problems
$Revision: 1.1 $
History: available in
CVS
Abstract:
There are "few" problems remaining in the Looks API/SPI. This document tries to
summarize them and where possible to provide some solutions. Most of the listed
problems are reflected in one or more
issues filled against the Looks module.
Contents:
- UI for Looks change
- Default look determination
- Children Looks set restriction/change
- Decorator look
- Sharing context throughout the nodes hierarchy
- destroy() Look.NodeSubstitute
- Synchronization problem in LookNode + unregistering substitutes
- Declarative description of looks
- Reflecting changes in loaded modules
- Performance
- Properties and property change Events of the Look itself
- Persistence of the Nodes tree and selected looks
- LEAF non LEAF change
- Index cookie for nodeLook
The most important feature for the end user of an application which uses
Looks is the possibility to change look of given node. In the current
implementation every LookNode has by default "View as" action in it's popup
menu and also an extra property set called "Look" in it's property sheet,
which both allow to change look on given node.
It is very likely that we'll have an requirement
from UI (or from some user of the NetBeans platform) to disallow this
feature and in turn to allow different way of selection of Look for given node.
(E.g. having an combo-box or tool bar in the explorer instead of action in
popup menu). Ideally user of the Looks API/SPI should be able to provide his
own mechanism for changing Looks. The Looks module could provide one utility
look (of type DecoratorLook see bellow) which when used on the root node
of given browser, will add the "View As" action and "Look" property set
to every node in the hierarchy. (Notice that it can be filtered if only one,
either the action or the property set, should be used). But there still has to
be an API call available which will return all available Looks on given LookNode
to make it possible to provide special GUI for changing looks.
Requirements:
- Provide an API call which will determine which Looks can be set on given
LookNode.
- Provide special DecoratorLook with the "View As" action and "Look"
property set.
Depends on:
Issues:
22968,
24360
When creating a new LookNode it is necessary to determine Look which will
be set for this LookNode. There are more aspects which influence the
selection of default look.
- If the parent node was already expanded and the user select some
look on some child node manually then the previously selected look
should probably be used. I say probably because it is a little bit
"matter of taste". However the behavior where collapsing a node clears
all manually selected looks is easy to achieve so we should rather count
with the more complicated case.
- There is a represented object type to Look(s) mapping. Default look
for the node is the first one in this mapping.
The problem here is that the users will probably want to have an option
to influence the order the items in the map. This is the case when user wants
to change default look of given object type in whole explorer/browser.
- Same mechanism as in 2. but using different mapping. See Children
Looks set restriction/change" bellow.
- similar mechanism as in 2. but the selection is not based on
class of represented object but rather on some of it's properties or on
type of some of it's properties etc.
Requirements:
- Provide SPI for default look determination.
- Provide default implementation of this SPI based on type of
the represented object.
- Provide way of plugging in another mechanism based on different
criteria.
- Provide a way for user to change default look for given type.
- Take the performance requirements (especially number of loaded classes)
into account.
Issues:
20394,
21365
It is often required that setting a Look on given node will restrict
or change the set of looks available on the children of the node. An example,
which is unlikely real, could be changing Look on a JavaClass to show the
inheritance hierarchy rather than content of the class. Such Look would
disallow to change back to content view in middle of the inheritance tree.
Requirements:
- Provide an SPI which will allow the change/restriction of available
looks for child objects of LookNode with given Look set.
- Provide a declarative way of specifying such changes
- Make it to work together with the API described in "UI for Looks change"
The usecases of Looks implemented till now (e.g. projects) show that the
looks API will be used for allowing cooperation between modules. E.g. one
module will provide some node and some look for it which will allow
other modules to add children to (ProxyLook/CompositeLook). In such
case the parent node may want to add actions/properties/... to all
it's children without knowing anything about
the child objects. In order to allow this it is desirable to have an utility
Look - let's call it DecoratorLook - which will allow such behavior.
Such DecoratorLook would probably consists of two sets of looks.
One set would be applied to all
subnodes the other would be used for registration of looks by modules
adding the child objects. One usecase of such look is mentioned in
"UI for Looks change"
Requirements:
Questions:
- Is it necessary and optimal to do this using wrapper objects. And
should we provide some utility classes for wrapping.
Issues:
24067
Let's have similar usecase as in the issue "Decorator Look" then it is often
required to provide some shared context throughout the tree of the nodes. The
child objects need to have access to some data bound to it's parent node. An
real example of this could be an reflection browser. Such browser would show
instances of classes it's fields and their values. Imagine following tree.
(something) specifies the type of represented object.
Instance - Hashtable (java.lang.Object)
size :: int (java.lang.reflect.Field)
3 - value of type (int)
In order to determine the value of the field we need to perform a reflection
call which takes the instance of the Hashtable as parameter. This is currently
problematic because the only thing the Look gets is the represented object
(In the case of size it is the java.lang.reflect.Fileld). In other words the
Look needs to be able to access the context of the tree somehow.
Requirement:
- Provide context sharing mechanism.
Questions:
- How often this happens?
- Is it OK to use object wrapping?
Issues:
24067
Issue #22966 says that the Look.NodeSubstitute should have a method allowing
to destroy the node and refresh the parent children.
Solution:
It is probably enough when the fireNodeDestroyed method will do the
children refresh on parent.
Issues:
22966
Currently all the methods in LookNode are synchronized using an instance
of Mutex in every LookNode. This seems to be 1st performance overkill
because of 160 more bytes for every LookNode 2nd Possible source of
deadlocks as client code in Looks is called from the methods.
On the other hand when there is no synchronization in the LookNode's
methods then it may happen that when changing look on the node two or more
NodeSubstitutes are in charge. The first one is the new one created when
changing look the other(s) might used by some Look operations done in different
thread. This state may cause problems.
Solution:
- Get rid of the Mutex synchronization.
- Create a mechanism for switching off, unregistering and ignoring
unused NodeSubstitutes.
Issues:
22967
It should be possible to create looks declaratively.
Requirements:
- Provide file + attribute format for all looks in the Looks Module
- Provide declarative format for "Children Looks set restriction/change"
The set of loaded modules has major influence on behavior of LookNodes.
Adding/removing module can have impact on default look for some type and
obviously on available Looks for given type. But it can also have impact
on all properties of a LookNode. If a look node has some ProxyLook set on it
and some of the delegates is add/removed any of the Node pretties can
potentially change.
Requirements:
- Provide mechanism for propagating changes in Looks to nodes.
Issues:
19340
Requirements:
- Minimize the number of loaded classes. Don't load any Looks until
really used. The only exception is probably LookSelector which
provides mapping form object's types to looks different from the
mapping based on class.
- Make sure that the performance of Node(s) based on huge number
of looks does not differ to much from hardcoded node or from
combination of hardcoded node and some number of FilterNodes.
Look can have it's own properties. E.g. mask in FilterLook. But it can also have
more "civil" properties e.g. sorting. Changing this properties will influence
properties of all nodes with this look set.
Solution:
This should be probably done similar to the solution of "Reflecting changes
in loaded modules". The NodeSubstitutes produced by Looks should listen
on changes in the Look and do the logic. I.e. to translate the changes
in Look properties to events on nodes in an intelligent way. This means
for example that change in a Look property which may only influence
icon of the nodes will not refresh the nodes children.
Notice that this should be an API available for people writing Looks. They
may want to create looks with properties as well.
Questions:
- Currently each Look can find out which nodes have the look set. This
can be done by calling nodeDelegates(). The question is whether we
shouldn't crate something like LookListener (probably extending
PropertyChangeListener). The second solution seems to be more JavaBeans
like and might also be more effective in case we implement some mediator
for registering Listeners and for firing the events.
Currently the expansion of the Nodes is persistent between the runs of the IDE.
There is no reason why the Looks set by the user should be forgotten between the
IDE runs.
Requirements:
- Provide mechanism for the persistence of node tree, selected looks
and relationship between the node and the represented object.
Issues:
20102,
25256?
Just implementation ToDo
Just implementation ToDo
Issues:
17660
