Community
Participate
Working Groups
In case a search provider is capable of performing a search without a search destination selected, the "Search in" section is useless and it takes quite some space. Showing the section only if necessary makes sense
What exactly are "destinations" in the context of the Search Console? None of the currently implemented search types (in the main branch or the prototype branch) seem to include any. And Manage Destinations opens an empty preference page. What are they and how do they play into the broader design for extensibility?
Hi Brian, The destinations are the places where the search is performed in, whatever that means for the search provider implementation. Imagine that you have a search provider which searches for web services. The web service definitions might reside on a UDDI server, or a custom registry, such as xmethods.com. In some preference page you are able to configure several UDDI servers The workflow in the console would be like this 1. Select "web services" in the "search for" field 2. You should select a destination (i.e. the server) where the search to be performed in. The destinations are displayed in the "Search in" component. Having in mind the UDDI/xmethods.com example, the search in tree could look like that: UDDI |-uddi_server1.com |-uddi-server2.com |-uddi-serverx.com Public registries |-xmethods.com |-myregistry.com In this example, "UDDI" and "Public registries" are the desctination categories which group similar destinations (places) to perform the search in. The nodes "uddi-server*", "xmethods.com" and "myregistry.com" are the specific destinations where to search the services in. The concept of destination categories and destinations is briefly described in the developer guide attached in the "developer guide" (https://bugs.eclipse.org/bugs/attachment.cgi?id=180106) The cheat sheets example defines a single destination category called "Local cheatsheets". This category defines several destinations which are mapped to the cheat sheets groups. Theoretically, you might also have a remote cheat sheets system which is, say, configured in the preferences. Then, you would have another category, e.g. "Remote cheatsheets". The children of this category (destinations) represent the concrete remote cheat sheets server. In both cases the result would contain one and the same type of objects - cheatsheets. The user would also have identical experience when consuming the sheets found. However, depending on the destination selected two different search providers would be used: 1. For local cheat sheets the search provider would use the cheat sheets API in Eclipse 2. For remote sheets another search provider would use a remote mechanism, such as web services or REST This use case is possible since search providers are contributed for each pair object type - destination category.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it and remove the stalebug whiteboard tag. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. --
