Bug 217347

Created attachment 123510 [details]
Proposed patch

Please review the attached patch.

Thanks a lot for working on this.
JL01: would it be possible to avoid including the ScopePanel GUI the API? Maybe something like:
final class ScopePanel extends Object { //maybe ScopePanelProvider
    public static ScopePanel create(...) {...}
    public JPanel getUI() {...}
    public boolean initialize(...) {...}
    public Scope getSelectedScope() {...}
}
Does not seem particularly nice, but would not introduce a subclassable UI class into the SPI.
JL02: the relationship between @ScopeDescription and ScopeProvider is a little bit confusing to me - maybe @SD should be renamed to @ScopeProvider.Registration? Also not sure if displayName and iconBase need to be defined in the @SD - the SP must be instantiated anyway to get the correct display name and icon. (It also relates to Scopes.create - I will need to think about this further.)
JL03: I don't think that getting "Scope" from the project's lookup in OpenProjectsScopeProvider.addProjectToScope is a good idea (I know that its done in Source/Inspect) - maintaining the Scope instance in the project's Lookup is pretty difficult. Maybe we could look-up ScopeProvider? Does not seem very nice to be, but better for the clients than Scope.

What a huge patch. Maybe it is enough to submit just diffs of API classes...

> JL02: ScopeDescription also does not have javadoc.

JL01: I'm not sure, I prefer to have something that cooperates nicely with the gui-builder. But I do agree that it should be final.

JL02: Yes, I can move/rename ScopeDescription to ScopeProvider.Registration. The  icon and displayname are in @SD because not all scopes are depending on the context -> Opened Projects, Remote, Custom. But this can be changed if you want.

JL03: Ok, will change this.

JB01: Sorry, I will document this class.

Created attachment 123726 [details]
Proposed API

Updated patch, splitted into API classes and implementation

JL01: Made ScopePanel final.
JL02: I moved @SD to @ScopeProvider.Registration and moved the Scopes implementation to separate delegating classes, as is design pattern used in netbeans sources.
JL03: I removed this from the scope provider and changed it to something that is used in FU currently.

JB01: Javadoc for @ScopeProvider.Registration (@SD) has been added.

Created attachment 123727 [details]
Proposed implementation

API looks good. 

VV01: small remark, compare method returns int, so 
return (o1.getPosition() < o2.getPosition() ? -1 : (o1.getPosition() == o2.getPosition() ? 0 : 1));
can be replaced by more simple
return o1.getPosition() - o2.getPosition();

VV02: I have a question. Find Usages sometimes expands first elements and sometimes not, probably based on number of elements to be displayed. Now "lazy" ExpandableTreeElement was introduced. Would it be expanded as well if it is only one? I want to change all our files nodes into ExpandableTreeElement to prevent creation of htmlized strings as it is now

VV01: I recently had some problems in C when true/false were not exactly 1/0, but I will change it.

VV02: No, the results should be expanded up to the found elements. I'm not sure if it is advisable for plugins, were it is possible to get all the found elements, to use the ExpandableTreeElement. Is the creation of these strings really that expensive?

If there are no further comments, I will integrate tonight.

(In reply to comment #8)
> VV02: No, the results should be expanded up to the found elements. I'm not sure
> if it is advisable for plugins, were it is possible to get all the found
> elements, to use the ExpandableTreeElement. Is the creation of these strings
> really that expensive?
I think I saw it in profiler, but have to double check. Anyway, it was just a question, not a blocker for integration

Changeset: 8224a1328778
Author:    Ralph Benjamin Ruijs <ralphbenjamin@netbeans.org>
Date:      2012-08-31 19:50
Message:   Issue #217347 - Add support for server side queries in Find Usages

Changeset: 999fa8f7d6ff
Author:    Ralph Benjamin Ruijs <ralphbenjamin@netbeans.org>
Date:      2012-08-31 19:51
Message:   Issue #217347 - Add support for server side queries in Find Usages

Integrated into 'main-golden', will be available in build *201209010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/8224a1328778
User: Ralph Benjamin Ruijs <ralphbenjamin@netbeans.org>
Log: Issue #217347 - Add support for server side queries in Find Usages