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.

Bug 58819 - Navigator APIs work
Summary: Navigator APIs work
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: David Simonek
URL:
Keywords: API, UMBRELLA
Depends on:
Blocks:
 
Reported: 2005-05-12 12:57 UTC by David Simonek
Modified: 2008-12-22 11:39 UTC (History)
8 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments
answers to arch questions (48.21 KB, text/html)
2005-06-08 13:14 UTC, David Simonek
Details
API clients how to mini guide (3.02 KB, text/html)
2005-06-08 13:16 UTC, David Simonek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Simonek 2005-05-12 12:57:12 UTC
Umbrella issue for navigator related work targeted to 4.2 release.
Comment 1 David Simonek 2005-06-08 13:13:07 UTC
Attaching materials for dev-rev inception review:
Comment 2 David Simonek 2005-06-08 13:14:39 UTC
Created attachment 22549 [details]
answers to arch questions
Comment 3 David Simonek 2005-06-08 13:16:08 UTC
Created attachment 22550 [details]
API clients how to mini guide
Comment 4 David Simonek 2005-06-08 13:23:43 UTC
All code can be found in cvs module core/navigator, on branch navigator_58819.
In "arch" subfolder, example implementations and layer declarations can also be
found.
Comment 5 Torbjorn Norbye 2005-06-08 22:48:21 UTC
Where is BasicNavPanelImpl.java? The link
 http://www.netbeans.org/nonav/issues/showattachment.cgi/22550/BasicNavPanelImpl.java

didn't work for me.
Comment 6 Torbjorn Norbye 2005-06-08 22:49:09 UTC
Doh I should have read your comment about the branch, I'll look there. (Just FYI
the link I followed was in the ModulesHowTo.html document)
Comment 7 Petr Pisl 2005-06-10 07:17:03 UTC
The second link - basicNavLayer.xml doesn't work for me as well. 
Comment 8 Petr Pisl 2005-06-10 09:09:25 UTC
In the manifest there is 

OpenIDE-Module-Layer: org/netbeans/modules/navigator/resources/layer.xml

But the layer doesn't exist and the module is not started. 
Comment 9 David Simonek 2005-06-10 11:44:42 UTC
Petr and others - links from ModulesHowTo attachment don't work, I know, sorry
you have to checkout from cvs and browse.

PPisl - module is not yet ready for development, but thanks for info anyway.
 
Comment 10 David Simonek 2005-06-10 12:17:24 UTC
To make review interesting a bit, here is a list of open issues that I have in
my mind:

1) How to specify order of multiple providers? (Imagine you'd want your special
xml view, say for web.xml to be always higher in Navigator UI combo than generic
xml view). My idea is to either put optional integer attribute "order" in xml
layer or use layer sorting mechanism itself.

2) Persistence - navigator views may want to persist some information, most
likely filter options of what to show, what to hide. Currently there is no
explicit mechanism for persistence in Navigator API. Easy solution is to store
views' settings in Navigator top component serialization, but TopComponent
serialization is not friendly to storing format changes, which may be serious
problem. Any idea here?

3) JSP people already expressed their wish to differentiate between node
selected in opened editor and node selected somewhere else (explorer), mostly
because of their performance and implementation reasons. I feel this could be
common case. How to approach such problem? We could have a flag in the layer,
meaning that a provider wants to be active only when node in editor is selected.
Or more generally, we could give providers info about selected node type and
give them chance to refuse to show completely or to show simpler structure for
in specific situations. This would lead to additional filtering-like interface
with method accept(Node node).
Comment 11 Milan Kuchtiak 2005-06-10 14:03:35 UTC
Looking at public packages (in project.xml):

1. I don't see the org.netbeans.api.navigator package in the code.
What classes should be there.
2. The dependency on org.openide.loaders doesn't seem to be required.
Comment 12 Milan Kuchtiak 2005-06-10 15:32:14 UTC
As far as the persistence problem - what about to provide the ability to create
the layer file for settiongs. The layer file (xml file) can consist of 2 parts :
optional part with known elements (like the order of view that should be open)
extesible part : anything can be included there.

Suggested schema for that file :

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            targetNamespace="http://xml.netbeans.org/navigator/settings"
            xmlns="http://xml.netbeans.org/navigator/settings"
            elementFormDefault="qualified">
   <xsd:element name="settings" type="ns:SettingsType"/>
   <xsd:complexType name="SettingsType">
       <xsd:sequence>
           <xsd:element name="viewToOpen" minOccurs="0" type="xsd:integer"/>
           <xsd:element name="optional" minOccurs="0" type="xsd:anyType"/>
       </xsd:sequence>
   </xsd:complexType>
</xsd:schema>

Sampe xml document :

<settings>
  <viewToOpen>0</viewToOpen> <!-- number of view that should be opened --> 
  <optional>
    <!-- anything can be included here -->
  </optional>
</settings>

Comment 13 Milan Kuchtiak 2005-06-10 15:51:19 UTC
The problem nr.3 is also related to MultiView editors.
We'like to have different structures in Navigator for different views.
See for example the web.xml editor.
Comment 14 Jan Lahoda 2005-06-10 17:53:46 UTC
Only a quick node: I would recommend to use NavigatorPane.panelActivated(Lookup)
instead of NavigatorPane.panelActivated(Node).

Comment 15 Jaroslav Tulach 2005-06-13 09:33:05 UTC
Y01 arch document talks about openapis. they are gone. please enumerate what  
you really depend on   
  
Y02 the navigator shall not listen on activated node, but on 
Utilities.actionGlobalContext, imho. It returns Lookup which then contains 
selected nodes. This will make the system more testable and composable. 
 
Y03 Load the registered providers using standard mechanism - e.g. FolderLookup 
so the set of registration formats is the same. Btw. otherwise document 
format-types question. 
 
Y04 The API cannot be under development forever. When you change it to 
official? 
 
Y05 Is it guaranteed that the SPI method is called from AWT thread or not? 
 
Y06 Why the how to is not part of arch*xml usecases document? If you do that 
you will be included in standard pages with usecases. 
 
Y07 Why the <api /> tag is not used to describe layer interface? We now 
generate summary page based on that and it is shame there is no description 
now: 
 
 
 
 
 
Comment 16 Petr Jiricka 2005-06-15 10:13:32 UTC
Looking at the branch, I guess package org.netbeans.api.navigator should be
removed from public packages - it does not exist.
Comment 17 Marek Fukala 2005-07-05 17:32:59 UTC
Note that the layer content in the example is not in accordance with the
ProviderRegistry class code. The currently required layer format for
NavigatorPanel instancies is following:

    <folder name="navigator">
        <folder name="panels">
            <folder name="text">
                <folder name="xml">
                    <file
name="org-netbeans-modules-xml-text-navigator-XMLNavigatorPanel.instance">
                        <attr name="mimeTypes" stringvalue="text/xml"/>
                    </file>
                </folder>
            </folder>
        </folder>
    </folder>

Please fix the example content.
Comment 18 Marek Fukala 2005-07-05 17:36:53 UTC
How the new navigator (newly inspector) module coexists with the old navigator
api/spi and its java implementation? I suppose the old one will be removed
right? Just now I have to disable the old navigator module to be able to use the
new one.
Comment 19 Jesse Glick 2005-07-12 04:00:14 UTC
I believe there was a TCR to remove the mimeTypes attribute, so plain
FolderLookup could be used. No?
Comment 20 David Simonek 2005-07-14 17:41:12 UTC
Hi all, sorry for delayed response, I was warking on TCRs and java navigation
module conversion at full speed :-)

Situation now: Nearly all TCRs completed, some documentation remnants left.
Example xml layer updated, Jesse is right it now conforms to FolderLookup style
of registration.

I'll ask for exit review soon, there are several minor topics that I'd like to
talk about:
1) I added spi.navigator.NavigatorLookupHint interface. It is for clients which
want to specify their Navigator content type in their node. I hope you'll have
no objections.

2) There seems to be a performance/flicking problem in Java client of new
Navigator API. When user is traversing java source code in editor code by
arrows, node for each method is activated, triggering repeated
panelActivated/panelDeactivated calls on java client's NavigatorPanel impl. This
causes flickering/unnecessary reloading of Navigator content.
My solution: I'd add method to the NavigatorPanel, say "contextChanged (Lookup)"
which will be called if node changes but still the same NavigatorPanel provider
is available. Client impl side then can judge if old and new context are somehow
related and not reload everything in such case. How about that? 

Comment 21 Jaroslav Tulach 2005-07-15 07:37:38 UTC
Can you attach results of "ant javadoc" and "ant coverage" here? 
Comment 22 Jaroslav Tulach 2005-07-15 16:15:48 UTC
Re. flicking: The lookup is designed to be mutable and everyone working with 
it is supposed to listen on changes inside it. That is why it would be enough 
imho, to just call activated(Utilities.actionGlobalContext()) as soon as first 
java file is selected and then ignore all node changes until someone selects 
different file type. The java impl would then listen on changes of its Lookup 
and update itself to the correct file content. 
Comment 23 David Simonek 2005-07-15 18:31:52 UTC
Yes, works but with one caveat - when lookup (activated nodes) is changed to
contain navigator window itself, clients would need to be adviced to not empty
their content, but stick with last context valid for them, which is not very nice :(
Comment 24 Jaroslav Tulach 2005-07-15 22:18:28 UTC
Hmm. I have not thought about that. Possible fix is to Use Lookups.proxy to 
have the selection of the lookup to delegate to under your control. Would 
mimic Utilities.actionsGlobalContext(), only in case when navigator window is 
selected, the previous Lookup would remain active.  
 
I do not know how much work this is, hopefully not much. This solution would 
still keep the spirit of dynamic behaviour of Lookup. 
Comment 25 Tomas Pavek 2005-07-25 10:18:07 UTC
Opinion document available here:
http://openide.netbeans.org/tutorial/reviews/opinions_58819.html
Comment 26 David Simonek 2005-08-04 12:01:01 UTC
Thanks Tomas for opinion document. TCRs requested to be fixed before merge are
fixed now, no further SPI changes I could see on my radar, so I'm going to merge
to main trunk in a minute. Remaining TCRs and TCAs will be solved continually
ASAP. Thanks again for your work. 
Comment 27 David Simonek 2005-08-04 12:23:28 UTC
Merge completed. Leaving this task still open until I resove remaining TCRs and
TCAs.
Comment 28 David Simonek 2008-10-15 13:00:24 UTC
Completed long time ago, just forgot to close this, closing now.