text: We.
  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:
  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.