Bug 18177

Summary: Looks API - create a stable version
Product: contrib Reporter: Jaroslav Tulach <jtulach>
Component: LooksAssignee: Petr Hrebejk <phrebejk>
Status: RESOLVED FIXED QA Contact: issues <issues.netbeans.org>
Priority: P1 CC: lkramolis, mentlicher, pjiricka, pkuzel, rkubacki, sdedic
Version: 3.xKeywords: API, ARCH
Target Milestone: 3.x   
Hardware: PC   
OS: Linux   
Whiteboard:
Issue Type: ENHANCEMENT Exception Report:
Bug Depends on: 17934, 18179, 19340, 19357, 19905, 20102, 20103, 21365    
Bug Blocks: 21340, 10145, 18985, 20306, 20690, 26921, 27843    
Attachments: First offcial version of the API/SPI

Description Jaroslav Tulach 2001-11-29 08:17:59 UTC
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.
Comment 1 Jaroslav Tulach 2001-11-29 08:21:24 UTC
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.
Comment 2 Jaroslav Tulach 2001-11-29 08:27:16 UTC
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.


Comment 3 Jaroslav Tulach 2002-01-11 11:35:56 UTC
See documentation page:
http://openidex.netbeans.org/proposals/looks/index.html
Comment 4 _ lkramolis 2002-01-29 11:12:36 UTC
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.
Comment 5 _ ttran 2002-02-27 15:16:22 UTC
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.
Comment 6 Svata Dedic 2002-02-27 15:31:56 UTC
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.

Comment 7 _ pkuzel 2002-02-27 15:37:36 UTC
For XML: Looks gives possibility to fix several interoperability bugs.
Comment 8 _ rkubacki 2002-02-27 15:52:44 UTC
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.
Comment 9 Svata Dedic 2002-02-27 18:33:21 UTC
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
Comment 10 Pavel Buzek 2002-03-01 09:06:18 UTC
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.
Comment 11 Milos Kleint 2002-03-08 13:50:34 UTC
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.
Comment 12 Petr Hrebejk 2002-04-03 11:40:08 UTC
*** Issue 2217 has been marked as a duplicate of this issue. ***
Comment 13 Petr Hrebejk 2002-06-06 08:17:16 UTC
Subcomponent change
Comment 14 Petr Hrebejk 2002-06-24 11:12:21 UTC
Moving Looks issues to dev 4.0
Comment 15 Jaroslav Tulach 2002-07-26 18:13:51 UTC
I think this is a must have task for 4.0, is it not?
Comment 16 Jaroslav Tulach 2002-09-30 12:47:40 UTC
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. 
Comment 17 Petr Hrebejk 2003-04-29 20:34:58 UTC
Created attachment 10189 [details]
First offcial version of the API/SPI
Comment 18 Petr Hrebejk 2003-05-06 09:10:55 UTC
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.
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo