Bug 92264 - [search] all types names should support patterns for package/enclosing type name
Summary: [search] all types names should support patterns for package/enclosing type name
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: 3.3 M1   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords: api
: 98494 111799 148387 (view as bug list)
Depends on:
Blocks: 111197
  Show dependency tree
 
Reported: 2005-04-21 13:55 EDT by Dirk Baeumer CLA
Modified: 2006-08-04 07:21 EDT (History)
5 users (show)

See Also:


Attachments
Proposed patch (34.05 KB, patch)
2006-05-18 06:39 EDT, Frederic Fusier CLA
no flags Details | Diff
JDT/UI patch (978 bytes, patch)
2006-05-18 06:44 EDT, Frederic Fusier CLA
no flags Details | Diff
Proposed patch update (46.94 KB, patch)
2006-06-22 10:05 EDT, Frederic Fusier CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Baeumer CLA 2005-04-21 13:55:20 EDT
The old Open Type dialog supported searching for package patterns. To port this
functionality over to the new open type dialog, search for all type names should
support patterns for package/enclosing type name.
Comment 1 Kent Johnson CLA 2005-04-21 15:05:52 EDT
To support this, we need a new API method on SearchEngine such as:

public void searchAllTypeNames(
	final char[] qualification, 
	final char[] typeName,
	final int matchRule, 
	int searchFor, 
	IJavaSearchScope scope, 
	final TypeNameRequestor nameRequestor,
	int waitingPolicy,
	IProgressMonitor progressMonitor)  throws JavaModelException

which supports both the qualification & typeName as patterns. We would use a 
QualifiedTypeDeclarationPattern instead of a TypeDeclarationPattern.

NOTE: We would match the member type 'p1.A.M.Network' if supplied with 'p1.*' 
& 'Net*'

This would be very similar to the new method searchAllTypeNames(char[][] 
qualifications, char[][] typeNames...) added for organize imports. See bug 
84224#c17.
Comment 2 Kent Johnson CLA 2005-04-27 12:21:38 EDT
Do we want to do this one?
Comment 3 Dirk Baeumer CLA 2005-04-27 12:33:06 EDT
Kent, what can we do here fore 3.1 assuming that we don't do anything for bug 92266.
Comment 4 Philipe Mulet CLA 2005-04-27 12:50:41 EDT
Basically we'd like to call these good for 3.1, and say that we revisit API for
3.2 (using object wrappers)
Comment 5 Dirk Baeumer CLA 2005-04-27 13:07:52 EDT
The problem is that the old open type dialog had the feature of being able to
use wildcards in pattern names. This is currently lost functionality certain
people are complaining about. So if we can do something without additional API
that would be great.
Comment 6 Philipe Mulet CLA 2005-04-27 13:23:01 EDT
Wildcard in simple name sounds fair, but in enclosing or package... do anyone
use this dialog with anything other than a simple name ?
Comment 7 Kent Johnson CLA 2005-04-27 13:27:48 EDT
Without a new API, we cannot support wildcards in the package name.

As for supporting it... with the history, why do they need wildcards in the 
package name?

The history will give them what they want quicker.
Comment 8 Dirk Baeumer CLA 2005-04-27 13:44:39 EDT
The use case is that they don't remember the name but know that the type is in a
util package. They can type *.util.* which gives them all types in all util
packages.
Comment 9 Kent Johnson CLA 2005-05-02 11:51:26 EDT
I accept that we may be 'removing' a case that worked in the past, but I doubt 
too many users will notice.

They can still find the type by using the search dialog with type declarations 
& a qualified pattern match.
Comment 10 Kent Johnson CLA 2005-05-06 12:50:59 EDT
Reconsider adding the API after 3.1
Comment 11 Dirk Baeumer CLA 2005-06-06 08:24:54 EDT
*** Bug 98494 has been marked as a duplicate of this bug. ***
Comment 12 Markus Keller CLA 2005-06-08 10:24:42 EDT
+1 from an occasional user of this feature.
Comment 13 Frederic Fusier CLA 2005-12-07 13:10:18 EST
*** Bug 111799 has been marked as a duplicate of this bug. ***
Comment 14 Frederic Fusier CLA 2005-12-07 13:12:14 EST
Kent, is it in your plan to add this API to SearchEngine or do you want me to take it?
Comment 15 Kent Johnson CLA 2005-12-07 13:55:44 EST
Check with Philippe whether we want to add it. I would vote no.

If so, then its all yours.
Comment 16 Philipe Mulet CLA 2005-12-12 05:17:51 EST
I could imagine living without it... now if doing it, we will not do something else (thinking of some template search for instance). Also, I would imagine that one may want a different matchRule for qualification than for typeName (likely overkill).

Pls check again with clients if really needed.
Comment 17 Huw Roberts CLA 2005-12-12 06:07:43 EST
Personally I find (found) this feature invaluable.  I used it in the way Dirk describes in Comment#8 - for example I know that there's a class that does something like I want in my code-base.  I know it's called *Cache* but when I search for *Cache* I get 1600 results because of the other jars in my workspace.  I can do other kinds of filtering (such as setting up a working set), which helps a bit, but it's nothing like as good as using package filtering: com.fredcorp.**.util.**.*Cache*
Comment 18 Dirk Baeumer CLA 2005-12-13 05:08:06 EST
We had that feature in th old (two pane) Open Type dialog. Besides the case described in #17 it is useful for "quickly" browsing all classes in a package. For example "java.util.*"
Comment 19 Frederic Fusier CLA 2006-04-19 04:11:50 EDT
Too late for this kind of change in dvpt process.
Defer post 3.2, set target as 3.3 to take this bug in early 3.3 dvpt
Comment 20 Frederic Fusier CLA 2006-05-18 06:17:05 EDT
Fix for this is now available for this problem => reopen
Comment 21 Frederic Fusier CLA 2006-05-18 06:39:50 EDT
Created attachment 41862 [details]
Proposed patch

Note that fix design is:
1) Change existing searchAllTypeNames(char[], char[], int, int,...) API method
   contract (eg. Javadoc) to specify that packageName parameter only accepts
   *exact* package full name.
2) Add new searchAllTypeNames(char[], int, char[], int, int,...) API method to
   allow usage of a different match rule for packages/enclosing types name.
Comment 22 Frederic Fusier CLA 2006-05-18 06:44:23 EDT
Created attachment 41868 [details]
JDT/UI patch

This patch needs to be applied on org.eclipse.jdt.ui project to make Open type dialog working properly with patterns in package name...
Comment 23 Frederic Fusier CLA 2006-06-22 10:05:25 EDT
Created attachment 45087 [details]
Proposed patch update

Patch updated with HEAD contents + JDT/Core plugins ID update (3.3.0) + buildnotes_jdt-core.html update + exportplugin.xml script update (see bug 148174)
Comment 24 Frederic Fusier CLA 2006-06-22 10:10:28 EDT
Released for 3.3 M1 in HEAD
Comment 25 Martin Aeschlimann CLA 2006-06-23 09:54:30 EDT
*** Bug 148387 has been marked as a duplicate of this bug. ***
Comment 26 Martin Aeschlimann CLA 2006-06-23 10:51:37 EDT
changed the open type dialog to use the support. thanks frederic!
Comment 27 Maxime Daniel CLA 2006-08-04 07:21:20 EDT
Verified for 3.3 M1 using build I20060804-0010.