This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
We need a reasonable way how to organize looks so we can easily locate them for given representation object in a way that makes it probable that correct look will be found. We need a way for different modules to replace (or lower priority) of some look and provide their own. We need use to be present with available looks (which make some sence on that object) and being able to pernamently change the order of looks available for given object.
I believe that issue 17934 (naming service over content of SFS) is good solution and I that is why I prototyped it: cvs co -r lookup_api_2001 -f core cvs co -r lookup_api_2001 -f openidex and check file org.openidex.nodes.looks.JndiLook for implementation of namespace search.
The current implementation base its search on class of representation object. Please design the JndiLook (or rename it) so one can insert its own Object->[String] conversion. So for example XMLDataObject look could base its decision on DTD name of the document. Suggestion - there might be a method: protected abstract Enumeration<String> names (Object representationObject) to allow such subclasses to do it.
See documentation page: http://openidex.netbeans.org/proposals/looks/index.html
Issue 18985 describes another problem of current (3.3) Looks implementation: Steps to reproduce: =================== 1) In the Explorer right-click a Foolder node and choose Find. 2) Find some XML document. 3) Expand the XML document in the Search Result dialog. XML document's nodes missing in the document tree.
Given current resource situation, we'll have to defer this issue to 4.0. If this decision is a big problem for someone, please add your justifications here.
We (= java module) hoped to use Looks to provide usability features (configurable displays in quickbrowse, or explorer) requested for 3.4 - since they allow greater flexibility for both users and implementors.
For XML: Looks gives possibility to fix several interoperability bugs.
Web modules developers would like to use looks for object enhancing. There is a lot of places in web module where different modules may want to change behaviour or appearance of object and Looks promise good solution without need for interoperability hooks.
Previous comments reminded me of another issue java & clazz modules have: We use a proprietary mechanism to allow extensibility as well (org.openide.src.nodes.FilterFactory). That mechanism is not sufficient and not really good. We've planned to get rid of it as soon as possible: in fact Looks effort was originally started as an attempt to solve this problem IIRC
The UI of new projects will greatly depend on Looks API. New projects will not be in 3.4, so target release for Looks is not my concern. But timing matters - we need to have project ready soon in 4.0 release cycle so we need Looks API stable enough to be able to build on it.
the VCS task #21340 depends on looks as well, the looks bug #21365 needs to be resolved in order we can use looks for our purposes.
*** Issue 2217 has been marked as a duplicate of this issue. ***
Subcomponent change
Moving Looks issues to dev 4.0
I think this is a must have task for 4.0, is it not?
These issues are planned as Sun's "must have" contribution to NetBeans 4.0 and are considered to be "high level" issues. That is why changing the type to FEATURE and priority to P1.
Created attachment 10189 [details] First offcial version of the API/SPI
See the official looks version in openide/looks. The feature is implemented and it is possible to create nodes without handles. Showing not/showing handle is controlled by the isLeaf(...) method in the Look class.