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.
To add support for server sides queries, there needs to be a way to add a "Remote Scope" to the list of scopes in find usages.
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