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 138345 - Api review of Jump to Symbol SPI
Summary: Api review of Jump to Symbol SPI
Status: RESOLVED FIXED
Alias: None
Product: utilities
Classification: Unclassified
Component: Jump To (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Tomas Zezula
URL:
Keywords: API, API_REVIEW_FAST
Depends on:
Blocks:
 
Reported: 2008-06-26 12:07 UTC by Tomas Zezula
Modified: 2008-07-02 12:34 UTC (History)
2 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments
Patch (20.90 KB, patch)
2008-06-26 12:09 UTC, Tomas Zezula
Details | Diff
New patch (20.89 KB, patch)
2008-06-26 12:18 UTC, Tomas Zezula
Details | Diff
Dialog screenshot (64.78 KB, image/png)
2008-06-27 08:20 UTC, Tomas Zezula
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2008-06-26 12:07:01 UTC
The SPI is needed to allow modules to provide data to Go  to Symbol dialog.
The SPI should be stable in NB 6.5.
The SPI mirrors the current Go to Type SPI.
Comment 1 Tomas Zezula 2008-06-26 12:09:43 UTC
Created attachment 63502 [details]
Patch
Comment 2 Tomas Zezula 2008-06-26 12:13:12 UTC
The diff has wrong number in the apichanges, which I've fixed in the new diff.
Comment 3 Tomas Zezula 2008-06-26 12:18:17 UTC
Created attachment 63503 [details]
New patch
Comment 4 Tomas Zezula 2008-06-26 13:59:41 UTC
One more change, the SPI should stay friend API as the rest of this module.
Comment 5 Jesse Glick 2008-06-26 19:41:28 UTC
Does the Go to Symbol dialog exist yet, or is it still proposed?
Comment 6 Tomas Zezula 2008-06-27 08:18:31 UTC
Yes, I've already created the dialog. But the complete patch set has approximately 4000 lines, it was hard to find the added spi in it, so I've created just the 
API diff. I am attaching the screenshot of the dialog, it's similar to the Go To Type dialog.
If someone want I can also attach tho complete diff.
Comment 7 Tomas Zezula 2008-06-27 08:20:04 UTC
Created attachment 63577 [details]
Dialog screenshot
Comment 8 Jaroslav Tulach 2008-06-27 10:04:02 UTC
Y01 "cancel()" is not operation of Provider, but of one invocation of provider. Should be part of Context or Result 
classes. Ditto cleanup(). Btw. I've just blogged about the topic two days ago: 
http://wiki.apidesign.org/wiki/APIDesignPatterns:RequestResponse

Y02 Is SymbolDescriptor API or SPI? Decide and adjust to final class or interface. Btw. my opinion is that you can 
remove the class from the API completely, and replace it by Result.addSymbol(Icon, String, String, String, Icon, 
FileObject, int, ActionListener) and/or similar methods. But the right approach really depends on your intention with 
the class...

Comment 9 Tomas Zezula 2008-06-27 10:29:24 UTC
YO1: Not so easy. When you look into the cancel javadoc, you will find out that the cleanup is rather operation of the 
Provider. The Result & Context changes with calls of compute, but the Provider may keep some caches which are cleaned when cleanup is called - cleanup 
is operation on provider.
The cancel may be moved to Context but this will make the SPI different to GoToType SPI which will be strange, these SPI are typically implemented by the 
same developer who will be interested why the APIs for "the same thing" differs.
The API pure solution will look in this way:

SymbolProviderFactory {
    /**
      * Called once per go to symbol dialog, the returned SymbolProvider
      * is not reused by other invocation of the go to symbol dialog
      */
    SymbolProvider create ();
} 
 registered in the services

SymbolProvider {
    Result query (Context);
    /**
      * Called when the go to symbol dialog is closed.
      * After this method is called no other query will come.
      */
    cleanup ();
}

Context {
   cancel()
   getName()
   getProject()
   ....
}

but it's very different to the GoToType SPI and much more complicated than the GoToType SPI.

Y02: SPI. The method addSymbol(Icon, String, String, String, Icon,  FileObject, int, ActionListener) with 8 parameters is a worse solution than having a single 
parameter operation addSymbol (SymbolDescriptor) with 1 parameter object in my point of view.
Comment 10 Tomas Zezula 2008-07-02 08:17:02 UTC
I will integrate it today.