Community
Participate
Working Groups
Currently the various places that use search are hard-coding the search service URL. As a first step we should put this in the file client so it can be plugged in.
Would really like to see this for RC3 is possible.
Not done yet, but work in progress pushed in branch "bug361476". As a first step I have left the hard-coding in fileClient.js. It is a bummer that this requires all pages to pull in the file service where in some cases it wasn't previously needed (like git pages). This is not ready to release.
This is fairly complicated. The global header that contains the search bar has no context on what file service to be searched. To actually be useful I think we would need to perform the search over each file system and then combine the results. We could do something like always pick the first file system and use its search location, but that would only work in the same case where it does today. The way it works today is all the URL construction happens at the time the query is created. Then it just sets window.location to: /search.html#<url-of-search-service>?q=<terms> Once on the search.html page it is dumb and does a simple get on the search service URL to get the results. This only works if the search service is on the same host as the search.html page, which is the problem we're trying to solve. To search across all file systems we would need to drop the URL from the hash and just have something like this: /search.html?q=<terms> On the search results page it would then iterate over all file services and perform the search on each one, and combine the results. In the end I think we need to make this change, because otherwise the search service is tied to the domain hosting the UI. I don't think an incremental step of just moving the hard-coded path into the file service will be useful for 0.3. I think we should just do the right fix for 0.4.
The last approach is what I was hoping for. e.g. making the search query creation in the search client ultra simple and no need to load the search plugin -- like just q=xyz as you suggest --- and then running against each file service and merging. It is getting late...
(In reply to comment #3) > > On the search results page it would then iterate over all file services and > perform the search on each one, and combine the results. I have a question here, maybe a stupid one: I am asking file service to give back the meta data/parent chain of a file, to build the tree model. Is there any chance for two files in two file system to have exactly the same full path + file name? Another question is can we search on a folder/folders? If not, can we just search all and filter out non-selected folders at the end. Is this an acceptable solution? I found searching on selected folder/folders is very useful for me.
I have a working implementation ready: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?h=bug361476-cleanup&id=6c8401837a921290b5ebdebbc9bb134bb12dad54 I verified global search bar, 'Open Resource', and editor global search are all working.
(In reply to comment #5) > I am asking file service to give back the meta data/parent chain of a file, to > build the tree model. Is there any chance for two files in two file system to > have exactly the same full path + file name? No I don't think so. The full path will always be different. File systems are looked up using a prefix on the full path, so there is no way for two file systems to have a file with the same full path. > Another question is can we search on a folder/folders? The server supports this already but there is no client side. On the server, just add Location:/file/<prefix>/* to search in a given folder only. You can do this today by manually manipulating the search URL in the browser but the post-processing doesn't account for it. See bug 334709 for details.
Released to master. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=821f2baf37b6583120695d1899d96ac46ca86497
Closing.
